The zkEVM ecosystem spent a 12 months sprinting on latency. Proving time for an Ethereum block collapsed from 16 minutes to 16 seconds, prices dropped 45-fold, and collaborating zkVMs now show 99% of mainnet blocks in below 10 seconds on track {hardware}.
The Ethereum Basis (EF) declared victory on Dec. 18: real-time proving works. The efficiency bottlenecks are cleared. Now the actual work begins, as a result of pace with out soundness is a legal responsibility, not an asset, and the mathematics below many STARK-based zkEVMs has been quietly breaking for months.
In July, the EF set a proper goal for “real-time proving” that bundled latency, {hardware}, power, openness and safety: show at the least 99% of mainnet blocks inside 10 seconds, on {hardware} that prices roughly $100,000 and runs inside 10 kilowatts, with absolutely open-source code, at 128-bit safety, and with proof sizes at or under 300 kilobytes.
The Dec. 18 publish claims the ecosystem met the efficiency goal, as measured on the EthProofs benchmarking website.
Actual-time right here is outlined relative to the 12-second slot time and about 1.5 seconds for block propagation. The usual is actually “proofs are prepared quick sufficient that validators can confirm them with out breaking liveness.”
The EF now pivots from throughput to soundness, and the pivot is blunt. Many STARK-based zkEVMs have relied on unproven mathematical conjectures to realize marketed safety ranges.
Over the previous months, a few of these conjectures, particularly the “proximity hole” assumptions utilized in hash-based SNARK and STARK low-degree assessments, have been mathematically damaged, pulling down the efficient bit-security of parameter units that trusted them.
The EF says the one acceptable endgame for L1 use is “provable safety,” not “safety assuming conjecture X holds.”
They set 128-bit safety because the goal, aligning it with mainstream crypto requirements our bodies and educational literature on long-lived programs, in addition to with real-world document computations that present 128 bits is realistically out of attain for attackers.
The emphasis on soundness over pace displays a qualitative distinction.
If somebody can forge a zkEVM proof, they’ll mint arbitrary tokens or rewrite L1 state and make the system lie, not simply drain one contract.
That justifies what the EF calls a “non-negotiable” safety margin for any L1 zkEVM.
Three-milestone roadmap
The publish lays out a clear roadmap with three onerous stops. First, by the tip of February 2026, each zkEVM group within the race plugs its proof system and circuits into “soundcalc,” an EF-maintained device that computes safety estimates based mostly on present cryptanalytic bounds and the scheme’s parameters.
The story right here is “widespread ruler.” As a substitute of every group quoting their very own bit safety with bespoke assumptions, soundcalc turns into the canonical calculator and might be up to date as new assaults emerge.
Second, “Glamsterdam” by the tip of Could 2026 calls for at the least 100-bit provable safety through soundcalc, closing proofs at or under 600 kilobytes, and a compact public clarification of every group’s recursion structure with a sketch of why it must be sound.
That quietly walks again the unique 128-bit requirement for early deployment and treats 100 bits as an interim goal.
Third, “H-star” by the tip of 2026 is the complete bar: 128-bit provable safety by soundcalc, proofs at or under 300 kilobytes, plus a proper safety argument for the recursion topology. That’s the place this turns into much less about engineering and extra about formal strategies and cryptographic proofs.
Technical levers
The EF factors to a number of concrete instruments supposed to make the 128-bit, sub-300-kilobyte goal possible. They spotlight WHIR, a brand new Reed-Solomon proximity check that doubles as a multilinear polynomial dedication scheme.
WHIR affords clear, post-quantum safety and produces proofs which are smaller and verification sooner than these of older FRI-style schemes on the identical safety degree.
Benchmarks at 128-bit safety present proofs roughly 1.95 instances smaller and verification a number of instances sooner than baseline constructions.
They reference “JaggedPCS,” a set of methods for avoiding extreme padding when encoding traces as polynomials, which let provers keep away from wasted work whereas nonetheless producing succinct commitments.
They point out “grinding,” which is brute-force looking out over protocol randomness to search out cheaper or smaller proofs whereas staying inside soundness bounds, and “well-structured recursion topology,” that means layered schemes wherein many smaller proofs are aggregated right into a single closing proof with rigorously argued soundness.
Unique polynomial math and recursion methods are getting used to shrink proofs again down after cranking safety as much as 128 bits.
Unbiased work like Whirlaway makes use of WHIR to construct multilinear STARKs with improved effectivity, and extra experimental polynomial-commitment constructions are being constructed from data-availability schemes.
The mathematics is shifting quick, however it’s additionally shifting away from assumptions that seemed secure six months in the past.
What adjustments and the open questions
If proofs are constantly prepared inside 10 seconds and keep below 300 kilobytes, Ethereum can enhance the fuel restrict with out forcing validators to re-execute each transaction.
Validators would as a substitute confirm a small proof, letting block capability develop whereas retaining home-staking reasonable. Because of this the EF’s earlier real-time publish tied latency and energy explicitly to “residence proving” budgets like 10 kilowatts and sub-$100,000 rigs.
The mix of enormous safety margins and small proofs is what makes an “L1 zkEVM” a reputable settlement layer. If these proofs are each quick and provably 128-bit safe, L2s and zk-rollups can reuse the identical equipment through precompiles, and the excellence between “rollup” and “L1 execution” turns into extra of a configuration selection than a inflexible boundary.
Actual-time proving is presently an off-chain benchmark, not an on-chain actuality. The latency and price numbers come from EthProofs’ curated {hardware} setups and workloads.
There may be nonetheless a spot between that and hundreds of unbiased validators really working these provers at residence. The safety story is in flux. The entire purpose soundcalc exists is that STARK and hash-based SNARK safety parameters hold shifting as conjectures are disproven.
Current outcomes have redrawn the road between “undoubtedly secure,” “conjecturally secure,” and “undoubtedly unsafe” parameter regimes, that means at the moment’s “100-bit” settings could also be revised once more as new assaults emerge.
It is not clear whether or not all main zkEVM groups will really hit 100-bit provable safety by Could 2026 and 128-bit by December 2026 whereas staying below the proof-size caps, or whether or not some will quietly settle for decrease margins, depend on heavier assumptions, or push verification off-chain for longer.
The toughest half is probably not math or GPUs, however formalizing and auditing the complete recursion architectures.
The EF admits that completely different zkEVMs usually compose many circuits with substantial “glue code” between them, and that documenting and proving soundness for these bespoke stacks is crucial.
That opens an extended tail of labor for tasks like Verified-zkEVM and formal verification frameworks, that are nonetheless early and uneven throughout ecosystems.
A 12 months in the past, the query was whether or not zkEVMs may show quick sufficient. That query is answered.The brand new query is whether or not they can show soundly sufficient, at a safety degree that does not rely on conjectures that will break tomorrow, with proofs sufficiently small to propagate throughout Ethereum’s P2P community, and with recursion architectures formally verified sufficient to anchor tons of of billions of {dollars}.
The efficiency dash is over. The safety race simply began.
