For the past year, the zero-knowledge Ethereum Virtual Machine (zkEVM) ecosystem has been in a relentless sprint, primarily focused on improving latency. This intense effort has yielded impressive results: the time it takes to prove an Ethereum block has dramatically shrunk from a laborious 16 minutes down to a mere 16 seconds. Concurrently, associated costs have plummeted by a staggering 45-fold, and today, participating zkVMs are proving an astonishing 99% of mainnet blocks in under 10 seconds on their designated hardware. The Ethereum Foundation (EF) celebrated this achievement on December 18, confidently declaring that real-time proving is now a reality and that performance bottlenecks have largely been cleared.
However, with this victory comes a significant pivot. The EF now asserts that raw speed, without an unwavering foundation of soundness, transforms from an asset into a critical liability. The underlying mathematics supporting many STARK-based zkEVMs have, in fact, been quietly faltering for several months, prompting an urgent reevaluation of priorities.
The Pivotal Shift: From Speed to Uncompromising Soundness
Back in July, the Ethereum Foundation outlined a comprehensive target for what it termed 'real-time proving.' This ambitious goal wasn't just about speed; it bundled latency, hardware efficiency, energy consumption, open-source accessibility, and crucially, security. The specific benchmarks included proving at least 99% of mainnet blocks within 10 seconds, using hardware costing around $100,000 and operating within 10 kilowatts, all with fully open-source code, a 128-bit security level, and proof sizes capped at or below 300 kilobytes. The December 18 announcement confirmed the ecosystem's success in meeting the performance aspects of this target, as validated by the EthProofs benchmarking site.
In this context, 'real-time' means proofs are generated swiftly enough for validators to verify them without disrupting the network's liveness, considering the 12-second slot time and approximately 1.5 seconds for block propagation. With performance targets met, the EF is now unequivocally shifting its focus from throughput to soundness, and this shift is stark. Many STARK-based zkEVMs have been relying on unproven mathematical conjectures to claim their advertised security levels. Over recent months, some of these critical conjectures, particularly the 'proximity gap' assumptions prevalent in hash-based SNARK and STARK low-degree tests, have been mathematically invalidated. This has effectively downgraded the true bit-security of parameter sets that depended on them.
The Ethereum Foundation's stance is clear: the only acceptable outcome for Layer 1 usage is provable security, not security contingent on a fragile conjecture. They have established 128-bit security as the absolute target, aligning with widely recognized mainstream cryptographic standards, academic literature on long-lived systems, and real-world computations that confirm 128 bits is realistically beyond the reach of current attackers. This emphasis on soundness is paramount, as a forged zkEVM proof could allow an attacker to mint arbitrary tokens or rewrite the Layer 1 state, effectively making the entire system lie, a threat far more severe than merely draining a single contract. This grave risk underscores why the EF labels a robust security margin for any L1 zkEVM as 'non-negotiable.'
A Three-Milestone Roadmap to Ironclad Security
To navigate this critical transition, the EF has unveiled a clear, three-milestone roadmap with stringent deadlines:
- First Milestone: soundcalc Integration (End of February 2026)
Every zkEVM team must integrate its proof system and circuits into 'soundcalc,' an EF-maintained tool. soundcalc will serve as the common ruler, computing standardized security estimates based on current cryptanalytic bounds and each scheme's parameters. This eliminates bespoke, assumption-laden security claims, providing a canonical, updatable calculator as new attacks emerge. - Second Milestone: Glamsterdam (End of May 2026)
By this deadline, teams must demonstrate at least 100-bit provable security via soundcalc. Additionally, final proof sizes must be at or below 600 kilobytes, accompanied by a concise public explanation of each team's recursion architecture and a sketch of its soundness argument. This milestone temporarily adjusts the initial 128-bit requirement for early deployment, treating 100 bits as an interim stepping stone. - Third Milestone: H-star (End of 2026)
This is the ultimate bar: teams must achieve 128-bit provable security as validated by soundcalc. Proofs must be at or below 300 kilobytes, and critically, a formal security argument for the entire recursion topology is required. This phase transcends pure engineering, delving deep into formal methods and rigorous cryptographic proofs.
Leveraging Technical Innovations for the Future
The Ethereum Foundation highlights several concrete technical tools and strategies designed to make the challenging 128-bit, sub-300-kilobyte target achievable:
- WHIR: A novel Reed-Solomon proximity test that doubles as a multilinear polynomial commitment scheme. WHIR offers transparent, post-quantum security, yielding proofs that are smaller and verify faster than older FRI-style schemes at equivalent security levels. Benchmarks at 128-bit security show proofs that are roughly 1.95 times smaller and verification times several times faster than baseline constructions.
- JaggedPCS: These techniques help avoid excessive padding when encoding traces as polynomials, ensuring provers don't waste computational effort while still producing succinct commitments.
- Grinding: A brute-force search method over protocol randomness to discover cheaper or smaller proofs, all while strictly adhering to soundness bounds.
- Well-structured Recursion Topology: This refers to layered schemes where numerous smaller proofs are efficiently aggregated into a single, compact final proof, supported by carefully argued soundness. This sophisticated polynomial math and recursion trickery are crucial for shrinking proof sizes even as security is boosted to 128 bits.
Independent efforts, such as Whirlaway, are already leveraging WHIR to construct more efficient multilinear STARKs. Furthermore, experimental polynomial-commitment schemes are being developed from existing data-availability solutions. The cryptographic landscape is evolving rapidly, moving away from assumptions that were considered robust just six months ago.
The Road Ahead: Challenges and Open Questions
Should proofs consistently meet the 10-second generation time and remain under 300 kilobytes, Ethereum gains a significant advantage: the ability to increase its gas limit without forcing validators to re-execute every transaction. Instead, validators could simply verify a compact proof, allowing block capacity to expand while maintaining the feasibility of home-staking. This is precisely why the EF's earlier real-time post explicitly linked latency and power to 'home proving' budgets, such as 10 kilowatts and sub-$100,000 rigs. The synergy of ample security margins and small proof sizes is what will establish an 'L1 zkEVM' as a credible settlement layer. If these proofs are both fast and provably 128-bit secure, Layer 2s and zk-rollups can seamlessly reuse the same machinery via precompiles, blurring the distinction between 'rollup' and 'L1 execution' into more of a configuration choice than a rigid boundary.
However, the journey isn't without its challenges. Real-time proving, for now, remains an off-chain benchmark, not a widespread on-chain reality. The latency and cost figures are derived from EthProofs' meticulously curated hardware setups and workloads, leaving a gap between these benchmarks and thousands of independent validators running these provers at home. The security narrative itself is in flux; the very existence of soundcalc underscores that STARK and hash-based SNARK security parameters are dynamic, shifting as conjectures are disproven. Recent findings have redrawn the lines between 'definitely safe,' 'conjecturally safe,' and 'definitely unsafe' parameter regimes, implying that today's '100-bit' settings might require further revision as new attacks inevitably emerge.
It remains uncertain whether all major zkEVM teams will genuinely achieve 100-bit provable security by May 2026 and the full 128-bit by December 2026, all while adhering to the strict proof-size caps. Some might opt for lower margins, rely on heavier assumptions, or push verification further off-chain. Perhaps the most formidable hurdle isn't just the math or the GPUs, but the formalization and rigorous auditing of complex recursion architectures. The EF acknowledges that diverse zkEVMs often comprise many circuits, bound together by substantial 'glue code.' Documenting and formally proving the soundness of these bespoke stacks is absolutely essential, opening a long and demanding tail of work for projects like Verified-zkEVM and formal verification frameworks, which are still nascent and vary significantly across different ecosystems.
A year ago, the prevailing question was whether zkEVMs could prove fast enough. That question has been answered decisively. The new, critical inquiry is whether they can prove soundly enough, at a security level that doesn't hinge on conjectures that might crumble tomorrow, with proofs compact enough for Ethereum's P2P network, and with recursion architectures formally verified to safeguard potentially hundreds of billions of dollars. The performance sprint is indeed over; the security race has only just begun.
Post a Comment