Skip to main content
netspecsEthereum networking

4.1.7.Block access lists

Stage
In progress
Validity
Active development outside the active set.
Sources
2 pinned sources

Block access lists record the accounts and storage used by block execution. EIP-7928 is in Review and EIP-8159 is Draft in the pinned sources. The fork schedule places this work in Glamsterdam, so this page is in progress.

Object and commitment

A block header in this proposed format contains block_access_list_hash after requests_hash. Its value is keccak256(rlp.encode(block_access_list)). Earlier headers omit the field.

The RLP list contains one entry per account, sorted by address. Each entry holds the account address, storage changes, storage reads, balance changes, nonce changes, and code changes. Storage keys and change indices have defined ascending orders. Each account appears once. A storage key appears at most once in each list and cannot appear in both storage_changes and storage_reads. Each change list has unique indices, and each slot-change list has at least one change. Duplicate account, storage, or change-index entries are invalid.

An access index of zero names pre-execution system work. Indices 1..n name transactions in block order. Index n+1 names post-execution system work and withdrawals. Accessed but unchanged accounts remain in the list with empty change lists.

eth/71 wire inventory

GetBlockAccessLists (0x12) requests lists by block hash.

BlockAccessLists (0x13) returns entries in request order. The RLP empty string marks a list that the peer cannot serve.

The response has a recommended 2 MiB soft limit. A single valid item may exceed that limit. A server may stop before adding another item.

Validation and failure handling

  • A receiver checks the RLP shape, ordering, uniqueness, and numeric bounds.
  • It hashes the encoded list and requires a match with the block header.
  • It treats 0x80 as unavailable data, not proof that the block has no access.
  • It rate-limits requests to control response amplification.
  • It accepts access lists only for blocks whose header format has the commitment.

Design rationale

Access lists travel apart from block bodies. This keeps normal block propagation small and lets a node fetch lists only when its sync or execution method needs them.

History

EIP-7928 defines the object and commitment. Draft EIP-8159 assigns the eth/71 request and response. Draft EIP-8189 also uses the object in snap/2.