Ethereum Block-Level Access Lists: How EIP-7928 Maps State

Ethereum wants to process and verify more work in parallel, but a validator cannot safely divide work it does not yet understand. Ethereum block-level access lists address that visibility problem: EIP-7928 gives each block a verifiable map of the state it touched and the values it produced. This guide connects that map to blockchain infrastructure basics without turning an active specification into a performance promise.

As of September 18, 2026, EIP-7928 is in Review. The Glamsterdam meta EIP schedules it for inclusion, while ethereum.org says the upgrade is testing on devnets and is expected in Q4 2026 without a confirmed mainnet date. Treat every field and timeline below as current protocol work, not activated mainnet behavior.

What Is a Block-Level Access List?

A block-level access list, or BAL, is an RLP-encoded record of the accounts and storage locations accessed while an Ethereum block executes. It also records post-transaction changes to storage, balances, nonces, and code. The block header commits to that data with block_access_list_hash, while execution clients store and exchange the full list separately.

Think of a BAL as the pick sheet for a busy warehouse. Before several crews start, the sheet identifies which shelves each order will visit. Crews handling different shelves can fetch in parallel. Orders touching the same shelf keep a safe order. Afterward, the completed sheet shows what inventory changed.

That analogy has an important limit: the builder does not get to publish an aspirational list. A validating client executes the block, derives the actual accesses, and checks them against the provided BAL. A missing or spurious entry can make the block invalid under the current EIP.

How EIP-7928 Records Ethereum State

The proposal organizes data by account address. Each AccountChanges entry can contain:

Field	What it records
storage_changes	Storage slots written and their post-transaction values
storage_reads	Slots read but not written
balance_changes	Post-transaction account balances when they change
nonce_changes	Post-transaction nonces
code_changes	New or modified runtime bytecode

Changes carry a block_access_index. Index 0 represents pre-execution system calls, indices 1 through n correspond to transactions in block order, and n + 1 represents post-execution system work and withdrawals. This ordering lets a client reconstruct the sequence of state changes instead of seeing only one final snapshot.

The encoding is deterministic. Accounts and storage keys are sorted, and the header stores the Keccak-256 hash of the RLP-encoded list. The Ethereum RLP guide explains why different clients need a canonical representation before they can agree on a hash.

EIP-7928 also includes read-only access. That matters because a node still performs database work when an opcode reads a balance, contract code, or storage slot without changing it. A dependency map that ignored reads could incorrectly treat two pieces of work as independent.

Why the Map Enables Parallel Work

Ethereum transactions share mutable state. Transaction B may read a value written by transaction A, so simply sending every transaction to a separate CPU core can produce the wrong result. Today, clients often discover those dependencies while executing in order.

BALs expose the dependency surface. The EIP identifies four intended capabilities:

1. Parallel disk reads. A client can fetch known accounts and slots concurrently instead of discovering them one by one.
2. Parallel transaction validation. Transactions with non-overlapping state can be grouped for parallel work while conflicts preserve ordering.
3. Parallel state-root computation. Known post-execution changes can be organized across independent state branches.
4. Executionless state updates. A syncing node can apply authenticated post-state changes without replaying every historical instruction.

These are architectural capabilities, not a fixed throughput guarantee. Hardware, client implementation, block composition, gas limits, and conflicting transactions all affect realized performance. A block in which many transactions touch the same popular contract is less parallel than a block of independent transfers.

EIP-7928 vs EIP-2930 Access Lists

The names are similar, but the mechanisms serve different layers.

Question	EIP-2930 transaction access list	EIP-7928 block-level access list
Who supplies it?	Transaction sender or tooling	Block builder, then verified by clients
Scope	One transaction	The full block plus system operations
Main purpose	Pre-warm listed state for gas accounting	Expose actual state dependencies and post-state changes
Must execution stay inside it?	No	The BAL must match actual block execution
Contains resulting values?	No	Yes, for recorded changes

An EIP-2930 access list is an optional, prepaid hint. A transaction can touch unlisted state and pay the applicable cold-access cost. A BAL is consensus-relevant block data: validators compare it with what execution really accessed. EIP-2930 entries are not automatically copied into a BAL; only state actually touched or changed belongs there.

How Nodes Receive and Validate BALs

During normal block processing, EIP-7928 extends the Engine API so the execution payload carries an RLP-encoded blockAccessList. The execution layer computes its hash, executes the block, builds the actual list, and rejects a mismatch.

Historical and peer-based synchronization need a network path too. EIP-8159, currently in Review, proposes the eth/71 protocol with GetBlockAccessLists and BlockAccessLists messages. A receiving client checks a BAL against the hash committed in the corresponding block header. The proposal keeps BAL delivery separate from the ordinary block body because not every sync strategy needs the data and BALs have a different retention policy.

The current EIP-7928 text requires execution clients to retain BALs for at least the weak subjectivity period, specified there as 3,533 epochs. Older full BAL data may be pruned while commitments remain. Operators should follow final client documentation rather than assume every node will serve every historical list.

What Changes for Users, Developers, and Node Operators

Regular users

There is no new asset, wallet migration, or token conversion. BALs are protocol plumbing. Any message asking you to send ETH or reveal a seed phrase to “enable EIP-7928” is a scam.

Application developers

Normal smart-contract semantics are not replaced by an application-facing allowlist. Developers should not assume a BAL lets a contract declare safe concurrency or bypass transaction order. The most immediate work belongs to low-level infrastructure—clients, tracing tools, block builders, sync systems, and data pipelines.

Node and infrastructure operators

Operators will need client releases that support the final payload, validation, storage, pruning, and peer-exchange rules. Resource planning should consider additional data handling as well as possible validation gains. Testnet results and client-specific guidance matter more than generalized throughput claims.

The neighboring Glamsterdam state-gas guide covers a different scaling constraint: pricing database growth and state access. BALs make work more visible; repricing tries to keep that work sustainable. Neither mechanism alone guarantees lower fees.

Risks and Limitations

• Specification risk: EIP-7928 and EIP-8159 remain in Review. Encoding, retention, limits, or edge-case rules can change before activation.
• Schedule risk: ethereum.org currently targets Q4 2026, but the mainnet activation date is not confirmed.
• Validation overhead: clients must collect, encode, hash, transmit, and compare BAL data. A speedup in one stage can add cost elsewhere.
• Data-availability risk: executionless updates require the relevant BAL to be available and authenticated. Pruned or unavailable data limits that sync path.
• Conflict limits: transactions that share heavily used state cannot all execute independently merely because a map exists.
• Implementation risk: different client interpretations can create invalid-block or chain-split risk, which is why devnets and interoperability tests matter.
• Market risk: protocol scaling work does not predict ETH's price. Crypto assets are volatile; use only funds you can afford to lose and do your own research.

Verification Checklist

When evaluating a BAL claim or implementation:

1. Check EIP-7928's current status and revision.
2. Confirm inclusion and activation through EIP-7773 and official client releases.
3. Distinguish “scheduled for inclusion” from “active on mainnet.”
4. Verify that the header commitment matches the RLP-encoded BAL.
5. Confirm the list matches actual state access, including read-only locations and system operations.
6. Test conflicting and non-conflicting transaction groups separately.
7. Measure end-to-end validation and sync cost rather than quoting one parallel benchmark.
8. Record client version, network, block number, and specification revision with results.

Frequently Asked Questions

Are BALs already active on Ethereum mainnet?

No. As of September 18, 2026, EIP-7928 is in Review and scheduled for Glamsterdam. Ethereum.org says Glamsterdam is testing on devnets, with Q4 2026 expected but no confirmed mainnet date.

Do BALs make every transaction execute in parallel?

No. They expose dependencies so clients can identify independent work. Transactions touching the same state still require ordering, and realized speed depends on the client and workload.

Can a wallet create an EIP-7928 list with eth_createAccessList?

No. eth_createAccessList relates to transaction-level EIP-2930 lists. An EIP-7928 BAL covers actual state access across a complete block and is verified as part of block processing.

Does executionless sync mean nodes stop verifying blocks?

No. It is a state-update path based on authenticated post-state data and protocol commitments, not permission to trust arbitrary values. Nodes still need the applicable consensus, header, and BAL validation rules.

Will BALs automatically lower gas fees?

No fixed reduction is guaranteed. BALs can create capacity headroom by improving validation and synchronization, but fees also depend on gas accounting, block limits, demand, and final client performance.

Primary Sources

• EIP-7928: Block-Level Access Lists
• EIP-7773: Glamsterdam hard-fork meta
• Ethereum.org: Glamsterdam roadmap
• EIP-8159: eth/71 Block Access List Exchange
• Ethereum.org: security roadmap and current progress

Bottom Line

EIP-7928 turns a block's hidden state dependencies into a deterministic, committed map. That map can support parallel reads and validation, faster state-root work, and executionless state updates—but only within the limits of real conflicts, available data, and correct client implementations.

Follow the official specifications through testnets and activation. This article is educational, not financial advice. Protocol plans can change, crypto assets can lose value, and you should independently verify current sources before acting (DYOR/NFA).