Ethereum has executed transactions sequentially since day one — not by philosophical choice, but because nodes had no reliable way to know which storage slots a transaction would touch until after it ran. Without that information upfront, parallelizing across transactions risks one thread overwriting state another is reading. The result: every block is processed like a single-core machine, regardless of how many cores the node has.
EIP-7928, confirmed for Ethereum's Glamsterdam upgrade targeting H1 2026, addresses this directly. It introduces Block-Level Access Lists (BALs) — structures that record every state access made during a block, attached to the block body as a validity condition. Here is how it works, and what it means if you are building on Ethereum today.
Why the EVM Has Always Been Single-Threaded
When a transaction hits an SLOAD opcode, the node fetches the storage value from disk before continuing. With sequential processing, these disk reads are dead time for every other pending transaction. Block builders have worked around this with state caches and prewarming strategies, but none of these are consensus-level solutions.
The throughput ceiling stays tied to the slowest sequential chain of state dependencies in the block. Adding more cores to the node does not help because the validation model mandates executing transactions in order — each transaction's output can become the next transaction's input, so you cannot safely run them independently without knowing the dependency graph ahead of time.
What Block-Level Access Lists Record
A BAL is a deterministic map of every account address and storage key accessed during a block, including their post-execution values. It is attached to the block body as a new field and its Keccak-256 hash appears in the block header. The BAL is not a hint — it is a consensus validity condition. If the BAL does not exactly match the actual execution trace, the block is invalid.
Each entry is tagged with a BlockAccessIndex: a uint16 indicating when the access occurred (index 0 for pre-execution system calls, 1 through N for each transaction in order, N+1 for post-execution operations). Write operations record value_after, producing a verifiable state diff stream for the entire block.
The overhead is bounded by the block gas limit: bal_items ≤ block_gas_limit / 2000. Empirical analysis of existing blocks puts average BAL size at around 72 KB compressed — smaller than worst-case calldata blocks.
How BALs Enable Parallel Execution on Validating Nodes
With a valid BAL, the execution pipeline on receiving nodes changes substantially:
Before: Parse block → Execute tx1 (fetch state + run EVM) → Execute tx2 → ...
After: Parse block → Parse BAL → Prefetch ALL referenced state in parallel
→ Build conflict graph → Execute independent tx clusters in parallelBefore the EVM starts, the client fires asynchronous disk reads for every address and storage key listed in the BAL simultaneously. The conflict graph — built from the BlockAccessIndex tags — identifies which transactions touch overlapping state. Research on existing Ethereum blocks suggests 60–80% of transactions access entirely disjoint storage, meaning those can run on separate cores without coordination. Transactions that do share state still execute in dependency order, but they benefit from eliminated disk waits.
The BAL is generated by the block builder during block construction and must be exact: if a transaction fails before accessing state (for example, out-of-gas during a CALL), those reads must not appear in the BAL. Block builders need to couple BAL generation tightly with the EVM interpreter loop.
What Glamsterdam Actually Changes for dApp Developers
For most smart contract and dApp developers, the immediate answer is: nothing you need to do now, meaningful improvements later.
BALs are built by block builders and validated by consensus nodes. Your Solidity code compiles and deploys without modification. The change happens entirely in the block production and validation pipeline.
Where you will feel the impact:
Gas costs and throughput. Parallel execution lets Ethereum process more transactions on the same hardware. Combined with Glamsterdam's gas limit increase — targeting 60M initially with higher limits under active testing — this reduces L1 gas costs. Patterns previously reserved for L2s may become economical on L1.
Local block builders and devnets. Because the BAL is a validity condition, any block producer in your development stack will need BAL support after Glamsterdam ships. If your team uses custom block builders for integration or end-to-end tests, plan for that migration before the testnet activation.
End-to-end test coverage becomes more valuable, not less. As the block construction pipeline changes, tests that mock at the RPC layer will not catch issues specific to BAL-aware block producers. Full-stack tests that exercise the actual client-to-wallet path — the kind @avalix/chroma enables with real wallet extensions rather than simulated RPC responses — remain the most reliable layer for validating that your transaction flows work as expected under changing infrastructure.
What to Watch Before Glamsterdam Ships
Glamsterdam is currently running on devnets, with public testnet activation on Holesky and Sepolia expected in the months ahead. The April 2026 checkpoint update noted that ePBS — the other Glamsterdam headliner — is proving more complex than anticipated, making a Q2 2026 mainnet launch optimistic. A more realistic target is H2 2026.
If you maintain infrastructure-level code — indexers, block explorers, raw block processors — EIP-7928 changes the block body format and adds a new header field. Application developers can wait and watch; block builder and client teams should start planning now.
For everyone else: Glamsterdam is good news. More throughput, lower gas, and a stronger execution foundation. The machine is about to change — understanding how it changes is enough for now.