debug_traceBlockByHash
debug_traceBlockByHash方法返回由其哈希标识的指定区块中所有交易执行的所有操作码的完整跟踪。此方法提供对指定区块内每个交易的全面操作码级执行信息，用于分析和调试，使其成为深入研究区块链状态转换的理想工具。
用途
- 调试特定已知区块内的复杂交易失败和交互
- 分析精确识别的区块中多个交易的执行模式
- 研究历史区块中交易的燃气使用优化
- 在生产环境中对已部署合约进行安全审计
- 验证特定重要区块中交易行为和执行流程的正确性
- 了解一系列交易中复杂的多合约交互
- 通过区块哈希分析历史区块以调查网络行为
- 追踪交易的精确执行，用于区块验证或错误搜索
- 识别同一区块上下文中交易执行的模式
- 调查MEV（矿工可提取价值）交易排序效应
- 在区块环境上下文中调试失败的交易
方法详情
此方法在操作码级别跟踪区块中所有交易的执行，通过区块哈希识别区块。
参数:
要跟踪的区块哈希
跟踪选项，用于配置调试输出
设置为true禁用存储捕获
设置为true禁用内存捕获
设置为true禁用堆栈捕获
使用自定义跟踪器（可用：callTracer、prestateTracer、4byteTracer等）
覆盖基于JavaScript跟踪的默认5秒超时
返回值:
区块内交易跟踪的数组
交易使用的燃气
交易是否失败
交易的返回值
结构化的EVM操作日志数组
程序计数器位置
执行的操作码
剩余燃气
此操作的燃气成本
调用深度
EVM内存内容（如果未禁用）
EVM堆栈内容（如果未禁用）
存储变更（如果未禁用）
响应示例（简化版）
{
"jsonrpc": "2.0",
"id": 1,
"result": [
{
"gas": 21000,
"failed": false,
"returnValue": "",
"structLogs": [
{
"pc": 0,
"op": "PUSH1",
"gas": 68232,
"gasCost": 3,
"depth": 1,
"stack": [],
"memory": [],
"storage": {}
},
{
"pc": 2,
"op": "MSTORE",
"gas": 68229,
"gasCost": 12,
"depth": 1,
"stack": ["0x60", "0x40"],
"memory": [
"0000000000000000000000000000000000000000000000000000000000000000",
"0000000000000000000000000000000000000000000000000000000000000000"
],
"storage": {}
}
// ... 更多操作
]
}
// 其他交易跟踪...
]
}
使用callTracer的响应
当使用callTracer选项时，响应会格式化为每个交易的调用图：
{
"jsonrpc": "2.0",
"id": 1,
"result": [
{
"type": "CALL",
"from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
"to": "0xdac17f958d2ee523a2206206994597c13d831ec7",
"value": "0x0",
"gas": "0x13458",
"gasUsed": "0x8fc",
"input": "0xa9059cbb0000000000000000000000001f9840a85d5af5bf1d1762f925bdaddc4201f984000000000000000000000000000000000000000000000002b5e3af16b1880000",
"output": "0x0000000000000000000000000000000000000000000000000000000000000001",
"calls": [
{
"type": "STATICCALL",
"from": "0xdac17f958d2ee523a2206206994597c13d831ec7",
"to": "0x1f9840a85d5af5bf1d1762f925bdaddc4201f984",
"gas": "0x8fc",
"gasUsed": "0x54b",
"input": "0x70a08231000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7",
"output": "0x0000000000000000000000000000000000000000000000000000000000000000"
}
]
}
// 额外的调用跟踪...
]
}
可用的跟踪器
Geth提供了几个内置跟踪器：
- 默认跟踪器：详细的操作码级执行日志
- callTracer：专注于合约之间的调用层次结构
- prestateTracer：显示执行前的合约状态
- 4byteTracer：跟踪函数选择器使用统计
- noopTracer：用于性能测试的最小跟踪器
- opCountTracer：计算每个操作码的出现次数
您还可以使用基于JavaScript的自定义跟踪器进行专业分析。
与其他区块跟踪方法的区别
虽然所有三种区块跟踪方法都提供类似的信息：
debug_traceBlockByHash接受区块哈希以精确识别区块debug_traceBlockByNumber使用区块号或标签（例如"latest"）debug_traceBlock需要RLP编码的区块作为输入- 所有方法返回相同的跟踪格式
- 当您知道要调查的确切区块哈希时，此方法是理想选择
性能考虑
- 跟踪整个区块非常消耗资源，特别是对于有多个交易的区块
- 对于复杂交易的区块，响应大小可能非常大
- 考虑使用
disableMemory、disableStack或disableStorage选项 - 仅用于调用图分析时，
callTracer效率更高 - JavaScript跟踪器可能需要更长的超时时间来处理复杂区块
- 对历史区块的查询需要归档节点
- 在公共节点上跟踪有许多交易的区块可能会超时
- 对于高交易量的区块，考虑单独跟踪各个交易
- 响应时间随区块大小和交易复杂性增加
- 对于具有复杂交易的区块，建议使用专门的跟踪器
重要说明
- 此方法需要在节点上启用调试API（--http.api=eth,debug,net,web3）
- 并非所有以太坊客户端都支持此方法（主要是启用了调试API的Geth）
- 对于较旧的区块，需要归档节点才能访问历史状态
- 该方法提供区块中所有交易的详细跟踪，这可能导致非常大的响应
- 不同的以太坊客户端可能产生略微不同的跟踪格式
- 输出格式取决于所使用的跟踪器，可能会在客户端版本之间发生变化
- 对于不需要跟踪的常规区块信息，使用eth_getBlockByHash
另请参阅
- debug_traceBlock - 使用RLP编码区块数据跟踪区块
- debug_traceBlockByNumber - 通过区块号跟踪区块交易
- debug_traceTransaction - 跟踪单个交易
- debug_traceCall - 跟踪调用而不创建交易
- eth_getBlockByHash - 不进行跟踪的通过哈希获取区块
帮助我们变得更好！
分享此页面并帮助我们为您创建更好的产品。