Skip to content

test(debug_getRawReceipts): use post-Byzantium block for get-block-n test#742

Open
mattsse wants to merge 1 commit intoethereum:mainfrom
mattsse:fix/debug-raw-receipts-post-byzantium
Open

test(debug_getRawReceipts): use post-Byzantium block for get-block-n test#742
mattsse wants to merge 1 commit intoethereum:mainfrom
mattsse:fix/debug-raw-receipts-post-byzantium

Conversation

@mattsse
Copy link

@mattsse mattsse commented Jan 25, 2026

Summary

Block 0x3 is pre-Byzantium (byzantiumBlock=9 in the test chain's genesis), which means receipts at that block use the legacy state root encoding instead of EIP-658 status code encoding.

This causes clients that only support EIP-658 status encoding (like reth) to fail the debug_getRawReceipts/get-block-n test, even though they correctly implement the EIP-658 receipt format.

Changes

Change the test to use block 0xa (10) which is post-Byzantium, ensuring the test validates EIP-658 status encoding which is what all modern clients use post-mainnet-Byzantium.

Context

  • Byzantium activated on mainnet at block 4,370,000 (Oct 2017)
  • Pre-Byzantium receipt encoding with state root is extremely rare in practice
  • Reth deliberately doesn't store pre-Byzantium state roots as discussed in paradigmxyz/reth#853

This change maintains test coverage while aligning with modern client implementations.

…test

Block 0x3 is pre-Byzantium (byzantiumBlock=9 in the test chain), which means
receipts use state root instead of EIP-658 status code. This causes clients
that only support EIP-658 status encoding (like reth) to fail the test.

Change the test to use block 0xa (10) which is post-Byzantium, ensuring the
test validates EIP-658 status encoding which is what modern clients use.

Amp-Thread-ID: https://ampcode.com/threads/T-019bf5ac-dd59-76c0-8ba8-8739e84b6a33
Co-authored-by: Amp <amp@ampcode.com>
@MysticRyuujin
Copy link

On the one hand, I understand the reluctance to support legacy stuff, but on the other hand, this is literally part of the blockchain's history and it does not change the fact that if clients request legacy receipts from Reth or Erigon they get a different response with different values. This is not fixing anything, it's just sweeping the API response differences under the rug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants