Test BLOCKHASH State Test Recency¶
Documentation for tests/frontier/opcodes/test_blockhash_state_test_recency.py@5f132e7c.
Generate fixtures for these test cases for Cancun with:
fill -v tests/frontier/opcodes/test_blockhash_state_test_recency.py --fork Cancun
State-test regression for the BLOCKHASH (0x40) opcode recency window.
In a state test, nethermind returns a non-zero hash for
BLOCKHASH(0) even when block 0 lies far outside the recency window (256
blocks pre-Prague, 8191 via EIP-2935 from Prague). eels (the reference),
go-ethereum, besu, erigon, evmone and reth all correctly return 0.
Root cause (nethermind, state-test only):
src/Nethermind/Ethereum.Test.Base/TestBlockhashProvider.cs implements::
number != 0 ? Keccak.Zero : Keccak.Compute(number.ToString())
It performs no recency-window check, and the opcode handler
InstructionBlockHash (in EvmInstructions.Environment.cs) delegates
that check to the provider -- it only rejects number >= current. So
BLOCKHASH(0) returns keccak256("0") regardless of how ancient block
0 is. Nethermind's production BlockhashProvider does enforce the
window, so this is a state-test tooling bug, not a mainnet consensus bug --
but it makes nethermind diverge under differential state-test fuzzing.
Test Functions Overview¶
| Name | Type | Cases (Cancun) | Description |
|---|---|---|---|
test_blockhash_zero_in_window_control |
state_test | 1 | In-window control: BLOCKHASH(0) returns the block-0 hash at block 1. |
test_blockhash_zero_out_of_window |
state_test | 4 | BLOCKHASH(0) must be 0 when block 0 is outside the recency window. |