Ethereum Foundation sets the 128-bit security standard: from a race for speed to a race for correctness

From the Time of Correctness: A Paradigm Shift

Over the past year, the zkEVM ecosystem has primarily fought delays. The progress has been impressive: generating proofs for Ethereum blocks has shortened from 16 minutes to 16 seconds, costs have decreased 45-fold, and participating zkVMs are currently producing proofs for 99% of mainnet blocks in under 10 seconds on the target hardware.

On December 18, the Ethereum Foundation announced a groundbreaking result: real-time proof generation is actually working. However, this moment of triumph turns out to be a turning point. Performance bottlenecks have been eliminated, but this has raised new, deeper questions. Speed without correctness is not a technical advantage but a systemic risk. At the same time, the mathematics behind many STARK-based zkEVMs has been silently collapsing for months — this is precisely why shifting focus from performance to security is not only recommended but actually unavoidable.

Mathematical Discrepancy and Assumption Problems

Many STARK-based zkEVMs have relied so far on unproven mathematical assumptions to achieve the claimed security level. In recent months, especially during scientific research, assumptions such as the “proximity gap” used in low-degree SNARK and STARK tests based on hashes have been mathematically disproven. This finding has significant consequences: the effective bit security of parameter sets relying on these assumptions has been substantially reduced.

The Ethereum Foundation has clearly stated: the only acceptable solution for L1 applications is “proven security,” not “conditional security based on the assumption that X is true.” This mathematical difference between specification and actual proof is critical for systems handling hundreds of billions of dollars in value.

The target is 128-bit security — a standard aligned with major cryptographic guidelines and scientific literature on the longevity of cryptographic systems. Realistically, 128 bits are beyond the practical reach of attackers, according to current computational records.

Three-Stage Roadmap: From Implementation to Formal Verification

The Ethereum Foundation has presented a clear roadmap with three hard milestones:

Phase one – end of February 2026:
Each zkEVM team will combine their proof system and circuits into “soundcalc” — a tool maintained by EF that estimates security based on current cryptanalysis limits and scheme parameters. This provides a common security measure, replacing the situation where each team reported their own bit security numbers. Soundcalc becomes the canonical calculator, updated as new attacks are discovered.

Phase two – “Glamsterdam” by the end of May 2026:
Requires at least 100-bit proven security via soundcalc, proofs no larger than 600 KB, and a public explanation of each team’s recursion architecture with a sketch of its correctness proof. This is a transitional phase, stepping back from the initial 128-bit target for early deployment.

Phase three – “H-star” by the end of 2026:
Full threshold: 128-bit proven security, proofs not exceeding 300 KB, and a formal security argument for the recursion topology. At this stage, it’s no longer about engineering but about formal methods and cryptographic proofs.

Technical Arsenal: From WHIR to Recursion Topology

The Ethereum Foundation points to specific tools enabling the achievement of 128-bit security with proof sizes below 300 KB.

WHIR – a new proximity test based on Reed-Solomon codes – also functions as a commitment scheme for multi-polynomial commitments. It offers transparency, quantum-resistant security, and generates proofs smaller and faster to verify than older schemes like FRI at the same security level. Benchmarks at 128-bit security show proofs about 1.95 times smaller and verification several times faster than baseline constructions.

JaggedPCS is a set of techniques to avoid excessive padding when encoding traces as polynomials — proof generators save unnecessary work, maintaining concise commitments.

Grinding — brute-force search over protocol randomness — allows finding cheaper or smaller proofs while maintaining correctness bounds.

Well-organized recursion topology involves layered schemes where multiple smaller proofs are aggregated into a single final proof with justified correctness. Independent projects like Whirlaway use WHIR to build multi-layered STARKs with increased efficiency.

Practical Implications and Open Questions

If proofs can consistently be generated in 10 seconds and are under 300 KB in size, Ethereum will gain the ability to increase gas limits without forcing validators to fully re-execute each transaction. Instead, validators will verify tiny proofs, enabling larger block capacities while maintaining feasible home staking — thus, the “home proving” budget is 10 kW of energy and hardware below $100,000.

This combination of large security margins and compact proofs transforms “L1 zkEVM” into a credible settlement layer. If proofs are both fast and verified at 128 bits, L2 and zk-rollups can leverage the same infrastructure via precompilations — the boundary between “rollup” and “L1 execution” becomes more about configuration than rigid architectural constraints.

At the same time, significant uncertainties remain. Real-time proof generation today is a off-chain benchmark, not an on-chain reality. The numbers regarding delays and costs come from selected hardware configurations of EthProofs. The gap between this and thousands of independent validators running proof generators at home remains real.

Security history is a phase of change. Soundcalc exists precisely because the parameters of hash-based STARKs and SNARKs are constantly evolving as assumptions are disproven. Recent results have again redefined the boundary between “definitely secure,” “default secure,” and “definitely insecure,” meaning that today’s 100-bit settings may be revisited with new attacks.

It’s uncertain whether all major zkEVM teams will actually reach 100-bit proven security by May 2026 and 128-bit by December 2026, staying below size limits, or if some will accept lower margins, rely on heavier assumptions, or extend off-chain verification.

The earliest obstacle may not be mathematics or GPU power but the formalization and auditing of full recursive architectures. EF admits that different zkEVMs combine many circuits with significant “glue code,” and documenting the correctness of these custom stacks is crucial. This opens a broad area of work for projects like Verified-zkEVM and formal verification frameworks, which are still in early stages and unevenly developed across ecosystems.

Conclusions: The End of One Race, the Beginning of Another

A year ago, the question was: can zkEVMs generate proofs fast enough? The answer is known. The new question is: can they generate proofs that are sufficiently correct, at a security level that does not rely on assumptions that may collapse tomorrow, with proofs small enough to propagate through the Ethereum P2P network, and with formally verified recursive architectures to safeguard hundreds of billions of dollars?

The performance race is over. The race for mathematical correctness and security is just beginning in earnest.