BAL, an access list that makes transaction verification parallel

Strawmap Glamsterdam (Early 2027) · BALs

Every block must carry a list of all accounts and storage slots the block accessed, along with their values after execution, and the hash of that list goes into the block header. Nodes can use this list to process data reads and transaction verification at the same time.

Why it is needed

Today, when an Ethereum node receives a new block, it executes the transactions inside one after another. This is because it cannot know which accounts and storage slots a transaction will touch until it runs it. There is an access list (EIP-2930) in which each transaction declares the addresses it will access in advance, but it is optional, so not every transaction uses it. BAL makes this list mandatory at the block level. If the list of all addresses and storage locations touched by the block, together with their post-execution values, arrives with the block, a node can read the needed data in bulk ahead of time and execute non-overlapping transactions concurrently. The computation of the state root, which summarizes the entire state into one value after execution, can also be split up. It also opens a path to updating state from the list alone, without executing the transactions directly. The original proposal explains that block execution time drops to the level of parallel reads and parallel execution. The Strawmap lists this item as a headliner of Glamsterdam, but that is only a projection and not a commitment. At the July 2026 developer call it was decided to include the related changes in devnet 7, and how long the list should be retained is still under discussion.

How it works

  1. Building the list The block builder gathers every account and storage location accessed while executing the transactions, along with their post-execution values, into a list. Only the hash of the list goes into the block header, and the list itself is delivered separately, outside the block body.
  2. Prefetching data A node that receives the block looks at the list before executing the transactions and reads the needed account and storage data from disk in bulk ahead of time.
  3. Concurrent execution and verification Transactions that do not touch the same account or storage location are executed concurrently. The execution results are checked against the list. If the hash of the list differs from the header value, the block is treated as invalid.

Related EIPs

← Roadmap