A native zkEVM scales bandwidth, not just execution
by mike neuder – sunday, june 21, 2026.
\cdot
Thanks to Ignacio and Ladislaus for fruitful discussions and comments.
\cdot
tl;dr; Enshrining a native zkEVM is part of Ethereum’s scaling roadmap. This upgrade is mainly pitched in terms of execution scaling; instead of fully executing the transaction in a block, validators will simply download and verify a cryptographic proof of correctness of the entire block. In theory, this unlocks massive potential increases in Ethereum’s gas limit. However, doing so naïvely would result in a linear increase in the block size. The latency incurred from downloading massive blocks would wash out the compute scaling benefits from verifying the ZK proofs. Fortunately, the block contents can be placed inside of blobs, which already allow consensus over large amounts of data without the full set of validators downloading the entire contents. In this way, the native zkEVM scales the bandwidth of the chain in conjunction with scaling the execution. Toni’s recent article “Blocks Are Dead. Long Live Blobs” makes this exact point, and EIP-8142 is an explicit proposal to enable this feature. This article belabors the point and avoids implementation details to hammer home this crucial benefit of a native zkEVM.
0. Background
A “native” zkEVM, where the protocol dictates that validators verify ZK proofs rather than re-executing the blocks, is part of the scaling roadmap for Ethereum L1. Usually, the zkEVM is pitched primarily as reducing the amount of execution time required for validators in the network; instead of re-executing all of the transactions in a block, the validators can simply verify a cryptographic proof of correctness (hereafter just “proof”). Since the verification time of a proof is sub-linear in the amount of gas in a block (it is O(\log^2 n) ), larger increases in the gas limit are enabled without correspondingly longer execution times. From execution timing data collected by the PandaOps team, we see that on average, blocks often take less than 100ms (less than 1% of the full 12s slot) to execute. Downloading the execution payload, which is just the list of transactions that constitute the block itself (hereafter, just the “block”), is another part of the critical path that must be accounted for. Current Ethereum blocks are about 150-200KB, which take about 100ms to download on the minimum 10Mbits/s connection described in the node requirements. Now imagine a 10x larger block. In the status quo, both the execution and block download latency would scale linearly to each take about 1s. With a native zkEVM, the block validation via proof verification would be much faster (c.f., current proof verification runs in the 50-200ms range, and the polylog scaling means it would grow very slowly under large gas limits). However, downloading the full block would still be linear in the gas limit. This leads to the following conclusion: block verification and download latencies must be considered together when analyzing gas limit increases.
This raises a fundamental question: What is the point of enshrining a zkEVM if the execution scaling benefits are washed out by increased latency of downloading the larger blocks? This article argues that a second key benefit of a native zkEVM is that it allows scaling the gas limit without increasing the block download latency. In short, in a post-zkEVM world, validators will only sample a subset of the block data, rather than downloading the entire transaction contents. Thus, the zkEVM provides two scaling benefits: (1) a reduction in latency corresponding to verifying the proof instead of executing the transactions and (2) a reduction in bandwidth corresponding to sampling a block instead of fully downloading it. While (1) gets lots of airtime, (2) is also necessary to realize the true scaling benefits of a native zkEVM.[1] [2]
Toni’s recent article “Blocks Are Dead. Long Live Blobs” makes this exact point and dives into the technical requirements for including blocks inside of blobs. Further, EIP-8142 is an explicit proposal to enable this feature.
This article belabors this point while intentionally avoiding the nitty-gritty of the implementation details because it is vital to justifying the enshrinement of a zkEVM and for general legibility of Ethereum’s scaling roadmap. Section 1 discusses the block validation flow as it exists today. Section 2 shows how that process changes with a naïve zkEVM implementation that still requires downloading the full block. Section 3 shows the timeline under a “smarter” zkEVM implementation that only asks validators to sample block contents (i.e., through EIP-8142). Section 4 concludes by discussing how a native zkEVM interplays with other scaling proposals.
1. Current block validation
In Ethereum today, the block validation flow is simple. We consider just the proposer, the attesters[3], and aggregators[4] for a single slot. The figure below shows this as a simple timeline.
- The proposer publishes a block.
- The attesters download the block.[5]
- The attesters execute the block.
- The attesters vote on their current canonical head.
- The aggregators merge attestations into aggregates.
We highlight a few important takeaways from this timeline:
- The proposer, per the honest validator specification, should publish their block at
t=0. However, due to timing games, they usually push later into the slot. - We split the attester duties into three distinct parts, all of which happen before the attestation deadline at
t=4.[6]
This process is how blocks have been validated since the launch of the beacon chain (ignoring data availability as a precondition for block validity). Enshrining a zkEVM, an important part of Ethereum’s scaling roadmap, represents a significant change to this flow.
2. Basic zkEVM block validation
With a native zkEVM, each block requires a corresponding ZK proof of correctness demonstrating that the transactions are valid. This introduces a new consensus participant, called a prover, who generates this proof for a given slot.[7] The figure below shows this as a simple timeline of the new block validation flow. The red circles are modified from the original, and the yellow circles are exactly the same (albeit renumbered).
- The proposer publishes a block. Same as (1) in Current block validation.
- The prover generates a proof of the block.
- The attesters download the block. Same as (2) in Current block validation.
- The attesters download the proof(s) of the block.
- The attesters verify the proof(s) of the block.
- The attesters vote on their current canonical head. Same as (4) in Current block validation.
- The aggregators merge attestations into aggregates. Same as (5) in Current block validation.
We highlight a few important takeaways from this timeline:
- The prover must produce a proof before the attesters can verify it. In reality, it is expected that multiple proofs are verified redundantly to ensure a ZK bug doesn’t lead to an invalid state transition, so really, multiple provers need to act and multiple proofs need to be downloaded and verified.[8]
- In this naïve version, the attester downloads the full block (3) and the proof (4), meaning their bandwidth consumption increases compared to the non-zkEVM validation flow. Proofs are targeted at a 300 KiB, so downloading three such proofs would add nearly a full megabyte of extra data to download each slot (0.8s on a 10Mbit/s connection).
- Rather than executing the block directly, the attesters now validate the zkEVM proof(s) (5) before making their vote (6).
On first blush, this setup is worse for scalability because the additional latency required to download and execute multiple proofs would be slower than just executing the block directly! Further, as discussed in Section 1, even if the proof verification provides a significant speedup over executing the block, we also have to consider that downloading the block itself scales significantly under a larger gas limit too. Without reducing the bandwidth overhead of higher-gas-limit blocks, a native zkEVM doesn’t provide meaningful scaling improvements. Fortunately, there is a simple solution to this problem that Ethereum is perfectly set up to utilize. Put simply, the validators can fully download the proofs, but only sample the block contents to perform the verification. The next section illustrates this.
3. Smarter zkEVM block validation
With blobs, Ethereum already has infrastructure built for large amounts of data to be posted to the chain without each individual node downloading the entire contents. EIP-8142 leverages this capability and puts the entire block into a blob to be sampled by validators in conjunction with verifying a proof of the sampled block’s correctness. The figure below shows this block validation flow. Only the blue circle differs from the previous timeline.
- The proposer publishes a block. Same as (1) in Basic zkEVM block validation.
- The prover generates a proof of the block. Same as (2) in Basic zkEVM block validation.
- The attesters sample the block, whose contents are included in a blob.
- The attesters download the proof of the block. Same as (4) in Basic zkEVM block validation.
- The attesters verify the proof of the block. Same as (5) in Basic zkEVM block validation.
- The attesters vote on their current canonical head. Same as (6) in Basic zkEVM block validation.
- The aggregators merge attestations into aggregates. Same as (7) in Basic zkEVM block validation.
The zkEVM allows attesters to sample the block (3) instead of fully downloading it. In my opinion, this is as important as reducing the execution time of the block. The attesters will still need to download the entire proof of the block (or multiple proofs), but they benefit from only sampling a portion of the full block contents.
This is a huge paradigm shift. The maximum size of a block increases linearly with the amount of gas in the block, meaning any gas limit growth without the zkEVM would result in increased download latency. Conversely, the proof size scales sub-linearly (again O(\log^2 n)) in the amount of gas in a block, meaning gas increases have a sub-linear impact on download latency of the proof in a post-zkEVM world. This is the fundamental unlock that makes a native zkEVM so exciting to me.
4. zkEVM compared to other scaling technologies
The zkEVM is an important part of Ethereum’s scaling plan. As discussed above, the main advantage of the zkEVM world is that it allows for large increases in the gas limit, without correspondingly large increases in the block verification and download latencies. This is great, but the overall throughput of the chain isn’t the only metric that matters for scaling.
- zkEVM vs. shorter slots: Shorter slots (and “quick” slots) aim to reduce the end-to-end latency of a slot. (In particular, they target the latter 8s of the slot time, during which attestation propagation and aggregation happen –– see any of the figures above.) In some ways, the zkEVM scaling roadmap works against the goal of shorter slots. This follows from the simple reality that introducing a proving step in the block production (2 in Basic zkEVM block validation) adds another participant in the block production flow and another round of communication to share the proof(s) with the rest of the network. Additionally, the zkEVM chain can only progress as fast as the fastest prover can complete a proof.[9] While “realtime proving” is within reach for 12-second slots, any reduction of the slot time requires a corresponding reduction in prover latency. Lastly, the current vision of shorter slots involves a lower per-block gas limit, effectively preserving the per-second gas limit of the chain. However, in a zkEVM world, there are fixed proving costs independent of the gas limit, so shorter slots work against the amortization of that work. On net, the reality isn’t so zero-sum between shorter slots and the zkEVM. The zkEVM is fundamentally a bandwidth-scaling technology, whereas shorter slots focus on reducing latency. As long as prover latency can be reduced sufficiently and proof sizes are small enough to download quickly, then these scaling technologies actually complement each other nicely.
- zkEVM vs. ePBS: ePBS changes the block production pipeline. A proposer can now commit to a block header without seeing the contents of the block. Further, the main attester set votes for the availability of that commitment (at
t=3), also blind to the block contents and validity. Only the payload timeliness committee members (a subset of 512 randomly sampled validators) vote on the timing and validity of the block itself, and they do so at timet=9. While this six-second delay exposes the protocol to the free option problem (which is a major vulnerability IMO), it does provide extra time for the block to be downloaded and executed. In a zkEVM future, this time is also helpful for the proofs to be generated and verified. Given ePBS is a headlining EIP in the Glamsterdam hardfork, it seems like the community values these scaling benefits[10] above the economic risk exposed by the free option problem. - zkEVM vs. fast finality: Fast finality (and the fast confirmation rule) are entirely orthogonal from an native zkEVM. Ethereum’s finality currently operates on the scale of epochs (32 slots), and the goal of fast finality is to reduce this to a smaller number of slots. A zkEVM doesn’t help or hinder this goal.
There are a lot of pieces of the Ethereum scaling puzzle. This article argues that when considering the scaling benefits of a zkEVM specifically, we should consider the bandwidth scaling enabled by blocks-in-blobs on equal footing with the compute scaling arising from substituting block execution with proof verification.
thanks for reading!
Note that we are ignoring the potential stateless benefits of having a zkEVM. For the purposes of this article, we are focusing on the realtime bandwidth and latency resources rather than the longer-term memory and disk consumption. While those are important too, in the short term, slot timing and resources are the scaling bottleneck. ↩︎
It is also worth noting that if bandwidth scales sufficiently fast, then fully downloading the larger blocks may be possible and eliminate the need for a more bandwidth-efficient block validation flow. In this world, the chain would be compute-bound, and the compute-scaling benefits of a native zkEVM would be the dominant factor. Intuitively, compute seems to be scaling faster than global bandwidth, but verifying this is an important empirical sanity check that should be done. ↩︎
The full validator set is partitioned into 32 groups, each of which votes for a single slot within the epoch, such that each validator votes exactly once per epoch. ↩︎
Aggregators merge attestations into a single, larger attestation, but they are neither paid for doing so nor punished for not. ↩︎
This timeline ignores the fact that sampling blob transactions is part of the block validation flow, which is not relevant for this discussion. ↩︎
This ignores the edge case where the block is downloaded before the attestation deadline, but the validation and voting take place after. Per the honest specification, as long as a valid block is downloaded by the deadline, the attester should consider it in their fork-choice view: “A validator should create and broadcast the attestation to the associated attestation subnet when either (a) the validator has received a valid block from the expected block proposer for the assigned slot or (b) get_attestation_due_ms() milliseconds has transpired since the start of the slot – whichever comes first.” Of course, they will only know the block is valid once they execute it, but the spec seems open to allowing execution to take place after the deadline, and how clients implement this is not important for this article. ↩︎
It is possible that the prover doesn’t actually become an enshrined role, and builders are expected to provide the proofs for blocks they build. While this fully eliminates the ability for solo-stakers to self-build blocks (because they cannot be expected to provide ZK proofs), they may contribute to the block contents through FOCIL and being “includers” – see here for what this unbundling could look like. ↩︎
Note that verifying multiple proofs is actually a more robust block validation flow than executing the block on a single execution layer client, which validators do today. In effect, verifying multiple proofs acts as an extremely cheap way of getting broader client diversity without asking nodes to run multiple execution layer binaries. ↩︎
Shameless plug for a recent paper we wrote about proof acquisition, from which footnote #5 captures this nicely: “Under this paradigm, the zk-EVM can operate at a faster pace, so long as someone in the network can both execute transactions and produce a correct proof (because sampling the transaction data and verifying the produced proof is sufficiently lightweight that the entire validator network can do so). Depending on the prover efficiency of the proof system, this may or may not be an improvement – on one hand, we operate at the pace of the fastest (rather than slowest) participant, but on the other, that participant must now both execute transactions and also write a ZK proof of correctness.” ↩︎
EIP-7886, which allowed for delayed execution of blocks, would have provided similar pipelining benefits without the free option problem, but is no longer an active proposal. ↩︎