EIP 7928 Block Access Lists Improve Ethereum Forensics

Ethereum’s next execution changes will create more data about what a block touched. A small Geth patch asks an important question: when a block fails validation, should the client keep that evidence or discard the most useful part?

A bad block needs all its evidence

Geth already stores invalid blocks so developers can inspect failures after a validation check rejects them. The client keeps up to ten bad blocks. That is a small rolling sample, but it can be enough to reproduce a fault and compare behavior across clients.

EIP 7928 changes what complete evidence means. Its proposed block access list records the accounts and storage locations touched during execution, plus resulting state changes. The block header commits to a hash of the list, while the full list travels separately through the Engine API. It is not part of the normal block body.

That separation creates a forensic gap. A client can retain the header and transactions from an invalid block while losing the access list that helped make it invalid. The proposed Geth change closes that gap by storing the list beside the bad block and restoring it when the block is read later.

What EIP 7928 actually records

EIP 7928 entered the standards process on March 31, 2025, and remains in Review. It covers storage reads, storage changes, account value changes, nonce changes, and code changes. It also records accounts that were touched but left unchanged. Missing or extra entries can make a block invalid.

The ordering is deterministic. Index 0 represents system activity before transaction execution. Indexes 1 through n represent transactions in block order. Index n plus 1 represents activity after execution, including withdrawals. Accounts and storage keys must also follow defined sorting rules.

The goal is not merely better logging. A complete list can support parallel disk reads, parallel transaction checks, parallel state root work, and state updates without full execution. The proposal cites 60 to 80 percent of transactions accessing separate storage slots, which gives parallel work room to help.

There is a cost. Analysis in the proposal estimates an average compressed list near 72.4 KiB for a 60 million gas block limit. The item count is bounded by the block gas limit divided by 2000. Execution clients must retain the lists for at least 3533 epochs. Those are engineering costs, not footnotes.

The patch is small and compatibility matters

The current Geth proposal changes two files with 22 additions and 5 deletions. It adds an optional block access list field to the stored bad block record. New records keep the list. Old records can still decode because the new field is optional.

That compatibility choice matters more than the line count. Operators can already have old bad block records in a database. A mandatory new field could turn a diagnostic improvement into a database decoding problem. The optional encoding avoids that trap.

The same patch also makes bad block summaries more explicit. Receipt logs would show each address, its topics, and its data. Chain configuration output would use the normal string form. Together, the changes aim to preserve both machine readable context and a more useful human summary.

Still, approval is not the same as proof. The visible patch adds no test file. Useful coverage would show that old records still decode, new lists survive a write and read cycle, an absent list remains valid, and the ten block retention rule still behaves as expected.

Version 1.17.6 is a separate clock

A second Geth change opened the version 1.17.6 development cycle on July 27, 2026. It changes the patch version from 5 to 6 and marks the build as unstable. The associated milestone had three open items and no closed items at the time of inspection.

That is release administration, not a release announcement. The forensic patch was also open. Nothing in the available public state proves it will ship in version 1.17.6. Treating nearby changes as one promise would be convenient, and wrong.

What to watch

First, watch whether the storage change gains explicit compatibility and round trip tests before merge. Bad block tooling is used when normal assumptions have already failed. That is exactly where untested serialization is least welcome.

Second, watch the network upgrade path for EIP 7928. The proposal requires a hard fork and changes both the block header and Engine API. Until an upgrade adopts it, the performance estimates and storage burden remain projections.

Finally, measure diagnosis time. Invalid blocks should be rare, so the average case says little. If failures cluster near an upgrade, a ten block window may rotate quickly. The useful metric is how fast complete evidence turns a rejected payload into a known cause.