op-geth
op-geth copied to clipboard
flatCallTracer for prebedrock blocks
Rationale
At https://github.com/ethereum/go-ethereum/pull/26377 this PR Geth introduced flatCallTracer
which uses callTracer
as a proxy to collect call stack info and at the end formats the output in Parity style
Currently, if I am correct flatCallTracer
works only for blocks above 105235063
and for older blocks response is
{
"jsonrpc": "2.0",
"id": 1,
"result": [
{
"error": "tracer not found"
}
]
}
Where older blocks support callTracer
(which means that they should support flatCallTracer
as well - this is just a different format)
This alignment will help a lot of data pipelines to align approaches add process all blockchains using Parity style traces since block 0.
If I am doing something wrong, feel free to advice how to solve that problem.
I assume that you are on OP-mainnet, because block number 105235063 is start of the OP-mainnet bedrock genesis. Also, your are getting some sane responses for prebedrock(block number below 105235063), so I again assume that l2geth is properly setuped on your side(or you are using public infra).
Overall node architecture follows below diagram(Ref):
If you send your RPC request, it first arrives to op-geth. If op-geth decides that this request is for prebedrock(block number below 105235063), it routes to l2geth, which stores legacy data and has the ability to trace prebedrock transactions.
Based on your observation, op-geth fetched upstream(geth) and implements flatCallTracer
. Thats why flatCallTracer
works in bedrock blocks. But, l2geth does not support flatCallTracer
, because it is not actively following geth's upstream changes.
Some sidenote: l2geth and op-geth have different state transition rules. Thats why there are two different binaries, and two different databases.
Question if flatCallTracer
uses callTracer
as a proxy to collect call stack info and at the end formats the output in Parity style, is there a chance that op-geth would be converting callTracer from l2geth to flatCallTracer
to keep the standard?
That seems possible. I proxied ots_traceTransaction
(erigon only RPC) by reconstructing response of debug_traceTransaction
at op-erigon: https://github.com/testinprod-io/op-erigon/pull/30. However I am not 100% sure.
@ pcw109550 is this something that Optimism Foundation can consider worth doing?