Ethereum researcher Mike Neuder published a research post arguing that a native zkEVM scales Ethereum's bandwidth, not just its execution, reframing how the upgrade fits into the scaling roadmap. The standard pitch for an enshrined zkEVM is execution scaling: instead of re-executing every transaction in a block, validators verify a cryptographic proof of the block's correctness, and because verification time grows sub-linearly (O(log2 n)) with gas, the gas limit can rise without proportionally longer execution times.

Neuder's point is that execution is only half the story. Downloading the block stays on the critical path, and block size grows linearly with the gas limit. Current Ethereum blocks run about 150 to 200KB and take roughly 100ms to download on the 10Mbit/s minimum connection in the node requirements. A 10x larger block would push download latency toward a full second, washing out the compute savings from proof verification. He concludes that block verification and download latencies must be weighed together when analyzing gas limit increases.

The fix relies on infrastructure Ethereum already has. By placing block contents inside blobs, validators can sample a subset of the data rather than downloading the entire block, the same mechanism danksharding uses for data availability. EIP-8142 proposes exactly this, putting the full block into a blob to be sampled in conjunction with verifying a proof of the sampled block's correctness. Neuder credits Toni's ethresear.ch post "Blocks Are Dead. Long Live Blobs" with making the same argument. The result is two distinct scaling benefits: lower latency from verifying a proof instead of executing transactions, and lower bandwidth from sampling a block instead of fully downloading it.

A native zkEVM introduces a new consensus participant, a prover, who generates the proof for each slot, with multiple provers and proofs expected to run redundantly to guard against a ZK bug producing an invalid state transition. Proofs are targeted at roughly 300 KiB, so attesters still download the full proofs even as they only sample the block contents, keeping proof download latency sub-linear in the gas limit while block sampling stays cheap.

Neuder also situates the zkEVM against other scaling efforts. He frames it as complementary to shorter slots, which target end-to-end latency rather than bandwidth, though shorter slots add tension around prover latency and fixed proving costs. He ties it to ePBS, a headlining EIP in the Glamsterdam hardfork, whose delayed payload timeliness vote leaves extra room for proofs to be generated and verified. Fast finality, he argues, is orthogonal to a native zkEVM.

The trusted Ethereum news briefing since 2022, reaching 6,000+ audio subscribers, 4,000+ newsletter subscribers, and 26k+ combined social followers.

Want to reach the ETH Daily audience? Learn more at ethdaily.io/ads.

Disclaimer: Content is for informational and educational purposes only and does not constitute financial, investment, legal, or other professional advice. No representations or warranties are made as to accuracy, completeness, or timeliness. Use of this content is at your own risk, and you should consult a qualified professional before making decisions. No fiduciary or advisory relationship is created