World Chain now streams EIP-7928 block access lists inside every flashblock, letting validators verify blocks in parallel while they are still being built, so throughput can scale toward a gigagas per second without raising the hardware requirements for block verifiers on the network.
A Primer on Full Block Access Lists
Every transaction reads and writes state; balances, nonces, contract storage, code. Today the only way for a validator to know which state a block touches, and what values result, is to re-execute the block one transaction at a time, in order. Execution is serial because transaction n +1 may depend on state written by transaction n. Serial re-execution sets a hard ceiling on how large blocks can get before validators fall behind.
Block Access Lists (BALs) makes the block's state accesses explicit. EIP-7928 defines a per-block structure that records for each account every balance, nonce, code change, and read or written storage slots along with their post-values. Each record carries the index of the transaction that caused it.
With the access list in hand, a validator no longer discovers dependencies by executing serially. It knows in advance what every transaction will read, so it can do three things:
- Execute transactions in parallel, seeding each worker's state view from the access list rather than from the output of the previous transaction.
- Compute the state root in the background, since the post-state is reconstructible from the list alone.
- Prewarm state, fetching the slots named in the list from disk ahead of execution.
Validation becomes a verification problem; execute, compare against what the list claimed, reject on divergence. A dishonest access list cannot make an invalid block valid. It can only waste a bounded amount of validation time.
Ethereum has selected EIP-7928 as a headliner of the Glamsterdam upgrade, on a roadmap that targets a 200M gas limit, about 16.7 Mgas/s of execution throughput. World Chain runs with block access lists today, unlocking block verification speeds which far exceed that target.
How full block access lists work on World Chain
World Chain produces a block every 2 seconds and streams each block in progress as 200 ms flashblocks: incremental payload deltas signed by the block builder. Full block access lists ride this pipeline. The design uses the upstream EIP-7928 primitives with one addition: each flashblock carries a slice of the block access list that its transactions produced, bounded by explicit min_tx_index and max_tx_index fields so slices compose into exactly one block-level list.
Construction happens in the block builder during normal execution. The builder's EVM records every state access as it executes transactions, tags each record with the transaction's global index, and emits the accumulated slice with each flashblock. The slice ships with an access_list_hash, a keccak commitment over the Recursive Length Prefix (RLP) encoding of the access list, inside the signed flashblock delta.
Validation happens on every follower as flashblocks arrive:
- Each incoming slice is checked against its claimed transaction index bounds.
- The transactions in the slice execute in parallel across a worker pool. Each worker reads its dependencies from the received access list rather than from the running state of prior transactions, which removes the serial chain that normally forces one-at-a-time replay. Results are reassembled in index order and compared against the claim.
- State root computation starts immediately from the claimed post-state, in the background, while execution is still in flight.
By the time the final flashblock arrives and the block seals, followers have already validated the block piece by piece. The engines payload validation at block sealing time then reduces to a check against work already performed rather than a full execution.
Two properties fall out of this design. First, verification cost is spread across the block interval instead of arriving as one lump at the end, which is what makes very large blocks practical inside a 2 second budget. Second, the access_list_hash in every signed flashblock is a commitment to the output of the state transition function at 200 ms cadence; the builder commits to exactly what its execution touched and changed throughout the block, and divergence is detected within one flashblock interval rather than one block interval.
Compared with the L1 deployment planned for Glamsterdam:
| Glamsterdam / L1 | World Chain | |
|---|---|---|
| Granularity | One list per 12s block | One list slice per 200ms flashblock |
| Commitment | bal_hash in the block header | access_list_hash in each signed flashblock delta |
| Activation | Hard fork | No fork required |
| Transaction indexing | Global per block | Global per block, plus per-slice index bounds |
| Distribution | Block body | Streamed over World Chain’s devp2p protocol |
The bandwidth cost is modest. An access list declares touched state and post-values, which is far smaller than a full execution witness. Under deliberately storage-heavy load we measured 2 to 3 KiB of access list per Mgas; compute-bound workloads produce proportionally smaller lists.
Benchmarking
We ran two load tests on World Chain test networks in the dev cluster driven by contender with storage-heavy transactions that cold-write and cold-read hundreds of distinct slots so that access lists grow with gas the way real state-heavy usage does.
Hardware in both cases is standard cloud infrastructure: Kubernetes (EKS) on AWS, r8i and r5 class instances, the reth container capped at 4 vCPU, and EBS gp3 storage at baseline provisioning (500 GiB, 3,000 IOPS, 125 MB/s, ext4). No io2, no instance-local NVMe.
Validation latency vs throughput. A 9 point sweep on Alphanet ramped sustained execution throughput from 1.7Mgas/s to 1 Ggas/s against a 2 billion gas limit, measuring per-flashblock validation latency on the following node. The result is sublinear with latency growing in the low-throughput regime and hitting a knee near 100 Mgas/s.
The plateau is the important property. Once the parallel validation pipeline is warm, adding more gas per block stops adding validation latency; work spreads across the worker pool and across the flashblock slices of the block. The validator remains real-time at every throughput we could generate and at saturation the limiting factor was the load harness and the sequencer, not the validator.
Conclusion
Full block access lists are enabled by a runtime flag rather than a hard fork, so the rollout does not require coordinated network upgrades.
- World Chain Sepolia: enabled July 27
- World Chain Mainnet: August 17
Full block access lists change the scaling equation. Instead of requiring every validator to verify increasingly larger blocks on increasingly larger hardware (as is the current paradigm on most Layer 2s today), block verification becomes a fully parallelizable process. Utilizing all available CPU cores on the machine verifying the blocks creates room for substantially more activity without raising the barrier to independent verification of the chain.