eth/tracers: apply block header overrides correctly #32183
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lightclient
reviewed
Jul 10, 2025
rjl493456442
changed the title
rjl493456442
previously approved these changes
Jul 15, 2025
|
made the changes matt suggested! |
|
@shazam8253 forgot to push the new commit? |
Noticed that the parent hash was not being set. The way we do getHash relies on the parentHash to be cached correctly, so setting the parentHash after doing makeHeader fixes the issue.
|
I noticed that the parent hash was not being set. The way we do getHash relies on the parentHash to be cached correctly, so setting the parentHash after doing makeHeader fixes the issue. I have also added a seperate test as well. |
lightclient
reviewed
Jul 15, 2025
lightclient
approved these changes
Jul 16, 2025
howjmay
pushed a commit
to iotaledger/go-ethereum
that referenced
this pull request
Aug 27, 2025
Fixes ethereum#32175. This fixes the scenario where the blockhash opcode would return 0x0 during RPC simulations when using BlockOverrides with a future block number. The root cause was that BlockOverrides.Apply() only modified the vm.BlockContext, but GetHashFn() depends on the actual types.Header.Number to resolve valid historical block hashes. This caused a mismatch and resulted in incorrect behavior during trace and call simulations. --------- Co-authored-by: shantichanal <[email protected]> Co-authored-by: lightclient <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #32175.
This fixes the scenario where the blockhash opcode would return 0x0 during RPC simulations when using BlockOverrides with a future block number. The root cause was that BlockOverrides.Apply() only modified the vm.BlockContext, but GetHashFn() depends on the actual types.Header.Number to resolve valid historical block hashes. This caused a mismatch and resulted in incorrect behavior during trace and call simulations.
Changes:
Added a new ApplyHeader method to BlockOverrides, which mutates the *types.Header with overridden fields. Updated the RPC simulation/tracing paths to apply header overrides directly to the Header object before creating the EVM block context. This makes sure that there is consistency between BlockContext.BlockNumber and Header.Number to allow GetHashFn() to function correctly in simulations.
Tests
I reproduced the error in a dev chain on geth and ran the updated code against the issue to ensure correctness.