The zkEVM ecosystem spent a year sprinting on latency. The time to prove an Ethereum block has been reduced from 16 minutes to 16 seconds, costs have been reduced by 45, 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 demonstration work has been carried out. Performance bottlenecks are eliminated. Now the real work begins, because speed without solidity is a liability, not an asset, and calculations under many STARK-based zkEVMs have been quietly failing for months.
In July, the EF set a formal “real-time proof” goal that bundles latency, hardware, energy, openness, and security: proving at least 99 percent of mainnet blocks in 10 seconds, on hardware that costs about $100,000 and runs in the 10 kilowatt range, with completely open source code, with 128-bit security, and with proof sizes equal to or less than 300 kilobytes.
The December 18 message claims that the ecosystem met the performance target, as measured on the benchmarking site EthProofs.
The real time is defined here in relation to the slot time of 12 seconds and approximately 1.5 seconds for block propagation. The standard is essentially “proofs are ready quickly enough that validators can verify them without breaking their liveness.”
The EF now shifts from flow to solidity, and the pivot is brutal. Many STARK-based zkEVMs have relied on unproven mathematical conjectures to achieve claimed security levels.
In recent months, some of these guesses, particularly the “proximity gap” assumptions used in the hash-based SNARK and STARK low-degree tests, have been mathematically broken, undermining the effective bit security of the parameter sets that depended on them.
The EF asserts that the only acceptable endgame for using L1 is “provable security”, not “security assuming conjecture X is true”.
They set 128-bit security as a goal, aligning it with traditional cryptographic standards bodies and academic literature on long-lived systems, as well as with record-breaking real-world calculations that show 128-bit is beyond the reach of attackers.
The emphasis on strength rather than speed reflects a qualitative difference.
If someone can tamper with a zkEVM proof, they can create arbitrary tokens or rewrite L1 state and trick the system, not just flush a contract.
This justifies what the EF calls a “non-negotiable” safety margin for any L1 zkEVM.
Three-step roadmap
The message presents a clear road map with three difficult stops. First, by the end of February 2026, each zkEVM team participating in the race plugs its proof system and circuitry into “soundcalc,” a tool maintained by EF that calculates security estimates based on current cryptanalytic limits and system settings.
The story here is that of the “common ruler”. Instead of each team quoting their own security with tailored assumptions, soundcalc becomes the canonical calculator and can be updated as new attacks emerge.
Second, “Glamsterdam” by the end of May 2026 requires provable security of at least 100 bits via soundcalc, final proofs equal to or less than 600 kilobytes, and a compact public explanation of each team’s recursion architecture with an overview of why it should be strong.
This quietly rolls back the original 128-bit requirement for early deployment and treats 100 bits as an interim goal.
Third, “H-star” by the end of 2026 is the full bar: 128-bit provable security by soundcalc, proofs equal to or less than 300 kilobytes, plus a formal security argument for the recursion topology. This is where it’s less about engineering and more about formal methods and cryptographic proofs.
Technical levers
The EF highlights several concrete tools intended to make the goal of 128 bits less than 300 kilobytes achievable. They highlight WHIR, a new Reed-Solomon proximity test that also serves as a multilinear polynomial engagement scheme.
WHIR provides transparent post-quantum security and produces smaller proofs and faster verification than legacy FRI-like systems at the same level of security.
128-bit security tests show proofs approximately 1.95 times smaller and verification several times faster than baseline builds.
They refer to “JaggedPCS”, a set of techniques to avoid over-padding when encoding traces as polynomials, allowing provers to avoid unnecessary work while still producing succinct commitments.
They mention “grinding”, which involves brute force searching the randomness of the protocol to find cheaper or smaller proofs while staying within strength limits, and “well-structured recursion topology”, i.e. layered schemes in which many smaller proofs are grouped into a single final proof with carefully argued strength.
Exotic polynomial and recursion math tricks are used to reduce proofs after increasing security up to 128 bits.
Independent works like Whirlaway use WHIR to construct multilinear STARKs with improved efficiency, and more experimental constructions of polynomial commitment are being built from data availability schemes.
The calculations are evolving quickly, but they are also moving away from assumptions that seemed safe six months ago.
What changes and open questions
If proofs are consistently ready within 10 seconds and remain under 300 kilobytes, Ethereum can increase the gas limit without requiring validators to re-execute each transaction.
Validators would instead verify a small proof, allowing block capacity to increase while keeping staking realistic. This is why EF’s previous real-time article explicitly linked latency and power to “home trial” budgets like 10 kilowatts and sub-$100,000 rigs.
The combination of large safety margins and small evidence is what makes an “L1 zkEVM” a credible settlement layer. If these proofs are both fast and secure on 128 bits, L2s and zk-rollups can reuse the same machines via precompilations, and the distinction between “rollup” and “L1 execution” becomes more of a configuration choice than a hard boundary.
Real-time proof is currently an off-chain benchmark, not an on-chain reality. Latency and cost figures come from hardware configurations and workloads curated by EthProofs.
There is still a gap between this and thousands of independent validators actually running these provers at home. The history of security is evolving. The only reason soundcalc exists is because hash-based STARK and SNARK security settings continue to evolve as conjectures are disproven.
Recent results have redrawn the boundary between “absolutely safe”, “hypothetically safe” and “absolutely dangerous” settings regimes, meaning that current “100-bit” settings could be revised again as new attacks emerge.
It is unclear whether all major zkEVM teams will actually achieve provable 100-bit security by May 2026 and 128-bit security by December 2026 while staying under proof size caps, 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 the GPUs, but the formalization and auditing of full recursion architectures.
The EF admits that different zkEVMs often compose many circuits with substantial “glue code” between them, and that it is essential to document and prove the robustness of these custom stacks.
This opens a long period of work for projects such as Verified-zkEVM and formal verification frameworks, which are still early and uneven across ecosystems.
A year ago, the question was whether zkEVMs would be fast enough. This question is answered.
The new question is whether they can prove it robustly enough, at a level of security that doesn’t depend on guesses that might break tomorrow, with proofs small enough to propagate 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 race to safety has just begun.
