trace_block doesn't work as expected

[Azleal]

System information

OS & Version: Linux

Erigon Command (with flags/config):

erigon --datadir /home/bsc/bsc-erigon --chain bsc --private.api.addr= --port 2511 --nat w3cu.solarlaugh.com --nat any --torrent.port 2514 --authrpc.port 2513 --http.addr 0.0.0.0 --http.vhosts --http.port 2510 --http.api=eth,erigon,web3,net,debug,trace,txpool --http.corsdomain --torrent.download.rate=2000mb --db.pagesize=8KB --db.size.limit=16TB

Chain/Network: bsc mainnet

Actual behaviour

there are 5 calls in this tx, including delegatecall, staticcall,call.

when calling erigon node with payload: {"method":"trace_block","params":["0x291BADC"],"id":1,"jsonrpc":"2.0"}, 0x291BADC is the block number of the tx_hash above in hex. in the result, there are only 3 calls of this tx(0x386c11b7332621e73d275f0e76a020ca035d4e14dea5d079511671dc4d2e3b97)

Expected behaviour

expected 5 calls to be returned.

Steps to reproduce the behaviour

1. visit tx trace in explorer
2. call curl --location 'http://erigon-node:2510' \ --header 'Content-Type: application/json' \ --data '{"method":"trace_block","params":["0x291BADC"],"id":1,"jsonrpc":"2.0"}'
3. differences between explorer calls and erigon trace_block calls

[blxdyx]

What's your version?

[Azleal]

What's your version?

sorry, I'm using quicknode api, not sure what their erigon version. try this command

curl -L 'https://docs-demo.bsc.quiknode.pro/' \
-H 'Content-Type: application/json' \
-d '{
  "method": "trace_block",
  "params": [
    "0x291BADC"
  ],
  "id": 1,
  "jsonrpc": "2.0"
}'

and search traces of tx(0x386c11b7332621e73d275f0e76a020ca035d4e14dea5d079511671dc4d2e3b97), only there traces are there, expected 5 calls as show in here

[blxdyx]

Thanks for your report. Will try fix it. BTW, why not try debug_traceBlock?

[Azleal]

Thank you for looking into this. Could you provide more details on how this issue occurs or what types of transactions might trigger it? I'd like to check if there are any such transactions in our database that we've overlooked.

BTW, why not try debug_traceBlock?

we need tx traces in a flattened array format, trace_block provides this directly, whereas debug_traceBlock or debug_traceBlockByNumber return nested results, requiring an additional step to flatten the structure.

for now, we've switched to debug_traceBlockByNumber. If trace_block is fixed in the future, we'll likely switch back to using it.

I appreciate your assistance and look forward to the fix. If convenient, please keep me updated on the progress. Thanks again for your support.

[blxdyx]

The trace_* return result format is right. Because the trace_block will not include the precompile contract. Such as call to 0x0000000000000000000000000000000000000001. The bscscan result is debug_traceTransaction, which is different with the trace_block.
You could try with this: curl -L 'localhost:8545' \ -H 'Content-Type: application/json' \ -d '{ "method": "debug_traceTransaction", "params": [ "0x386c11b7332621e73d275f0e76a020ca035d4e14dea5d079511671dc4d2e3b97", { "tracer": "callTracer", "tracerConfig": { "includePrecompiles": false } } ], "id": 1, "jsonrpc": "2.0" }' It will return 3 calls with the includePrecompiles == false.

[Azleal]

Thank you for your detailed reply. I've tested using "tracerConfig": { "includePrecompiles": false } with both debug_traceTransaction and debug_traceBlockByNumber, and indeed, both returned 3 calls for the transaction in question.

I have a few follow-up questions to further clarify this topic:

1. is it accurate to say that all calls to precompiled contracts are exclusively of the staticcall type, and never call or delegatecall types?

2. when using "tracerConfig": { "includePrecompiles": false }, should we expect consistent results across trace_block, debug_traceTransaction, and debug_traceBlockByNumber? or are there potential discrepancies?

3. do you know of any comprehensive documentation for tracerConfig? I've found some information, such as this QuickNode documentation, but it seems incomplete. are there more detailed resources available?

If you're aware of any additional materials or documentation related to this topic, I would greatly appreciate if you could share them. Thank you for your assistance.

[blxdyx]

1. it depend on how your tx's input data.
2. trace_transaction and debug_traceTransaction are different. I remember gas and gasUse are diff. You can refer this: #311 . And other parts are same.
3. It depend on the rpc provider. I didn't found much doc about this.

[Azleal]

1. it would be nicer if you have any examples. currently, we're planning to omit any 'staticcall' type calls in both trace_block and debug_traceBlockByNumber. of course with "tracerConfig": { "includePrecompiles": false }. just to make sure that both of these two methods would return identical results(as for trace lenth).

2. you might make a mistake, I didn't mention trace_transaction. but i got you, gas and gasUse are not in consideration.

it's a pity that there's no full doc about this. anyways, I think I figured out most of it. thank you

[blxdyx]

trace_block is tracetransaction one by one. So i mean they are same. And it more easy to find diff. You can refer to this case: https://etherscan.io/vmtrace?txhash=0xed080a06ef45da6f2f09e8371b9f2f7f9c5784ac431f07f55d32cf2fee62a4cc&type=parity The etherscan are use trace* api. And the gasused is bigger than the receipt's gasused, because trace_api also will not include refund gas.

[blxdyx]

Reopen if still have problem.