The zkEVM ecosystem has spent a year working on improving latency. The time to prove an Ethereum block has been reduced from 16 minutes to 16 seconds, the cost has dropped by a factor of 45, and participating zkVMs can now prove 99% of mainnet blocks on target hardware within 10 seconds.
On December 18th, the Ethereum Foundation (EF) declared victory in its real-time proof effort. Performance bottlenecks are eliminated. This is where the real work begins. Unhealthy speed is a liability rather than an asset, as many STARK-based zkEVM calculations have been quietly broken for months.
In July, EF set a formal goal for “real-time proof,” which brings together latency, hardware, energy, openness, and security. That means proving at least 99% of mainnet blocks in under 10 seconds, running within 10 kilowatts on roughly $100,000 hardware, with completely open source code, 128-bit security, and a proof size of less than 300 kilobytes.
In a Dec. 18 post, the ecosystem claims to have met its performance goals as measured on the EthProofs benchmark site.
Real time here is defined relative to a 12 second slot time and approximately 1.5 seconds of block propagation. This standard essentially states that “proofs are prepared quickly enough that verifiers can verify them without compromising validity.”
EF is currently pivoting from throughput to health, but that axis is slowing down. Many STARK-based zkEVMs have relied on unproven mathematical speculation to achieve their advertised security levels.
Over the past few months, some of these assumptions, particularly the “proximity gap” assumption used in hash-based SNARK and STARK low-order tests, have been broken mathematically, destroying the effective bit security of the parameter sets that relied on them.
EF states that the only acceptable end goal for L1 usage is “provable security” rather than “security assuming that conjecture X holds.”
They set a goal of 128 bits of security, consistent with calculations from mainstream cryptographic standards bodies, academic literature on long-lived systems, and real-world records that show 128 bits is realistically out of reach for attackers.
Emphasizing soundness over speed reflects a qualitative difference.
If someone can forge a zkEVM proof, they can not only deplete a single contract, but also mint arbitrary tokens or rewrite the L1 state to lie to the system.
This justifies what EF calls a “non-negotiable” security margin for L1 zkEVM.
Three milestone roadmap
This post provides a clear roadmap with three hard stops. First, by the end of February 2026, all zkEVM teams participating in the race will connect their proof systems and circuits to “soundcalc,” an EF-managed tool that calculates security estimates based on current cryptanalysis limits and scheme parameters.
The story here is “Common Ruler”. Instead of each team quoting their own bit of security based on bespoke assumptions, soundcalc becomes a standard calculator that can be updated as new attacks emerge.
Second, “gramsterdam” requires at least 100 bits of provable security via soundcalc, no more than 600 kilobytes of final proof, and a compact public description of each team’s recursive architecture and a sketch of why it should be sound, by the end of May 2026.
This quietly rescinds the original 128-bit requirement for early adopters and treats 100-bit as an interim target.
Third, “H Star” by the end of 2026 is the perfect standard. Formal security discussion of 128-bit provable security, proofs under 300 kilobytes, and recursive topology with soundcalc. Now, this is not about engineering, but about formal methods and cryptographic proofs.
technical lever
EF presents several specific tools aimed at making the 128-bit, sub-300 kilobyte goal achievable. They focus on WHIR, a new Reed-Solomon proximity test that also functions as a multilinear polynomial commitment scheme.
WHIR provides transparent post-quantum security and produces proofs that are smaller in size and faster to verify than older FRI-style schemes at the same security level.
Benchmarks for 128-bit security show that proofs are approximately 1.95 times smaller and verifications are several times faster than baseline construction.
They refer to “JaggedPCS”, a set of techniques to avoid excessive padding when encoding traces as polynomials. This allows the prover to generate concise commitments while avoiding wasted work.
They mention “grinding,” which brute-forces the randomness of a protocol to find cheap or small proofs while keeping it within soundness, and “well-structured recursive topology,” which refers to layered schemes that aggregate many small proofs into a single final proof with carefully argued soundness.
After increasing the security to 128 bits, unusual polynomial calculations and recursion tricks are used to reduce the proof.
Independent studies such as Whirlaway have used WHIR to construct multilinear STARKs with improved efficiency, and more experimental polynomial commitment structures have been constructed from data availability schemes.
The calculations are progressing rapidly, but we are moving away from assumptions that seemed safe six months ago.
Changes and open questions
If proofs are consistently ready within 10 seconds and stay under 300 kilobytes, Ethereum can increase the gas limit without forcing validators to re-execute every transaction.
Validators instead verify small pieces of evidence, expanding block capacity while keeping home staking realistic. This is why EF’s previous real-time post explicitly tied latency and power to “home testing” budgets like 10 kilowatts and sub-$100,000 rigs.
The combination of large security margin and small proof makes “L1 zkEVM” a reliable payment layer. If these proofs are fast and 128-bit secure, L2 and zk-rollup can reuse the same mechanism via precompilation, and the distinction between “rollup” and “L1 execution” becomes a compositional choice rather than a hard boundary.
Real-time proofs are currently an off-chain benchmark, not an on-chain reality. Latency and cost numbers are derived from EthProofs’ carefully selected hardware setups and workloads.
There is still a gap between the thousands of independent verifiers actually running these provers at home. The security story is in flux. The reason soundcalc exists is that STARK and hash-based SNARK security parameters continue to move as conjectures are disproved.
Recent results have redrawn the line between “definitely safe,” “speculatively safe,” and “absolutely unsafe” parameter regimes. This means that the current “100-bit” setting may be revised again as new attacks emerge.
It is unclear whether all major zkEVM teams will actually reach 100 bits of provable security by May 2026 and 128 bits of provable security by December 2026 without exceeding the proof size limit, or whether some teams will simply accept lower margins, rely on stricter assumptions, or prolong verification off-chain.
The most difficult part may not be the math or the GPU, but formalizing and auditing a fully recursive architecture.
EF acknowledges that different zkEVMs often constitute many circuits with substantial “glue cords” in between, and it is essential to document and prove the integrity of these custom stacks.
This will require lengthy work on projects such as Verified-zkEVM and formal verification frameworks, which are still in their early stages and uneven across the ecosystem.
A year ago, the question was whether zkEVM could prove fast enough. That question can be answered.
The new question is whether they can be proven soundly enough, with a proof small enough to propagate across Ethereum’s P2P network, and with a recursive architecture formally verified enough to lock in hundreds of billions of dollars, with a level of security that doesn’t rely on speculation that might break tomorrow.
The performance sprint is over. The security competition has just begun.