Sixteen Seconds Was the Easy Part: Ethereum's zkEVM

cover

Introduction

The Ethereum Foundation’s December 18, 2025 post on zkEVM security foundations does two things in the same document. It declares the realtime-proving targets met: proving latency down from 16 minutes to 16 seconds, costs down roughly 45x, zkVMs producing proofs for 99% of mainnet blocks in under 10 seconds on hardware costing less than $100,000. It then concedes that some of the mathematical conjectures underpinning STARK-based proof systems have been disproven, which means a zkEVM advertising 100 bits of security may in practice be delivering closer to 80.

Those two statements belong to different categories. The first is an engineering result, self-reported and visible on a public dashboard. The second is a retraction of a claim the industry had already been making in marketing material and audit summaries. The performance number improved; the security number was wrong.

That ordering is the interesting part. The binding constraint on an enshrined L1 zkEVM was never throughput. A proof system that takes 16 minutes to prove a 12-second block is useless for consensus, so latency had to come down first, and the zkVM teams brought it down fast. But once Ethereum validators stop re-executing transactions and start accepting proofs, the proof system becomes the thing that decides what is true. A liveness failure in that world means a missed slot. A soundness failure means consensus accepts a state transition that never happened: tokens minted from nothing, balances rewritten, bridges drained, and no re-execution layer underneath to catch it.

So the Foundation’s 2026 roadmap is a security sprint rather than a performance one. The deliverables are a scoring tool called soundcalc, 100 bits of provable security with proofs under 600 KiB by the Glamsterdam fork, and 128 bits with proofs under 300 KiB plus a formal soundness argument by the end of 2026. The word carrying the weight in all of this is “provable,” as distinct from “conjectured,” and the distinction is load-bearing precisely because the conjectures already failed once.

What realtime proving had to beat

The July 10, 2025 Foundation post that opened this program defined realtime proving as a list of hard numbers rather than a direction of travel. A proof for 99% of mainnet blocks within 10 seconds. On-premises capital expenditure under $100,000. Power draw under 10 kW. Proof size under 300 KiB. At least 128 bits of security, with 100 bits accepted as a short-term floor. No trusted setups, and fully open-source code.

Each constraint maps to a property of the end state. The 10-second latency budget exists because Ethereum’s slot time leaves no room for a proof that arrives after the next block. The $100,000 and 10 kW limits exist because the Foundation wants proving to remain accessible to operators who are not hyperscalers, which it frames as a censorship-resistance safeguard: if only a handful of industrial facilities can produce proofs in time, those facilities can decline to prove a block. The proof-size limit matters because every validator on the network downloads the proof, and a 600 KiB object propagating to every node in a slot is a different bandwidth problem than a 50 KiB one. The absence of trusted setups removes a class of ceremony risk that no amount of later auditing can retire.

The mechanism all of this serves is stateless validation. Today an Ethereum validator holds the full state and re-executes every transaction in a block to confirm the proposer’s claimed post-state root. That re-execution is why node hardware requirements track the gas limit, and why raising the gas limit is a fight. Under stateless validation, the validator holds no state. It receives a block, a succinct proof that executing the block’s transactions against the pre-state root yields the claimed post-state root, and it verifies the proof. Verification is cheap and roughly constant in the size of the computation being proved. Proving is expensive and scales with it.

That asymmetry is the whole source of the gas-limit headroom argument. If validators verify instead of re-execute, the cost of validating a 10x larger block does not rise 10x for them. It rises for whoever produces the proof. The Foundation’s sequencing follows directly: validators first run stateless ZK clients optionally, alongside normal re-execution; once a supermajority of stake is comfortable, the gas limit rises to a level where proof verification is the only practical way to keep up; once every validator verifies proofs, those proofs can feed an EXECUTE precompile that extends the same machinery to rollups.

Ethproofs, the public tracker the ecosystem uses to measure this, lays the path out as five phases: performance sprint, security sprint, delayed proving, mandatory proving, enshrined proofs. As of the snapshot underlying this analysis, the performance sprint is marked complete and the security sprint is the current phase, working toward the 100-bit and 600 KiB milestone. The last three phases have not started.

The distance between 99% of blocks and the tracker

The Foundation’s “99% of blocks under 10 seconds” and the Ethproofs cohort data describe the same system from different angles, and the gap between them is where the remaining engineering lives.

On the aggregate Ethproofs figures, across 502,520 tracked block slots, provers produced a proof within 10 seconds 70.2% of the time. That clears the stated interim threshold of 70% and does so narrowly. The remaining mass is not mostly slow proofs. It is absence: 26.2% of slots recorded the prover offline, 3.36% “stunned,” and 0.22% “paralyzed.” Conditional on a proof being completed at all, 95.4% landed inside the eligibility window.

Those two numbers, 70.2% unconditional and 95.4% conditional, say something specific. The proof systems are fast. The operations around them are not yet reliable. A research cohort running experimental zkVMs on GPU clusters will have downtime, and nobody should read a quarter of slots offline as a statement about the underlying cryptography. But the Foundation’s roadmap eventually arrives at mandatory proving, where a missing proof is a consensus-relevant event rather than a gap in a dashboard. The variable that has to go to near-zero before that phase is credible is the offline rate, and it is the variable the performance-sprint headline does not address.

Prover diversity shows the same shape. Of ten evaluated provers in the realtime-proving cohort, three meet the weekly eligibility threshold: Zisk at 69%, Axiom at 58%, zkDTVM at 8%. The remainder, including Pico, the Airbender variants, Succinct, and Ziren, sit at 0%. That is a snapshot of a moving target and several of those teams are plausibly weeks away from crossing the line. It is still the configuration the network has today, and it matters for the next section, because the defense that the Foundation proposes against soundness failure is diversity.

Costs, meanwhile, have come in below where almost anyone would have guessed two years ago. Leading provers report per-proof costs in the range of $0.0031 to $0.0063, achieved on clusters of four to sixteen NVIDIA 5090 GPUs. A third of a cent to prove an Ethereum block is not a rounding error against block rewards; it is beneath consideration. Whether that price survives contact with a competitive market carrying fully loaded electricity, depreciation, redundancy, and operator margin is a separate question, and research-cohort economics are not market economics.

Why soundness failures are a different class of problem

Every distributed system distinguishes liveness from safety, and the distinction usually resolves into a tradeoff where you accept more of one to get less of the other. An enshrined L1 zkEVM makes the tradeoff radically asymmetric.

A liveness failure in the proving layer means no valid proof arrives for a block within the slot. Under the proposed designs this is survivable. The network can fall back to re-execution during the optional and delayed phases, attesters can decline to build on an unproven block, and penalties can be set to make repeated failure expensive for whoever was supposed to produce the proof. The damage is measured in missed slots and delayed finality.

A soundness failure means the proof system accepts a proof for a state transition that is false. If validators have stopped re-executing, nothing else in the stack is checking. The Foundation’s own framing is blunt about what that permits: minting tokens, rewriting state, stealing funds. There is no equivalent of a chain halt that catches it in progress, because from consensus’s point of view nothing abnormal occurred. The forged state is canonical.

This is why the proposed rollout never puts one zkVM in the trusted position. A stateless ZK client in the Foundation’s design verifies proofs from multiple independently implemented zkVMs, each proving against a different EVM implementation, with three as the illustrative number. A validator accepts the block only if all of them verify. The analogy is explicit: this is client diversity applied one layer down. A soundness bug in a single zkVM becomes a liveness problem rather than a theft, because the other verifiers reject the forged proof and the block does not get attested.

The weakness in that argument is the same weakness that has dogged client diversity itself. Defense in depth only works if the implementations fail independently. Two zkVMs built on the same polynomial commitment scheme, relying on the same soundness conjecture, compiled through overlapping toolchains, targeting the same EVM specification, do not give three independent chances to catch an error. They give one, dressed as three. The cohort data makes this concrete: if only three implementations are fast enough to be eligible at any given moment, the practical diversity available to a validator is whatever those three happen to be, and the correlation structure among them is not something the Ethproofs dashboard measures.

Nominal diversity reproducing concentration under a different label is the failure mode worth watching here, and it is not solved by adding more entries to a tracker.

Provable bits versus conjectured bits

The Foundation’s answer to the soundness problem is to stop accepting self-reported security levels and start scoring them against a common standard. That standard is soundcalc, a tool that estimates a zkVM’s security in bits from current cryptographic bounds and the proof system’s parameters. Integration across participating teams was targeted for the end of February 2026, with scores published alongside performance, liveness, and cost on Ethproofs.

The reason this needed a tool rather than a disclosure requirement is that STARK security arguments are frequently parameterized against conjectures. A proof system designer picks parameters that would deliver a target security level if a particular conjecture about the behavior of the underlying code or commitment scheme holds, publishes that target, and the number enters circulation. The gap between “secure under conjecture C” and “secure” is invisible in a one-line claim of 100 bits.

Per the December post, at least one of those foundational conjectures has been mathematically disproven. The consequence is not academic. A system advertising 100 bits under the disproven conjecture may provide something nearer 80 bits when scored against what is actually proven. Eighty bits of soundness is not immediately breakable by a motivated adversary with a GPU, but it is the wrong number to secure a settlement layer against, and it is the wrong number to have discovered after the claim was made rather than before.

The roadmap that follows is specific. By the Glamsterdam fork, targeted for the end of May 2026, participating zkVMs should hit 100 bits of provable security with proofs no larger than 600 KiB. By the end of 2026, under the label H-star, the target is 128 bits with proofs under 300 KiB and a formal soundness argument accompanying them.

Those two targets pull against each other. Security margin in a STARK comes substantially from repetition, and repetition inflates the proof. Getting from 100 bits at 600 KiB to 128 bits at 300 KiB means improving the security-per-byte of the construction itself, which is why the post points at newer machinery: WHIR as a commitment scheme, JaggedPCS, and restructured recursion architectures that change how many layers of proof compression sit between the execution trace and the final object a validator downloads. These are active research directions with research-stage risk attached, and the schedule assumes they land.

What a bit count does not cover

The sources describing soundcalc specify what it estimates and not what it omits, and the omission list is where the historical damage in this field has actually occurred.

A soundness score derived from cryptographic bounds and proof-system parameters is a statement about the protocol on paper. It says that an adversary who cannot break the underlying hardness assumptions cannot forge a proof for a false statement with probability better than some bound. It does not, on any reading the available sources support, speak to whether the circuit faithfully encodes the EVM’s semantics, whether any constraint system is under-constrained such that invalid witnesses satisfy it, whether the witness generator produces values the constraints fail to pin down, or whether the compiler translating a high-level circuit description into constraints introduces a divergence.

Those are the bug classes that have produced real zkEVM incidents. A system can carry a mathematically impeccable 128-bit soundness argument and still accept a forged proof because one opcode’s constraint set permits a value it should forbid. The Foundation’s July post acknowledges the broader requirement, listing formal verification, audits, and bug bounties as necessary over time, which implies it does not regard the bit count as sufficient. But the public scoreboard will show a number in bits, and a number on a dashboard tends to become the thing people cite.

We could not determine from the available sources whether soundcalc’s scope is intended to extend to implementation-level correctness or whether a separate verification track covers it. That gap is worth resolving before the scores become the gating criterion for a phase transition.

EXECUTE and the native rollup path

The third strand of this program is a design proposal rather than a shipped system. Justin Drake’s native rollups post, published to ethresear.ch in January 2025, describes an EXECUTE precompile that would expose L1 execution verification as a primitive any contract can call.

The precompile takes a pre-state root, a post-state root, a transaction trace, and a gas amount, and returns whether executing that trace against the pre-state yields the post-state within the gas bound. How a validator satisfies itself of that answer is deliberately unspecified at the consensus layer. A validator can re-execute the trace directly, or it can verify a SNARK proving the same statement. No proof system is enshrined. Staking operators choose their own zkEL verifier client the way they choose an execution client today, as a subjective local decision rather than a protocol constant.

The gas accounting is designed to make the primitive meterable. A call costs a fixed EXECUTE_GAS_COST plus the gas used by the inner execution multiplied by an EIP-1559-style metered price specific to EXECUTE, with a separate cumulative limit and target across all such calls in a block. The gas is charged in full even when the call returns false, which removes the obvious griefing vector of submitting invalid traces cheaply.

A native rollup is then a contract that wraps EXECUTE in a derivation function: the logic handling sequencing, bridging, forced inclusion, and governance. The rollup’s state transition correctness is no longer something the rollup proves to itself. It is something L1 validators check as part of validating the L1 block. What that removes from the rollup’s attack surface is substantial: no custom SNARK circuit to get wrong, no fraud-proof game with its challenge windows and bonding assumptions, and no security council holding upgrade keys as the backstop for bugs in either. The rollup stays EVM-equivalent by construction, and it inherits L1 hard forks automatically, since the semantics EXECUTE enforces are whatever L1 execution means at that moment.

The timing mechanics are the delicate part. The proposal sketches one-slot delayed execution, giving provers a full slot to produce proofs for block n while block n+1 is being built, with attesters conditioning their attestation of block n+1 on proofs for block n being available. Penalties for missed slots are illustrated at around 1 ETH. Light-client liveness rests on an altruistic-minority prover assumption, meaning the design expects at least some provers to produce proofs even when the marginal economics are thin.

Drake’s post also notes that an optimistic native rollup could run a gas limit far above EXECUTE_CUMULATIVE_GAS_LIMIT, because in the optimistic case EXECUTE is only invoked to settle a challenge over a small disputed segment rather than to verify every block. That matters for throughput: the ZK path’s cost is bounded by what L1 is willing to meter, while the optimistic path uses EXECUTE as a settlement oracle and pays for it only under dispute.

None of this has shipped. The post is a design sketch from January 2025 with illustrative parameters, and the penalty sizes, delay structure, and gas constants are placeholders. A proof-of-concept demonstration is referenced in discussions of this roadmap as having occurred in March 2026; the sources available here do not document its scope or outcome, and we treat it as unverified. A working demonstration of a precompile is a long way from consensus integration, fee-market calibration, and a client ecosystem that can verify the resulting proofs in a slot.

What remains of the L2 stack

If native rollups reach production, the thing they obsolete is a specific layer of the rollup stack rather than rollups as a category.

What goes away is the bespoke security apparatus. A rollup that routes its state transitions through EXECUTE does not need to maintain its own prover, its own circuit, its own verifier contract, or the governance structure that exists to patch those things when they break. The security council, which in practice is the honest answer to “what happens when the proof system has a bug,” loses its reason to hold keys. For teams whose differentiation is EVM equivalence plus lower fees, that is most of the engineering budget and most of the trust assumption they currently ask users to accept.

What does not go away is everything above the state transition function. Someone still orders transactions, and sequencing rights remain the primary revenue source for most rollups today. Someone still publishes data, and blob fees remain a real cost that EXECUTE does nothing to reduce. The derivation function still has to handle forced inclusion correctly, which is where a rollup’s censorship resistance actually lives, and getting it wrong is still a way to lose user funds. Bridging logic still has to be written and still has to be right.

And native rollups are EVM-equivalent by definition, which bounds who they serve. A rollup running a non-EVM virtual machine, a modified gas schedule, native account abstraction with altered semantics, or anything else that diverges from L1 execution cannot route through a precompile that enforces L1 execution. For those systems, EXECUTE is not an upgrade path. It is a competitor with a better security story in the segment where the two overlap.

The honest position on L2 governance tokens is that the sources supporting this analysis contain no market, governance, or token-economic data, and any claim about valuation consequences would be invention. What can be said structurally is narrower: a governance token whose primary function is appointing and constraining a security council is a claim on a decision-making process, and native rollups are designed to remove the decisions that process exists to make. Tokens whose function is sequencing rights, fee capture, or ecosystem coordination are attached to functions EXECUTE does not touch. The distinction between those two cases is the thing to look at, and it is specific to each stack rather than general to the category.

Migration is also not free. A live rollup with billions in bridged assets moving to a new state-transition verification path is executing a bridge upgrade, which is the highest-risk operation in the business. Teams will move when the alternative is embarrassing, not when the design is elegant.

Proving concentration and the home validator

The censorship-resistance argument in the July 2025 post depends on home proving remaining viable, which is why the $100,000 and 10 kW targets exist at all. A proof market that only industrial operators can enter is a market where a small number of parties can decline to prove a block, and under mandatory proving that becomes a veto.

It is worth separating two roles that get conflated. Verification is cheap: a stateless validator checking three proofs does not need a GPU cluster, and the hardware burden on a home validator under stateless validation is plausibly lower than it is today, since holding full state and re-executing is the expensive part. Proving is where the concentration risk sits. The current cost figures, a third of a cent to six tenths of a cent per proof, are achieved on clusters of four to sixteen high-end GPUs. That is reachable for a well-capitalized individual and trivially reachable for a firm, but it is not a laptop, and the sub-cent per-proof number is only impressive given the capital behind it.

The cohort composition reinforces the point. Three eligible provers out of ten evaluated is not a market; it is a research group. Whether that ratio reflects a bootstrapping phase where seven teams are mid-optimization, or a structural outcome where proving has economies of scale that squeeze out small operators, is not answerable from a point-in-time snapshot. Both readings are consistent with the data. The hardware supply chain, electricity cost exposure, and geographic distribution of the operators who do qualify are not tracked anywhere we could find.

The same uncertainty applies to the gas-limit argument, which is the most concrete user-facing benefit on offer. The plan raises the L1 gas limit once a supermajority of stake runs ZK clients comfortably. If stateless validation genuinely decouples validator cost from gas limit, that is a large and durable win. But the proposal assumes proving capacity scales with the gas limit at tolerable cost, and proving cost does scale with the computation being proved. A 10x gas limit increase is a 10x larger trace to prove inside the same slot. The current cost figures are for blocks at today’s gas limit.

What would have to become observable

The performance sprint produced numbers that a third party can check on a public dashboard, which is more than most infrastructure roadmaps offer. The security sprint is harder to audit from outside, because a provable-security score is a statement about a proof whose correctness most readers cannot evaluate, and because the most dangerous bug classes are the ones the score does not appear to cover.

A few things would move the credibility of this program more than another latency improvement.

Per-prover soundcalc scores published on Ethproofs with the conjectures each system does and does not rely on stated explicitly, so that a reader can tell whether three eligible provers represent three independent failure modes or one.
The offline rate across tracked slots falling from the current ~26% toward something that would survive mandatory proving, where a missing proof is consensus-relevant rather than a dashboard gap.
A published, numeric threshold for each phase transition. The sequencing from delayed proving to mandatory proving to enshrined proofs is currently described by phase names rather than by the share of stake, the number of independent verified implementations, or the sustained reliability figure required to advance.
An answer to what happens after a soundness failure in an enshrined system. If a forged proof mints tokens and consensus accepts it, the recovery path is a social-layer fork, which is the same answer Ethereum has always had and a much less comfortable one when the trigger is a cryptographic bug rather than a visible exploit.

The 2026 milestones, soundcalc integration by February, 100 bits at 600 KiB by Glamsterdam in May, 128 bits at 300 KiB with a formal soundness argument by year end, are targets the Foundation set for itself, and the Ethproofs phase indicator still showing the security sprint as current is the only independent status signal available here. Whether those dates held is not something the sources underlying this analysis establish.

What is established is the order of difficulty. Sixteen minutes to sixteen seconds took eighteen months of focused engineering by teams with clear metrics and a public leaderboard. Going from a conjectured 100 bits to a proven 128 requires new cryptography to work, new constraint systems to be correct, and a measurement standard to cover the bugs that have historically caused the failures rather than the ones that are easiest to quantify.