The problem it targets
Blockchain scaling gets discussed almost entirely in terms of throughput: how many transactions per second a network can push through. But there’s a quieter, harder problem sitting underneath that: making sure independent validators can actually verify that throughput without needing ever-more-expensive hardware. Solve throughput without solving verification, and you’ve just centralized the network onto whoever can afford the biggest machine. World Chain‘s rollout of full Block Access Lists (BALs) this August is a well-targeted answer to that second, harder problem.
The underlying primitive, EIP-7928, is serious enough that Ethereum itself has picked it as a headline feature of the upcoming Glamsterdam hard fork. What’s notable is that World Chain didn’t wait around for that fork. It’s running the idea in production on an L2 today. That’s a good use case for rollups: a place to prove out execution ideas that are too risky to ship straight to Ethereum L1, and World Chain deserves credit for actually being one of the first to take that step rather than just talking about it.
What actually changes, and why it’s smart
Today, EVM validators verify a block the slow way: re-executing every transaction in order, because transaction n+1 might depend on state that transaction n just changed. That serial chain is the real ceiling on block size, not compute power, but the fact that you can’t parallelize replay when you don’t know the dependencies ahead of time.
EIP-7928’s fix is elegant: make those dependencies explicit before execution starts. Every account touched, every storage slot read or written, and the resulting values are recorded and tagged to the transaction responsible. A validator then knows in advance exactly what each transaction will need, so it can farm work across CPU cores, prefetch state from disk, and start computing the state root in the background, all before the block is even finished being built.
World Chain’s own contribution on top of this is genuinely nice engineering. It produces a block every two seconds but streams incremental “flashblocks” roughly every 200 milliseconds, and a matching slice of the access list, cleanly bounded by transaction-index ranges, rides along with each one. The effect is that validators aren’t handed one big lump of verification work at the end of the block. They’ve been chewing through it continuously, in small pieces, the whole time. By the moment the block seals, most of the verification is already done. That’s a nice piece of systems design, not just a spec implementation.
What the benchmark shows
World Chain’s reported numbers are the best evidence yet that this approach works as intended: sustained execution throughput scaling from 1.7 Mgas/s up to 1 Ggas/s while staying real-time, with validation latency actually plateauing rather than climbing as load increased. This means the parallel pipeline was soaking up the extra work rather than falling behind. At the very top of the range, it wasn’t the validator that ran out of headroom; it was the load generator and sequencer. That’s about as clean a signal as a benchmark can give that the bottleneck has genuinely moved.
Worth keeping in mind: this was measured on a dev-cluster testnet with a deliberately storage-heavy synthetic workload and a validator intentionally capped at 4 vCPUs. It was a controlled test rather than organic mainnet traffic. That’s a normal and sensible way to stress-test an architecture before wider rollout, and it means the real proof point is still ahead: how this performs once real, varied mainnet activity and full network-wide propagation are in the mix. Given how solid the underlying design is, that’s a promising position to be testing from.
Why it matters beyond World Chain
There’s a broader story here too. Block Access Lists are coming to Ethereum L1 eventually, but L2s are exactly where ideas like this should get pressure-tested first because they offer a smaller blast radius, faster iteration, and real usage. World Chain choosing to implement this ahead of the fork, and to extend it further with 200ms streaming that Ethereum’s own spec doesn’t require, is a genuine contribution to how the wider ecosystem thinks about the throughput-versus-verification tradeoff, not just a feature shipped for its own network.
The takeaway
The core insight is to parallelize verification, start it before the block is finished, and get more out of the CPU capacity validators already own instead of demanding bigger machines. It’s the right idea, and World Chain has actually built and benchmarked a working version of it rather than just proposing it. The 1 Ggas/s figure is a controlled result, not a mainnet-proven ceiling yet, but it’s a strong, well-engineered step toward decoupling execution capacity from the hardware bar for independent verification, which is the thing that actually matters for keeping a chain decentralized while it scales.
