当使用 debug_tracecall 并在执行过程中发生变化。这太详细了。当我使用默认 callTracer
时,我可以得到一个更好的调用树。但是,我似乎都无法从跟踪中提取发射事件。我可以在跟踪中看到它们( log*
opcodes),但是没有简单的方法可以将它们实际解析为“可读”的东西(以及值和原始地址),必须有一种方法来获取日志 - 有什么想法吗?
例如。这是埃塞卡(Etherscan)显示(请参阅发射事件部分)
When using debug_traceCall, I get a low-level EVM trace of all opcodes and state changes during the execution. This is excessively detailed. When I use default callTracer
, I can get a much nicer call tree. However, neither way I cannot seem to be able to extract the emitted events from the trace. I can see them in the trace (LOG*
opcodes) however there is no easy way to actually parse them to something "readable" (along with values and originating address) There must be a way to get the logs - any ideas?
Eg. this is what Etherscan shows https://etherscan.io/tx-decoder?tx=0x3e3ad35fda1fddd9e154b3860b50371a1acd2fdb4f27f897e234846522bde732 (see Emitted Events section)
发布评论
评论(2)
因此,我自己想到了这一点 - 我为Geth创建了一个自定义的JavaScript示踪剂,该示踪剂以3rd param传递给geth to debug_tracecall (请参阅链接提供的API参考):
该示踪剂由Geth执行,用于跟踪中的每个操作。本质上是什么:
log0
,log1
,log2
,log3
或log4
evm opcodes主题0
和后续主题(如果有)将示踪剂传递给Geth看起来像这样:
So I figured this myself - I created a custom JavaScript tracer for geth that is passed to geth in 3rd param to debug_traceCall (see provided API reference by the link):
This tracer is executed by geth for each operation in the trace. Essentially what it does:
LOG0
,LOG1
,LOG2
,LOG3
orLOG4
EVM opcodestopic0
and subsequent topics (if any)Passing the tracer to geth looks like this:
}
我看到我们可以在这里提取主题。我认为我们还可以一起提取主题和存储。我们需要做什么
}
I see that we can extract topics here. I think we can also extract topics and storage together. What do we need to do