EIP-7928 BAL does not record EIP-4788 timestamp read operation for invalid queries

[raxhvl]

Metadata

• Hardfork: Amsterdam

What was wrong?

When an invalid timestamp is queried for EIP-4788 beacon block root, the call reverts but the timestamp slot is NOT recorded as a storage read.

Sources

If no changes remain, addresses are included with empty lists; if storage was read, the corresponding keys MUST appear in storage_reads.

Additional Context

Test case

Function Name	Goal	Setup	Expectation
test_bal_4788_query	Ensure BAL captures storage reads when querying beacon root (valid and invalid queries)	Parameterized test: Block 1 stores beacon root at timestamp 12. Block 2 queries timestamp (valid=12, invalid=0). Valid query: reads both timestamp and root slots, writes returned value. Invalid query: reads only timestamp slot (contract reverts), query contract has implicit SLOAD recorded (SSTORE(0,0) is no-op).	Block 1 BAL: System call writes. Block 2 BAL MUST include at block_access_index=0: System call writes for block 2. Valid case at block_access_index=1: BEACON_ROOTS_ADDRESS with storage_reads [timestamp_slot, root_slot], query contract with storage_changes. Invalid case at block_access_index=1: BEACON_ROOTS_ADDRESS with storage_reads [timestamp_slot only], query contract with storage_reads [0].

Gets the following error:

BlockAccessListValidationError: Storage read 0 not found or not in correct order. Actual reads: []

cc: @nerolation @fselmo

[fselmo]

@raxhvl, I'm not sure the exact logic of the contract but the pseudocode in the EIP explicitly states that if the 32-byte input is 0 for the timestamp, it reverts without any implicit SLOAD.

if to_uint256_be(evm.calldata) == 0:
    evm.revert()

This will be dependent on the code in the contract as the SSTORE logic for this should behave much like any other SSTORE. I tried my hand locally a bit and it seems to record my reads that are not 0.

Very quick and dirty attempt:

invalid_timestamp = ("0xdeadbeef").encode()
invalid_timestamp_calldata = invalid_timestamp.ljust(32, b'\x00')
storage_to_read = (
    int.from_bytes(invalid_timestamp_calldata) % 8191
).to_bytes(32, 'big')

tx = Transaction(
    sender=pre.fund_eoa(),
    to=BEACON_ROOTS_ADDRESS,
    value=0,
    data=invalid_timestamp_calldata,
    gas_limit=100_000,
)

blockchain_test(
    pre=pre,
    blocks=[
        Block(
            txs=[tx],
            expected_block_access_list=BlockAccessListExpectation(
                account_expectations={
                    BEACON_ROOTS_ADDRESS: BalAccountExpectation(
                        storage_reads=[storage_to_read],
                    ),
                }
            ),
        )
    ],
    post={},
)

[fselmo]

Changing the above to 0 timestamp indeed does not record the read though. Would be a good test imo, though we should all be using the same contract. Good coverage nonetheless.

[raxhvl]

There are two cases:

1. Malformed timestamp - size is not exactly 32 bytes.
2. Invalid timestamp - valid size but timestamp is out of range.

(1) should revert before state access hence no read. (2) Reads state to validate the timestamp and hence must record
read.

The issue is about (2) and was reported using this test case.

I will have a separate test for (1).