{"id":17375,"date":"2026-02-18T01:36:44","date_gmt":"2026-02-18T01:36:44","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/02\/18\/shipping-an-l1-zkevm-2-the-security-foundations\/"},"modified":"2026-02-18T01:36:44","modified_gmt":"2026-02-18T01:36:44","slug":"shipping-an-l1-zkevm-2-the-security-foundations","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/02\/18\/shipping-an-l1-zkevm-2-the-security-foundations\/","title":{"rendered":"Shipping an L1 zkEVM #2: The Security Foundations"},"content":{"rendered":"


\n<\/p>\n

\n

Thanks to Arantxa Zapico, Benedikt Wagner, and Dmitry Khovratovich from the EF cryptography team for their contributions, and to Ladislaus, Kev, Alex, and Marius for the careful review and feedback.<\/em><\/p>\n

\n

The zkEVM ecosystem has been sprinting for a year. And it worked! We crossed the finish line for real-time proving!<\/p>\n

Now comes the next phase: building something mainnet-grade.<\/p>\n

<\/g><\/svg><\/a>From speed to security<\/h2>\n

In July, we published a north-star definition<\/a> for realtime proving. Nine months later, the ecosystem crushed it<\/a>: proving latency dropped from 16 minutes to 16 seconds, costs collapsed 45\u00d7, and zkVMs now prove 99% of all Ethereum blocks in under 10 seconds on target hardware.<\/p>\n

While the major performance bottlenecks have been cleared by the zkEVM teams, security still remains the elephant in the room.<\/p>\n

<\/g><\/svg><\/a>The case for 128-bit provable security<\/h2>\n

Many STARK-based zkEVMs today rely on unproven mathematical conjectures to hit their security targets. Over the past months, STARK security has been going through a lot<\/a>, with foundational conjectures getting mathematically disproven<\/a> by researchers. Each conjecture that falls takes bits of security with it: what was advertised as 100 bits might actually be 80.<\/p>\n

The only reasonable path forward<\/a> is provable security<\/em>, and 128 bits remains the target<\/a>. It’s the security level recommended by standardization bodies<\/a> and validated by real-world computational milestones<\/a>.<\/p>\n

For zkEVMs, this isn’t academic. A soundness issue is not like other security issues. If an attacker can forge a proof, they can forge anything: mint tokens from nothing, rewrite state, steal funds. For an L1 zkEVM securing hundreds of billions of dollars, the security margin is not negotiable.<\/p>\n

<\/g><\/svg><\/a>Three Milestones<\/h2>\n

For us, security and proof size are both critical\u2014but they’re also in tension. More security typically means larger proofs, and proofs must stay small enough to propagate across Ethereum’s P2P network reliably and in time.<\/p>\n

We are setting three milestones:<\/p>\n

Milestone 1: soundcalc integration<\/strong> Deadline: End of February 2026<\/em><\/p>\n

To measure security consistently, we created soundcalc<\/a>: a tool that estimates zkVM security based on the latest cryptographic security bounds and proof system parameters. It’s a living tool and we plan to keep integrating the latest research and known attacks.<\/p>\n

By this deadline, participating zkEVM teams should have their proof system components and all of their circuits integrated with soundcalc. This gives us a common ground for the security assessments that follow. (For reference, see examples of previous integrations: #1<\/a>, #2<\/a>)<\/p>\n

Milestone 2: Glamsterdam<\/strong> Deadline: End of May 2026<\/em><\/p>\n