Ethereum Foundation refocuses on security instead of speed, applying a 128-bit standard for 2026.

The zkEVM ecosystem has undergone a comprehensive acceleration over the past year. The proof generation time for an Ethereum block has decreased from 16 minutes to just 16 seconds; costs have fallen by 45 times; and participating zkVMs can now generate proofs for 99% of blocks on the mainnet in under 10 seconds when running on target hardware.

On December 18, the Ethereum Foundation (EF) officially declared victory: creating real-time proof has become possible. The fundamental performance bottlenecks have been removed. However, a more difficult phase has truly begun, as speed without accompanying mathematical robustness will become a risk rather than an advantage. More concerning, the mathematical foundation of many zkEVMs based on STARK has quietly shown points of failure over the past few months.

The goal of 'real-time proving' and the turning point in security

In July, EF set an official goal for “real-time proving”, which not only revolves around latency but also includes hardware, energy, openness, and security. Specifically, the system must prove at least 99% of mainnet blocks within 10 seconds, on hardware worth about 100,000 USD, consuming no more than 10 kW of electricity, using completely open-source code, achieving 128-bit security level, and with proof size not exceeding 300 kilobytes.

The post on December 18 confirms that the ecosystem has achieved this performance goal, based on data from the benchmark site EthProofs.

The concept of “real-time” here is defined relatively to Ethereum's 12-second slot cycle and approximately 1.5 seconds allocated for block transmission. In other words, the proof must be ready fast enough for the validator to verify without disrupting the liveness (liveness) of the network.

However, EF quickly shifted focus from throughput to soundness (soundness), and this shift is quite rigid. Many zkEVMs based on STARK have achieved advertised security levels by relying on unproven mathematical hypotheses.

In recent months, some of these hypotheses, particularly the “proximity gap” assumptions in low-degree tests (low-degree tests) of SNARK and STARK based on hash functions, have been mathematically broken. This significantly undermines the actual security level of the parameter sets that once relied on them.

EF emphasizes that with L1, the only acceptable destination is “provable security,” not “security if hypothesis X is correct.”

The 128-bit level is chosen as the standard, suitable for mainstream cryptographic standard organizations and academic literature on long-term existing systems, as well as real-world computational records showing that 128-bit is beyond practical attack capabilities.

The priority for robustness over speed reflects a fundamental difference. If an attacker can spoof zkEVM proofs, they can not only drain a contract but can also mint arbitrary tokens, rewrite the L1 state, and make the entire system “lie”. Therefore, EF considers high security margins to be non-negotiable for any zkEVM used on L1.

Three Milestone Roadmap

EF provides a clear roadmap with three mandatory milestones.

First, by the end of February 2026, all zkEVM teams involved must integrate their proof systems and circuits into “soundcalc”, a tool maintained by the EF to compute the security level based on current cryptographic analysis limits and parameters of each scheme.

The goal is to establish a “common metric.” Instead of each team self-reporting their bit-security level based on their own assumptions, soundcalc will become the standard tool, which can be updated as new attack methods emerge.

Secondly, the milestone “Glamsterdam” at the end of May 2026 requires achieving at least 100-bit security that can be proven through soundcalc, with the proof size not exceeding 600 kilobytes, along with a public, concise explanation of the recursive architecture and fundamental reasoning for its robustness.

This implicitly adjusts the initial 128-bit target for the early deployment phase, considering 100-bit as an intermediate level.

Thirdly, by the end of 2026, “H-star” will be a full standard: 128-bit security that can be proven through soundcalc, with a maximum proof size of 300 kilobytes, and a formal security argument for the entire recursive structure. At this stage, the challenge is no longer purely technical, but strongly leans towards formal methods and cryptographic proofs.

Technical Leverage

EF indicates a range of tools aimed at realizing the 128-bit goal with proof under 300 kilobytes. Notably, WHIR, a new Reed-Solomon proximity check, also serves as a multilinear polynomial commitment (multilinear polynomial commitment).

WHIR provides transparent, post-quantum security, generating smaller proofs and faster verification compared to traditional FRI schemes at the same security level. The 128-bit benchmark shows that proof sizes fall by about 1.95 times, while verification speeds are many times faster than the underlying structure.

EF also mentions JaggedPCS, a set of techniques that helps avoid the unnecessary padding of ( when encoding traces into polynomials, allowing the prover to fall computational waste while still maintaining a concise commitment.

In addition, there is “grinding”, which means performing brute-force searches in the random space of the protocol to achieve cheaper or smaller proofs while still remaining within the security bounds, along with tightly designed recursive architectures where multiple small proofs are aggregated into a final proof with solid reasoning.

Polynomial and recursive mathematical techniques are becoming increasingly complex and are being used to shrink proofs after raising the security level to 128-bit.

Independent studies like Whirlaway leverage WHIR to build more efficient multi-linear STARKs, while other experimental polynomial commitment structures are being developed from data availability schemes.

Mathematics is advancing very quickly, but at the same time it is also moving away from assumptions that were considered safe just a few months ago.

What has changed and the unanswered questions

If the proof is always ready within 10 seconds and keeps the size under 300 kilobytes, Ethereum can increase the gas limit without forcing validators to re-execute the entire transaction. Instead, they only need to verify a small proof, allowing for block size expansion while maintaining the ability to stake at home.

This is the reason why EF in previous articles has closely linked latency and power consumption with the “home proving” budget of 10 kW and hardware under 100,000 USD.

The combination of high security and small proofs is what makes an “L1 zkEVM” a reliable payment layer. If these proofs are both fast and achieve 128-bit provable security, L2s and zk-rollups could reuse the same mechanism through precompile, making the boundary between “rollup” and “L1 execution” more flexible, being configurable rather than rigidly separated.

Currently, real-time proving only exists in the form of off-chain benchmarks. The latency and cost figures come from selected hardware configurations and workloads on EthProofs. The gap between that and thousands of independent validators actually running provers at home is still significant.

The security story is still not settled. The reason soundcalc was born is that the security parameters of STARK and SNARK are based on continuously changing hash functions as hypotheses are disproven. Recent results have redrawn the boundaries between “provably secure”, “secure under assumptions”, and “provably insecure”, meaning that today's “100-bit” configurations may need adjustments in the future.

It is unclear whether all major zkEVM teams can achieve 100-bit by May 2026 and 128-bit by the end of 2026 while still adhering to proof size limits, or if some will accept lower security margins, relying on heavier assumptions, or extend off-chain verification.

The biggest challenge may not lie in mathematics or GPUs, but in formalizing and auditing the entire recursive architecture. EF acknowledges that zkEVMs often pair many circuits with a significant amount of “glue code,” and the documentation as well as proving the robustness of these custom stacks is vital.

That opens up a long way for projects like Verified-zkEVM and formal verification frameworks, which are still in the early stages and uneven across ecosystems.

A year ago, the big question was whether zkEVM could prove fast enough. That question has been answered.

Now, the question is whether they can prove to be solid enough, at a level of security not reliant on assumptions that may collapse tomorrow, with evidence small enough to spread on Ethereum's P2P network, and with a recursively verified architecture sufficiently rigorous to anchor hundreds of billions of USD in value.

The performance race has ended.

The security race has only just begun.

Vương Tiễn