trace_block gas field not equal to debug_traceBlockByNumber output

[quick-pawiromitchel]

Describe the bug debug_traceBlockByNumber returns 0x3f9a0 but trace_block returns 0x31082

Version go-opera/v1.1.3-txtracing-rc.5

To Reproduce

curl 'localhost:8545' -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceBlockByNumber","params":["0x4d8fea4", {"tracer":"callTracer","timeout":"300s"}], "id":1,"jsonrpc":"2.0"}' | jq -r '.result[0].result.gas'

Responds with 0x3f9a0

curl 'localhost:8545' -X POST -H "Content-Type: application/json" --data '{"method":"trace_block","params":["0x4d8fea4"], "id":1,"jsonrpc":"2.0"}' | jq -r '.result[0].action.gas'

Responds with 0x31082

Expected behavior Same gas value

[HonzaDajc]

Debug and trace namespaces are working little bit different.

Root call for debug_trace... has gas value of gas limit - initial gas ( 282,248 - (21000 + 736) ) and that is 0x3f9a0 and it has gasUsed value 0x2a46c (173164) which is gas used by this root call without inner calls.

Root call for trace_... has gas value in action element equals to gas limit to see how much gas actually was used for transaction and gasUsed in result element has a value from transaction receipt to be able to see actual gas consumed by this transaction (all calls in this tx)

Gas and gas used for inner calls should be the same for debug and trace.

[ella-quicknode]

@HonzaDajc Hi, I would like to have further insights on another response inconsistency we observed, it would be good to have the understanding if it's related to inner calls.

In additional to the above issue. We also observed the difference between debug_traceTransaction and trace_transaction call. The txn hash is: 0x596d084f9a97bc0dc88feb04db186212759e3853f41f61c1ed99f9becb123a19. I used "input" field as identifier, and I see "input": "0x" has given 2 different from address between the 2 tracing methods.

trace_transaction shows from: 0xf6ee0b77e670d504058d62c3f979e609f146e2d9, while debug_traceTransaction shows from: 0x6b181aacbe3abea94e6c4261ca07b70ede531a4b. Is the data correct?

Please let me know if I shall open a new issue to address this?

[HonzaDajc]

@ella-quicknode Hi, yes the thing you reported is a bug, already fixed in sonic release, so once archive nodes will use sonic, then it will give same result. It is because of wrong address for inner delegate call