You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Web3 Client Version: Geth/linux-amd64/go1.21.13 via QuickNode
Chain ID: 1329
Describe the bug
We noticed an inconsistency when calling debug_traceBlockByNumber with the tracer set to flatCallTracer. This inconsistency occurs when there are traces for failed transactions within the block. The response returns an incorrect blockHash within the output of this tracer.
To Reproduce
We observed this issue occurring on multiple blocks.
To illustrate the problem, we will highlight two specific examples: blocks 79123882 and 79124420.
When you request the block details using the eth_getBlockByNumber endpoint for each of the examples, you will get the following responses:
Notice the incorrect blockHash returned in the example responses when tracing the block.
For transaction 0x6acd4adb60084b0281ed40b5cce4fcf560cdcb42a883d0130001db70bb4c2420 (79123882) we got the blockHash0xe03a22247e778c76d23ab1063882fefa52e21f9193e7c1e6b5982664af7f98d3
For transaction 0xf59b273e232c919d0b3dec144322e8024d71cbd881bbcf707dba3332c987a6c0 (79124420) we got the blockHash0xe0ff31bf20f8fc9f8765313c16e8b4cda883ea99de2f2535c31a738f9c336893
Both of which is returning incorrect blockHash fields.
Expected behavior
The tracer result in the examples shown above should be returning the correct blockHash for these failed transactions. That is:
When tracing block 79123882;
the blockHash should be 0xf35379eeb07f128a728e2800da1b866fff83f88654702e18de12e8e023693381
and NOT0xe03a22247e778c76d23ab1063882fefa52e21f9193e7c1e6b5982664af7f98d3
for transaction 0x6acd4adb60084b0281ed40b5cce4fcf560cdcb42a883d0130001db70bb4c2420
When tracing block 79124420;
the blockHash should be 0x613665431b87da5cec698a7e4bf170bf9a179ae310265f3872cf15f33711be54
and NOT0xe0ff31bf20f8fc9f8765313c16e8b4cda883ea99de2f2535c31a738f9c336893
for transaction 0xf59b273e232c919d0b3dec144322e8024d71cbd881bbcf707dba3332c987a6c0
Additional context
Some additional context which might be affecting this:
I noticed on the master branch the version of Geth is: github.com/ethereum/go-ethereum v1.13.2
I know there have been some changes which may require bumping go-ethereum to get this fixed.
Web3 Client Version:
Geth/linux-amd64/go1.21.13
via QuickNodeChain ID:
1329
Describe the bug
We noticed an inconsistency when calling
debug_traceBlockByNumber
with the tracer set toflatCallTracer
. This inconsistency occurs when there are traces for failed transactions within the block. The response returns an incorrectblockHash
within the output of this tracer.To Reproduce
We observed this issue occurring on multiple blocks.
To illustrate the problem, we will highlight two specific examples: blocks
79123882
and79124420
.When you request the block details using the
eth_getBlockByNumber
endpoint for each of the examples, you will get the following responses:Block Details Example
79123882
Block Details Example
79124420
These responses are all correct, and if you take note of each block hash, you'll have:
79123882
->0xf35379eeb07f128a728e2800da1b866fff83f88654702e18de12e8e023693381
79124420
->0x613665431b87da5cec698a7e4bf170bf9a179ae310265f3872cf15f33711be54
This is also highlighted in SEITrace explorer for blocks 79123882 and 79124420.
For each of these blocks, there was 1 EVM transaction, both of which failed.
79123882
had0x6acd4adb60084b0281ed40b5cce4fcf560cdcb42a883d0130001db70bb4c2420
79124420
had0xf59b273e232c919d0b3dec144322e8024d71cbd881bbcf707dba3332c987a6c0
Now the problem lies here, when we call the
debug_traceBlockByNumber
with the tracer set toflatCallTracer
as shown below:Tracing Block Example
79123882
Tracing Block Example
79124420
Notice the incorrect
blockHash
returned in the example responses when tracing the block.0x6acd4adb60084b0281ed40b5cce4fcf560cdcb42a883d0130001db70bb4c2420
(79123882
) we got theblockHash
0xe03a22247e778c76d23ab1063882fefa52e21f9193e7c1e6b5982664af7f98d3
0xf59b273e232c919d0b3dec144322e8024d71cbd881bbcf707dba3332c987a6c0
(79124420
) we got theblockHash
0xe0ff31bf20f8fc9f8765313c16e8b4cda883ea99de2f2535c31a738f9c336893
Both of which is returning incorrect
blockHash
fields.Expected behavior
The tracer result in the examples shown above should be returning the correct
blockHash
for these failed transactions. That is:When tracing block
79123882
;blockHash
should be0xf35379eeb07f128a728e2800da1b866fff83f88654702e18de12e8e023693381
0xe03a22247e778c76d23ab1063882fefa52e21f9193e7c1e6b5982664af7f98d3
0x6acd4adb60084b0281ed40b5cce4fcf560cdcb42a883d0130001db70bb4c2420
When tracing block
79124420
;blockHash
should be0x613665431b87da5cec698a7e4bf170bf9a179ae310265f3872cf15f33711be54
0xe0ff31bf20f8fc9f8765313c16e8b4cda883ea99de2f2535c31a738f9c336893
0xf59b273e232c919d0b3dec144322e8024d71cbd881bbcf707dba3332c987a6c0
Additional context
Some additional context which might be affecting this:
I noticed on the master branch the version of Geth is:
github.com/ethereum/go-ethereum v1.13.2
I know there have been some changes which may require bumping
go-ethereum
to get this fixed.For example:
I am speculating here and I am unsure if it is helpful, but maybe it's a good start to hone into the problem.
The text was updated successfully, but these errors were encountered: