Ethereum Foundation changes priorities: security over speed, 128-bit as an immutable requirement by 2026

The zkEVM ecosystem has already solved the speed puzzle. Over the past year, proof generation time has decreased from 16 minutes to 16 seconds, fees have dropped by 45 times, and most network participants now verify 99% of blocks in 10 seconds on standard hardware. The Ethereum Foundation officially announced this victory on December 18 — the pressure on throughput has finally eased. But behind speed success lies a crisis in reliability.

From speed to reliability: a turning point

Mathematics of many STARK-based constructions has begun to fall apart over recent months. The assumptions that project designers relied on have proven unsustainable. This is especially true for the “proximity gap” in hash-based SNARK and STARK protocols — assumptions that the academic community has already disproved. As a result: the effective security of some parameters has fallen significantly below the claimed levels.

The Ethereum Foundation concludes that hidden mathematical distrust is unacceptable for L1 systems. Instead of a “security under” strategy, they have established a categorical requirement: proven security, with a set of bits totaling at least 128. This aligns with academic standards and lifelong cryptographic practice — a level that even a theoretical attacker cannot reach.

The logic is simple: if someone forges a zkEVM proof, they rewrite the entire L1 state, create tokens out of nothing, and force the protocol to lie. This is not a typical contract vulnerability — it’s a collapse of trust in the entire system. That’s why EF insists on an “undisputed” security margin.

Three implementation stages with strict deadlines

First milestone — February 2026:
Each zkEVM team must connect their proof system to “soundcalc” — a universal security calculation tool supported by EF. Instead of each project announcing its own bit security based on unique assumptions, everyone works with a single standard. soundcalc will be updated upon detection of new attacks, ensuring assessment relevance.

Second milestone — May 2026 (“Glamsterdam”): Mandatory minimum proven security of 100 bits, final proof size up to 600 kilobytes, plus public explanation of each recursion stack architecture. This is a softer entry before the final requirement — an intermediate goal that conditionally separates reliably secure from clearly insufficient.

Third milestone — December 2026 (“H-star”): Full target: 128-bit proven security, proof sizes no larger than 300 kilobytes, formal cryptographic justification of recursion topology. At this stage, engineering transitions into formal verification — a world of proofs, not assumptions.

Technical arsenal for achieving the impossible

The Ethereum Foundation has not just issued requirements — they pointed to tools that make 128-bit and 300-kilobyte proofs feasible.

WHIR — a new Reed-Solomon proximity test, which also serves as a commitment scheme for multi-line polynomials. Compared to previous FRI constructions: proofs are 1.95 times smaller at the same security level, verification is several times faster. This ensures post-quantum resilience without size penalties.

JaggedPCS — a method that avoids excessive padding when encoding traces as polynomials. Provers reduce unnecessary work, leaving commitments concise.

Grinding and well-structured recursion topology — a brute-force parameter search for cheaper, smaller proofs within security bounds, plus multi-level schemes where hundreds of small proofs are aggregated into a final proof with carefully justified security.

Independent teams like Whirlaway are already experimenting with WHIR for multi-line STARKs with increased efficiency. Mathematics is evolving rapidly but also moving away from assumptions that seemed guaranteed just half a year ago.

High stakes, unresolved questions

If proofs can be generated in less than 10 seconds and remain under 300 kilobytes, Ethereum could radically increase gas limits without requiring home validators to re-execute each transaction. Instead, they would verify a compact proof — a step toward realistic staking at high throughput.

But reality lags behind EthProofs test environments. Real-time proof generation remains a non-chain benchmark, dependent on tuned hardware and controlled loads. The gap to thousands of independent validators running this at home is still significant.

The most challenging part may not be the mathematics itself but the formalization of complete recursion architectures. Many zkEVMs consist of a dozen schemes glued together with “adhesive code.” Documenting and verifying the security of such stacks is a whole front for projects like Verified-zkEVM, which are still in early stages.

Moreover, today’s 100-bit security margin could be revised tomorrow if new attacks emerge. soundcalc is constantly “moving,” updating as cryptanalysis progresses.

From speed race to reliability race

A year ago, the question was: can zkEVMs prove quickly enough? The answer has been found. Now the real question is: can they prove reliably enough — at a security level that does not depend on assumptions that could be broken, with proofs small enough for P2P dissemination, with architectures formally verified for hundreds of billions of dollars?

The throughput race is over. The race for unbreakable security is just beginning.