The zkEVM ecosystem has undergone a year of comprehensive acceleration in latency. The proof creation time for a single Ethereum block has decreased from 16 minutes to just 16 seconds; costs have decreased by 45 times; and the participating zkVMs can now create proof for 99% of blocks on the mainnet in less than 10 seconds when running on target hardware.
On December 18, the Ethereum Foundation (EF) officially announced victory: creating real-time proof has been proven feasible. The fundamental performance bottlenecks have been removed. However, the more challenging phase has truly begun, as speed without accompanying mathematical robustness will become a risk rather than an advantage. More concerning is that the mathematical foundation of many zkEVMs based on STARK has quietly shown points of failure for several months now.
The goal of 'real-time proving' and the turning point regarding security
In July, EF set an official goal for 'real-time proving', not only focusing on latency but also including 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, and proof size not exceeding 300 kilobytes.
The post on 12/18 confirms the ecosystem has achieved this performance target, based on data from the EthProofs benchmark site.
The concept of 'real-time' here is defined relatively to Ethereum's 12-second slot cycle and about 1.5 seconds for block transmission. In other words, the proof must be ready fast enough for the validator to verify without interrupting the network's liveness.
However, EF quickly shifted focus from throughput to soundness, and this shift is quite rigid. Many zkEVM based on STARK have achieved advertised security levels by relying on unproven mathematical assumptions.
In recent months, some of these hypotheses, particularly the 'proximity gap' assumptions in low-degree tests of SNARK and STARK based on hash functions, have been mathematically broken. This significantly undermines the actual security levels of 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 true'.
The 128-bit level was chosen as the standard, in line with 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 soundness over speed reflects a fundamentally different nature. If an attacker can forge zkEVM proofs, they not only drain a contract, but can mint arbitrary tokens, rewrite L1 state, and make the entire system 'lie'. Therefore, EF considers high security margins non-negotiable for any zkEVM used at L1.
A roadmap with three milestones
EF lays out a clear roadmap with three mandatory milestones.
Firstly, by the end of February 2026, all zkEVM teams involved must integrate their proof systems and circuits into 'soundcalc', a tool maintained by EF to calculate security levels based on current cryptographic analysis limits and parameters of each scheme.
The goal is to establish a 'common measure'. Instead of each team self-declaring their bit-security levels based on their own assumptions, soundcalc will become the standard tool, which can be updated as new attack methods emerge.
Secondly, the 'Glamsterdam' milestone at the end of May 2026 requires achieving at least 100-bit security provable through soundcalc, with proof size not exceeding 600 kilobytes, along with a concise public explanation of the recursive architecture and its foundational arguments for robustness.
This implicitly adjusts the initial 128-bit goal for the early deployment phase, considering 100-bit as an intermediate level.
Thirdly, 'H-star' at the end of 2026 is the full standard: 128-bit security provable through soundcalc, maximum proof size of 300 kilobytes, and an official security argument for the entire recursive structure. At this stage, the challenge is no longer purely technical, but leans heavily towards formal methodology and cryptographic proofs.
Technical levers
EF points out a series 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 scheme.
WHIR provides transparent, post-quantum security, generating smaller proofs and faster verification compared to traditional FRI schemes at the same security level. Benchmarking at 128-bit shows proof size reducing by about 1.95 times, while verification speed is significantly faster than base structures.
EF also mentions JaggedPCS, a set of techniques that help avoid excessive padding when encoding traces into polynomials, allowing provers to reduce computational waste while maintaining concise commitments.
There is also 'grinding', which means brute-force searching in the random space of the protocol to achieve cheaper or smaller proofs while still within the security margin, along with tightly designed recursive architectures, where many small proofs are aggregated into a final proof with solid reasoning.
Increasingly complex polynomial and recursive tricks are being used to shrink proofs after raising the security level to 128-bit.
Independent studies like Whirlaway leverage WHIR to build more efficient multilinear 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 changes and the unanswered questions
If proofs are always ready within 10 seconds and maintain a size under 300 kilobytes, Ethereum can increase the gas limit without forcing validators to re-execute entire transactions. Instead, they only need to verify a small proof, allowing for block capacity expansion while still maintaining home staking capability.
This is why EF in previous writings has tightly linked latency and power consumption to the 'home proving' budget of 10 kW and hardware under 100,000 USD.
The combination of large security margins and small proofs is what makes an 'L1 zkEVM' a reliable payment layer. If these proofs are both fast and achieve provable 128-bit security, L2s and zk-rollups can reuse the same mechanism through precompile, making the boundary between 'rollup' and 'L1 execution' more flexible, being configuration-dependent rather than rigidly separated.
Currently, real-time proving only exists in the form of off-chain benchmarks. Metrics on latency and costs come from selected hardware configurations and workloads on EthProofs. The gap between that and thousands of independent validators actually running provers at home remains substantial.
The security narrative is also still undecided. The reason soundcalc was created is that the security parameters of STARK and SNARK are based on continuously changing hash functions as hypotheses are discarded. Recent results have redrawn the boundaries between 'definitely safe', 'hypothetically safe', and 'definitely unsafe', 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 extending 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 zkEVM often pair many circuits with significant amounts of 'glue code', and documenting and proving the soundness of these custom stacks is crucial.
This opens up a long road for projects like Verified-zkEVM and formal verification frameworks, which are still in the early and uneven stages across ecosystems.
A year ago, the big question was whether zkEVM could prove fast enough. That question has been answered.
Now, the issue is whether they can prove robust enough, at a security level not dependent on hypotheses that could collapse tomorrow, with proof small enough to propagate over Ethereum's P2P network, and with a recursively verifiable architecture sufficiently tight to anchor hundreds of billions USD in value.
The performance race has ended.
The security race has just begun.