If you think a native zkEVM only speeds up execution, you're missing the real prize: bandwidth scaling. Mike Neuder's latest post on ethresear.ch walks through why blocks-in-blobs (EIP-8142) are the unsung second half of the scaling story.
Current Ethereum blocks run 150-200 KB, taking about 100 ms to download on the 10 Mbit/s connection that node requirements specify. A 10x gas limit increase pushes download time to roughly 1 second. Add execution time on top, and you're eating a significant chunk of the 12-second slot. This is the problem a naive zkEVM doesn't solve: proof verification stays fast (50-200 ms and grows O(log^2 n) with gas), but downloading the full block scales linearly.
Execution scaling alone isn't enough
Neuder's key point: a native zkEVM that only replaces execution with proof verification still leaves bandwidth as a bottleneck. Attesters would download the full block plus multiple proofs (targeted at ~300 KiB each, so three proofs add nearly 1 MB per slot). On a 10 Mbit/s link that's another 0.8 seconds. Worse, the linear download time of the block itself grows proportionally to the gas limit. Without addressing this, the compute gains from ZK proofs are washed out by network latency.
The blocks-in-blobs trick
Ethereum already has blobs for large data that validators sample rather than download entirely. EIP-8142 extends that: put the entire block into a blob, and attesters only sample a subset of its contents before verifying the proof. The proof itself is still fully downloaded (and it's small and scales sub-linearly), but the block data no longer travels to every validator.
This is the bandwidth scaling unlock. Gas limit can grow without linear growth in per-slot download. The zkEVM becomes a scaling tool for both dimensions: compute (proof verification instead of re-execution) and bandwidth (sampling instead of full download). Neuder calls this a paradigm shift, and he's right.
Where the zkEVM fits with other proposals
Shorter slots and zkEVM can coexist, but prover latency must shrink too. ePBS buys an extra 6 seconds for proving and verification, though Neuder flags the free option problem as a major vulnerability. Fast finality is orthogonal. The takeaway: blocks-in-blobs makes zkEVM viable for real scaling, not just a trick for execution savings.
Next time someone pitches a native zkEVM as "proofs replace execution," ask them how they plan to move the block data. The answer should be blobs and sampling.
Source: A native zkEVM scales bandwidth, not just execution
Domain: ethresear.ch
Comments load interactively on the live page.