
ethereum
EIP-7928 Explained: How Block-Level Access Lists Bring Parallel Execution to Ethereum L1
EIP-7928 introduces Block-Level Access Lists that record every account and storage slot a block touches, letting Ethereum clients read and validate transactions in parallel. It ships as a headliner of the Glamsterdam upgrade, targeted for Q4 2026, and supports a gas limit increase from 60M toward 200M.
SEP 08, 2026
Last updated SEP 08, 2026 · V1
TL;DR
- Block-Level Access Lists (EIP-7928) give Ethereum parallel transaction execution, meaning multiple transactions run at once. Everstake tracks the change as a validator across 130+ networks to date.
- Ethereum today runs transactions one after another, because no node knows in advance which data a transaction will read or write. A BAL lists every account and storage slot a block touches upfront, so clients can read and verify in parallel.
- EIP-7928 is a headliner of the Glamsterdam upgrade, next to enshrined proposer-builder separation (ePBS). It supports a planned block gas limit increase from 60M toward 200M, and a longer-term 10,000 transactions per second (TPS) aspiration.
- A Geth proof of concept measured a 42% cut in mean block processing time. Treat the gas and TPS figures as targets, because real throughput depends on client software and block contents.
- Mainnet activation is targeted for Q4 2026, though the date is not final. ETH holders take no action, while node operators and validators update their clients.
- Parallel L1 execution complements L2 rollups, and stays one track in Ethereum’s wider 2026 scaling plan.
What is EIP-7928?
EIP-7928 defines a Block-Level Access List (BAL), a record in every block of all accounts and storage slots the block accesses, together with their post-execution values. The spec makes this list a validity condition, so an incorrect BAL invalidates the block.
Storage slots are the individual locations where a smart contract keeps its data. Post-execution values are what those locations hold after the block runs.
The status is Draft, Standards Track (Core), scheduled for inclusion in Glamsterdam on the Amsterdam execution layer.
Authors include Toni Wahrstätter, Dankrad Feist, Francesco D’Amato, and Jochem Brouwer. The proposal was created in March 2025.
Why Ethereum cannot parallelize today
Ethereum executes transactions serially because a node cannot predict which accounts or storage slots a transaction will access until it runs it. Each transaction waits for the previous one to finish.
Congestion turns serial execution into a processing traffic jam. The Ethereum Virtual Machine (EVM) interleaves disk reads (IO) with computation, one transaction at a time.
Picture a warehouse worker with a shopping list that only reveals the next aisle after the current item is picked. Planning a faster route is impossible, because the destinations stay hidden until each step completes.
Blind execution caps the block gas limit, the ceiling on how much computing work each block can hold. Faster, more predictable validation is a precondition for the 60M-toward-200M target.
Predictable validation also supports decentralization. When modest hardware can validate large blocks by reading state in parallel, home and solo stakers keep pace as capacity grows.
How Block-Level Access Lists work
Validators re-run every block to verify the proposer’s work. BALs hand them the access map before that re-run, so clients read state and check transactions in parallel.
The block builder assembles the list, and the network rejects any block whose BAL does not match execution.

According to the EIP-7928 abstract, the mechanism enables:
- parallel disk reads,
- parallel transaction validation,
- parallel state-root computation,
- executionless state updates.
Together, these let a client verify one block by working on separate pieces at the same time.
A new block header field, block_access_list_hash, holds the Keccak-256 hash of the RLP-encoded BAL. Clients verify the body against this hash.
Independent transactions run at the same time across cores. A HackMD deep dive cites historical analysis that 60–80% of transactions touch disjoint slots, meaning separate data that cannot collide.
The remaining 20–40% share state and depend on each other. Post-transaction values in the BAL let clients resolve those dependencies without waiting on serial disk lookups.
An ETH/USDC swap and a separate NFT mint touch different accounts. A client can process both simultaneously on separate cores.
BALs vs. EIP-2930 access lists
EIP-2930 and EIP-7928 are frequently confused, yet they differ in scope and enforcement. EIP-2930 access lists are optional and set per transaction, while BALs are protocol-mandated and set per block.
A BAL records only the state touched during execution, so EIP-2930 pre-declarations count only when the block accesses them. That rule corrects a common misconception.
| Property | EIP-2930 access list | EIP-7928 BAL |
| Scope | Per transaction | Per block |
| Enforcement | Optional | Protocol-mandated |
| Content | Address and key hint | Accounts, slots, post-values |
| What is recorded | As submitted by sender | Only state touched at runtime |
| Purpose | Warm-access gas discount | Parallel execution and faster validation |
Parallelizing L1 vs. relying on Layer 2
Layer 2 (L2) rollups are separate networks that process transactions off the main chain, then post the results back to it. Rollups such as Base, Arbitrum, and Optimism hold tens of billions in total value locked (TVL).
Ethereum still scales its base layer. A faster, higher-capacity L1 lowers the cost of posting data and reduces congestion for the rollups that settle on it.
BALs fall under the “Scale L1” objective of the roadmap. This track runs next to blob scaling from Fusaka and PeerDAS, which lowers the cost for rollups to store their data.
L1 parallelization complements L2 scaling. Rollups remain the primary path to low-cost execution at volume.
BALs within the Glamsterdam upgrade
Glamsterdam upgrades two layers at once: the execution layer, where transactions run, and the consensus layer, where validators agree on blocks. It combines the Gloas consensus upgrade and the Amsterdam execution upgrade.
Core developers call it the biggest fork since The Merge, Ethereum’s 2022 move to proof of stake.
BALs ship next to the other headliner, ePBS (EIP-7732), which moves block-building into the protocol. A separate gas-repricing package, which adjusts the cost of common operations, may lower L1 fees by around 78.6% in some estimates.
A supporting proposal, EIP-8159, adds a network message so nodes can share BALs while syncing.
Everstake covers the full fork in its Glamsterdam upgrade overview. The 10,000 TPS number traces back to the five north stars of the Strawmap, published by Justin Drake on February 25, 2026.
Performance, overhead, and trade-offs
Early benchmarks are promising but preliminary. A Geth proof of concept over 120 blocks recorded a 42% reduction in mean block processing time and a 69% improvement in storage reads.
Account read time rose 70% and execution time rose 7% in the same tests. The authors marked both as open items for further work.
BAL size stays modest. A BAL size analysis found a median block produces a 42.6 KB compressed list, with the 95th percentile at 73.7 KB.
| Metric | Value | Note |
| Mean block processing | 708ms to 409ms | Geth PoC, 120 blocks |
| Storage read time | 477ms to 147ms | Geth PoC |
| Median BAL size | 42.6 KB compressed | 178-tx block |
| 95th-percentile BAL | 73.7 KB compressed | 286-tx block |
| Added bandwidth | ~300.2 MB/day | at 12-second blocks |
Engineering challenges remain across client teams. Edge cases include:
- out-of-gas calls that must stay out of the BAL,
- no-op SSTORE writes that record but change no state root,
- index-width choices that future-proof larger blocks.
The Ethereum Foundation notes real throughput depends on client performance and block contents. A single PoC number is not a settled result.
What it means for Ethereum community
BALs change work for operators and builders, while holders take no action. The table below maps each group.
| Audience | What changes |
| ETH holders | None. Balances and addresses are unchanged |
| Stakers and delegators | None. The validator operator updates clients |
| Node operators | Check storage IOPS and latency; update CL and EL clients |
| Developers | No redeployment; account for gas-repricing changes |
Node operators feel the hardware angle most. Parallel disk reads reward faster storage, so operators check disk read speed (IOPS) and latency before activation.
Both the consensus-layer (CL) and execution-layer (EL) client software must be updated, and ePBS tightens block timing.
Developers keep their contracts as deployed. Gas-repricing proposals change some costs, so teams should test on public networks before mainnet.
For institutions, the change is an infrastructure question about operations and client readiness. Due diligence on a validator now includes:
- readiness for parallel execution,
- client-update discipline,
- the new Payload Timeliness Committee (PTC) duty from ePBS.
Everstake runs white-label validators for institutional clients across 130+ networks to date, with 99.98% uptime and zero material slashing events on major networks since 2018. That track record is the kind of operational baseline institutions weigh when a fork of this size approaches.
Glamsterdam is a hard fork, a mandatory upgrade every node must adopt to stay on the network. Everstake explains the distinction in its hard fork explainer.
Timeline and status
Dates are not finalized and have moved twice, from H1 2026 to Q4 2026. Multiple client teams are prototyping EIP-7928, including:
- Geth,
- Besu,
- Nethermind,
- Reth.
The public Platåberget testnet, a practice network that mirrors Ethereum, forked on August 20, 2026. At ACDC #185, developers proposed a Sepolia fork for September 28, 2026 and a Hoodi fork near October 26, 2026.
Mainnet activation is targeted for Q4 2026, contingent on stable devnets, the short-lived developer networks that run first. The upgrade schedule is the place to verify current block heights before publishing any date.
The parallelization idea is already spreading. BNB Chain integrated a BAL variant through BEP-592 and reported an 18.6% throughput improvement in lab tests.
FAQ
What is EIP-7928 in simple terms?
EIP-7928 adds a Block-Level Access List to every Ethereum block. It lets nodes read state and validate transactions in parallel.
What is the difference between a BAL and an EIP-2930 access list?
EIP-2930 access lists are optional and set per transaction, while EIP-7928 BALs are mandatory and set per block. BAL records the state touched at runtime, and sender pre-declarations are ignored.
Will BALs make Ethereum reach 10,000 TPS?
10,000 TPS is a long-term Ethereum L1 aspiration measured years out. It is a theoretical ceiling that depends on transaction mix, client performance, and the 60M-toward-200M gas path, so treat it as a target.
Does parallel execution replace Layer 2s?
No. Parallel L1 execution complements rollups, and Everstake points out that L2 networks remain the main route to low-cost execution at volume.
Do I need to do anything as an ETH holder or staker?
No. ETH holders and delegators take no action, since balances, addresses, and keys are unchanged. Everstake updates its validator clients in time of the fork on behalf of its delegators.
When does EIP-7928 go live?
EIP-7928 is targeted for Q4 2026 on mainnet, with a Sepolia fork proposed for September 28, 2026. Everstake recommends verifying the latest Glamsterdam schedule, because these dates are not final.
Looking forward
BALs turn Ethereum’s single-threaded execution into a parallel model by making state access explicit and enforced at the block level. That is a structural modernization of the block, and a foundation for the network’s 2026 scaling targets.
EIP-7928 works as part of a package. It pairs with ePBS, gas repricing, and the wider issuance and staking debate shaping Ethereum this year.
Share with your network