The zkEVM ecosystem has been sprinting on latency for a year. Proof time for an Ethereum block dropped from 16 minutes to 16 seconds, costs dropped 45x, and participating zkVMs now prove 99% of mainnet blocks in less than 10 seconds on target hardware.
The Ethereum Foundation (EF) declared victory on December 18: real-time proof works. The performance bottlenecks have been resolved. Now the real work begins, because speed without robustness is a disadvantage, not an asset, and the math under many STARK-based zkEVMs has been quietly breaking for months.
In July, the EF set a formal goal for “real-time proofing” that bundled latency, hardware, energy, openness, and security: prove at least 99% of mainnet blocks in 10 seconds, on hardware costing about $100,000 and running within 10 kilowatts, with fully open-source code, with 128-bit security, and with proof sizes of 300 kilobytes or less.
The December 18 message claims that the ecosystem has met its performance goal as measured by the EthProofs benchmarking site.
Real time is defined here relative to the slot time of 12 seconds and approximately 1.5 seconds for block propagation. The standard is essentially: “proofs are ready fast enough that validators can verify them without interrupting liveness.”
The EF is now turning from transit to solidity, and the spindle is blunt. Many STARK-based zkEVMs have relied on unproven mathematical conjectures to achieve advertised security levels.
In recent months, some of these conjectures, especially the ‘proximity gap’ assumptions used in hash-based SNARK and STARK low-grade tests, have been mathematically debunked, overturning the effective bit security of parameter sets that depended on them.
The EF says that the only acceptable endgame for L1 use is “demonstrable safety,” not “safety, assuming presumption X holds.”
They set 128-bit security as a goal, aligning it with mainstream crypto standards bodies and academic literature on long-lived systems, as well as real-world record calculations showing that 128 bits is realistically out of reach for attackers.
The emphasis on solidity over speed reflects a qualitative difference.
If someone can forge a zkEVM proof, he can mint random tokens or rewrite the L1 state and make the system lie, not just empty one contract.
That justifies what the EF calls a “non-negotiable” safety margin for each L1 zkEVM.
Roadmap with three milestones
The post contains a clear roadmap with three hard stops. First, each zkEVM team in the race at the end of February 2026 will connect its pilot system and circuits to ‘soundcalc’, an EF-maintained tool that calculates security estimates based on current cryptanalytic limits and the scheme’s parameters.
The story here is ‘common ruler’. Instead of each team quoting their own piece of security with custom assumptions, soundcalc becomes the canonical calculator and can be updated as new attacks emerge.
Second, “Glamsterdam” requires at least 100-bit provable security via soundcalc, final proofs at or below 600 kilobytes, and a compact public explanation of each team’s recursion architecture by the end of May 2026 with an outline of why it should be sound.
This quietly rolls back the original 128-bit requirement for early implementation and treats 100-bit as an intermediate goal.
Third, by the end of 2026, ‘H-star’ will be the full bar: 128-bit provable security by soundcalc, proofs at or below 300 kilobytes, plus a formal security argument for the recursion topology. That’s where it becomes less about technique and more about formal methods and cryptographic proofs.
Technical levers
The EF points to several concrete tools intended to make the goal of 128 bits and less than 300 kilobytes achievable. They highlight WHIR, a new Reed-Solomon proximity test that doubles as a multilinear polynomial commitment scheme.
WHIR provides transparent, post-quantum security and produces proofs that are smaller and more quickly verified than those of older FRI-like schemes at the same security level.
Benchmarks on 128-bit security show that proofs are roughly 1.95 times smaller and verification is several times faster than baseline constructs.
They refer to “JaggedPCS”, a set of techniques to avoid over-padding when encoding traces as polynomials, allowing provers to avoid wasted work while still making concise commitments.
They mention “grinding,” which is the brute force search of arbitrary protocols to find cheaper or smaller proofs while staying within the bounds of soundness, and “well-structured recursion topology,” which means layered schemes in which many smaller proofs are merged into a single final proof with carefully argued soundness.
Exotic polynomial math and recursion tricks are used to reduce proofs after security has been increased to 128 bits.
Independent work such as Whirlaway uses WHIR to build multilinear STARKs with improved efficiency, and more experimental structures with polynomial commitments are being built based on data availability schemes.
The calculations are fast, but also deviate from the assumptions that looked safe six months ago.
What is changing and the open questions
If proofs are consistently ready within 10 seconds and remain under 300 kilobytes, Ethereum can increase the gas limit without forcing validators to redo every transaction.
Validators would instead verify a small proof, allowing block capacity to grow while keeping the home strike realistic. This is why EF’s previous real-time post explicitly linked latency and power to “home-proven” budgets such as 10 kilowatts and installations under $100,000.
The combination of large safety margins and small proofs makes an “L1 zkEVM” a credible settlement layer. If these proofs are both fast and provably 128-bit secure, L2s and zk rollups can reuse the same machinery via precompiles, and the distinction between “rollup” and “L1 execution” becomes more of a configuration choice than a rigid boundary.
Real-time proof is currently an off-chain benchmark, not an on-chain reality. The latency and cost figures come from the hardware settings and workloads compiled by EthProofs.
There’s still a gap between that and the thousands of independent validators who actually run these provers at home. The safety story is in flux. The whole reason soundcalc exists is that STARK and hash-based SNARK security parameters keep evolving as suspicions are refuted.
Recent results have redrawn the line between “absolutely secure,” “presumably secure” and “absolutely unsafe” parameter regimes, meaning that the current “100-bit” settings could be revised again as new attacks emerge.
It’s not clear whether all major zkEVM teams will actually reach 100-bit provable security by May 2026 and 128-bit by December 2026, while staying below proof-size limits, or whether some will quietly accept lower margins, rely on heavier assumptions, or push verification off-chain for longer.
The hardest part may not be the math or GPUs, but formalizing and checking the entire recursion architectures.
The EF admits that various zkEVMs often assemble many circuits with substantial ‘glue code’ between them, and that documenting and proving the soundness of those custom stacks is essential.
That opens up a long line of work for projects like Verified-zkEVM and formal verification frameworks, which are still in their infancy and unevenly distributed across ecosystems.
A year ago, the question was whether zkEVMs could prove fast enough. That question is answered.
The new question is whether they can prove robust enough, at a level of security that doesn’t rely on presumptions that might be correct tomorrow, with proofs small enough to spread across Ethereum’s P2P network, and with recursion architectures formally verified enough to anchor hundreds of billions of dollars.
The performance sprint is over. The safety race has just begun.