Block-Level Access Lists: Ethereum Scaling Proposal

The name sounds bureaucratic. The idea is concrete: before a client finishes processing a block, it should have a structured record of every account and storage location the block touched. That record gives client software a map of the work ahead instead of forcing every part of the system to discover dependencies at the same time.

This is not a promise of a magic transaction-per-second number. As of July 29, 2026, EIP-7928 is marked "Review" in the Ethereum Improvement Proposals repository. It is a proposal for making block processing less serial, more inspectable, and easier to split across hardware resources when the surrounding protocol work is ready.

What are block-level access lists?

EIP-7928 defines a block-level access list, often shortened to BAL, as a record of accounts and storage locations accessed during block execution, together with post-execution values where state changed. The proposal says that record can support parallel disk reads, parallel transaction validation, parallel state-root computation, and state updates without replaying every transaction.

The distinction between a block-level list and an old transaction-level hint matters. EIP-2930 introduced optional access lists for individual transactions, but EIP-7928 notes that they are not enforced. A BAL would cover what was actually touched across the entire block. It must include accessed accounts even when they did not change, such as a contract inspected by an opcode or the recipient of a zero-value transfer.

That requirement turns the list into more than an optimization suggestion. A client can compare the supplied list with the access pattern it produces while executing the block. If the two do not match, the proposal treats the block as invalid.

How would EIP-7928 change block processing?

Today, an execution client often learns which data it needs as it runs a transaction. That makes it difficult to schedule disk work and transaction checks in parallel. With an accurate BAL, a client can prepare independent reads and identify work that does not contend for the same state.

The proposal adds a block_access_list_hash to the block header. The proposed execution payload carries the full RLP-encoded list through the Engine API, while the header commits to it with a Keccak-256 hash. In the draft, the list is not part of the block body and execution clients retain it separately.

EIP-7928 also constrains list size through the block gas limit rather than a fixed item count. Its current design assigns an item cost of 2,000 gas for each address or storage key, then requires the list to fit within that gas-derived budget. This is a useful design choice: the metadata grows with the work a block is already allowed to perform instead of creating a separate unlimited data channel.

For node operators, the most relevant outcome is not that every transaction suddenly runs in parallel. It is that clients gain an explicit dependency record for disk I/O, validation, and state-root work. As of July 29, 2026, the proposal says clients must retain BALs for at least the weak-subjectivity period, specified as 3,533 epochs, to support synchronization after a temporary absence.

Why is this part of Ethereum's 2026 scaling plan?

The Ethereum Foundation's February 18, 2026 protocol update merged its separate Scale L1 and Scale Blobs initiatives into one Scale track. The stated reason was practical: execution capacity, data availability, networking, and consensus changes increasingly touch the same client code and cannot be planned as isolated projects.

That combined track names block-level access lists as support for raising the gas limit toward and beyond 100 million, alongside client benchmarking. It also names EIP-7732, enshrined proposer-builder separation, as a Glamsterdam scaling component. EIP-7732 separates consensus-block validation from execution-payload construction and validation, which complements the execution map proposed by EIP-7928.

The sequencing matters. Ethereum's official roadmap places Pectra on May 7, 2025 and Fusaka on December 3, 2025 before Glamsterdam and Hegotá in H2 2026. Pectra raised blob targets from three to six, with a maximum of nine. Fusaka introduced PeerDAS; around that milestone, the roadmap records a default gas limit of about 60 million. Those earlier changes address data availability and capacity; BALs aim at how clients process a fuller block without making node operation needlessly harder.

What does this mean for rollups and application developers?

For rollups, the value is indirect but important. Rollups depend on Ethereum for settlement and data availability. The Ethereum scaling roadmap explains that rollups batch transactions offchain and publish results to Ethereum; it also describes the long path from cheaper blob data toward fuller data availability sampling and more decentralized sequencers and provers.

Block-level access lists do not lower a rollup fee on their own. They are infrastructure for clients that must validate larger or more complex blocks predictably. If the proposal and its companion changes mature, they could reduce execution bottlenecks. It is reasonable to infer that this would make coordinated gas-limit and data-capacity work easier, but the proposal does not guarantee a particular outcome.

Application developers should read the proposal as a reason to keep state access disciplined, not as a new application-layer API. Contracts that create heavy, unpredictable access patterns still impose real costs on the network. The benefit comes when clients can see the relationships among reads, writes, calls, balances, nonces, and code changes with enough precision to schedule work safely.

For readers following Ethereum's broader upgrade cycle, our earlier overview of the Glamsterdam and Hegotá roadmap provides the wider context. The Layer 2 consolidation analysis explains why improvements to settlement infrastructure can matter across many rollup ecosystems, not only one chain.

What should you watch before Glamsterdam?

Start with status, not headlines. As of July 29, 2026, EIP-7928 remains under review, so its exact format and its place in a final fork can change. The Ethereum Foundation's own 2026 Protocol priorities update is clear that the goal is a coordinated Scale track, not a guarantee that every proposed feature ships on a fixed date.

The practical decision rule is simple. Treat a BAL as meaningful only when three things line up: the proposal advances beyond review, execution clients demonstrate compatible implementations, and the fork scope confirms how it connects with ePBS and gas-limit work. Until then, it is a well-specified path for client efficiency, not a completed Ethereum upgrade.