Thanks to Arantxa Zapico, Benedikt Wagner, and Dmitry Khovratovich of the EF crypto team for their contributions, and to Ladislaus, Kev, Alex, and Marius for their careful review and feedback.
The zkEVM ecosystem has been sprinting for a year. And it worked! We crossed the finish line to prove it in real time!
Now comes the next phase: creating something mainnet quality.
From speed to security
In July, we published a North Star definition of real-time proof. Nine months later, the ecosystem crushed it: proof latency dropped from 16 minutes to 16 seconds, costs were reduced by 45, and zkVMs now prove 99% of all Ethereum blocks in less than 10 seconds on target hardware.
Although the major performance bottlenecks have been resolved by the zkEVM teams, security still remains the elephant in the room.
The case for provable 128-bit security
Many STARK-based zkEVMs today rely on unproven mathematical conjectures to achieve their security goals. Over the past few months, STARK’s security has faced numerous challenges, with fundamental conjectures mathematically disproven by researchers. Each guess that falls brings with it security elements: what was announced as 100 bits could in reality be worth 80.
The only reasonable path to follow is provable securityand 128 bits remains the target. This is the security level recommended by standards organizations and validated by real IT steps.
For zkEVMs, this is not academic. A solidity problem is not a security problem like any other. If an attacker can falsify a proof, they can falsify anything: create tokens from scratch, rewrite a state, steal funds. For an L1 zkEVM securing hundreds of billions of dollars, the margin of security is non-negotiable.
Three milestones
For us, safety and event size are both essential, but they are also in tension. More security generally means larger proofs, and proofs must remain small enough to propagate reliably and on time across Ethereum’s P2P network.
We set three milestones:
Milestone 1: soundcalc integration Deadline: end of February 2026
To measure security consistently, we created soundcalc: a tool that estimates the security of zkVM based on the latest cryptographic security limits and proof system settings. It is a living tool and we plan to continue incorporating the latest research and known attacks.
By this deadline, participating zkEVM teams should have their proof system components and all their integrated circuits in soundcalc. This gives us common ground for the security assessments that follow. (For reference, see previous integration examples: #1, #2)
Step 2: Glamsterdam Deadline: end of May 2026
- 100-bit provable security (as estimated by soundcalc)
- Final proof size ≤ 600 KB
- Compact description of the recursion architecture and sketch of its robustness
Milestone 3: H-star Deadline: end of 2026
- 128-bit provable security (as estimated by soundcalc)
- Final proof size ≤ 300 KB
- Formal security argument for the robustness of the recursion architecture
Recent advances in cryptography and engineering make it possible to achieve the above steps: compact polynomial commitment schemes like WHIR, techniques like JaggedPCS, a bit of grinding, and a well-structured recursion topology can all contribute to a viable path forward.
Recursion is particularly worth highlighting. Modern zkEVMs involve lots of custom recursively composed circuitry, with lots of glue in between. Every team does it differently. Documenting this architecture and its robustness is essential for the security of the entire system.
The way forward
There is a strategic reason to lock down zkEVM security now.
It is difficult to secure a moving target. Once the teams achieve these goals and the zkVM architectures stabilize, the formal verification work we have invested in will be able to reach its full potential. By H-star, we hope that the proof system layer will have mainly ruler. Not fixed forever, but stable enough to formally verify critical components, finalize security proofs, and write specifications that match the deployed code.
This is the basis needed to secure L1 zkEVMs.
Building foundations
A year ago, the question was whether zkEVMs would be fast enough. This question is answered. The new question is whether they can prove it strongly enough. We are confident they can.
On our side:
- In January, we will publish an article clarifying and formalizing the steps above.
- We will follow with a technical article describing proof system techniques to achieve security and proof size goals.
- At the same time, we will update Ethproofs to reflect this change: emphasizing security alongside performance.
- We are here to help you through this process. Contact the EF crypto team.
The performance sprint is over. Now let’s strengthen the foundations.
