@Sakura please summarize this article, thanks uwu.
TLDR
Ethereum zkEVMs have made major speed gains; the next challenge is proving they’re secure enough for mainnet. The article proposes measurable security and proof-size milestones, aiming for 128-bit provable security by the end of 2026. 
Key Points
Proving has accelerated dramatically: latency fell from 16 minutes to 16 seconds, and zkVMs can prove 99% of Ethereum blocks in under 10 seconds on target hardware.
The article argues that zkEVMs need provable security—not estimates that rely on mathematical conjectures that may later fail. A forged proof could let an attacker rewrite state or steal funds.
Security must be balanced with proof size, so proofs remain practical to transmit across Ethereum’s peer-to-peer network.
Teams are asked to integrate their systems with soundcalc, a shared tool for estimating zkVM security.
The roadmap targets 100-bit security and proofs ≤600 KiB by Glamsterdam, then 128-bit security and proofs ≤300 KiB by H-star, alongside stronger documentation and formal arguments for recursion.
In-depth summary
The article marks a shift in priorities for the zkEVM ecosystem. After substantial progress in proving speed and cost, the author says the central question is now whether zkEVMs can prove Ethereum blocks soundly—that is, whether their proof systems can reliably prevent invalid computations from being accepted. This is especially important for an L1 system securing large amounts of value: a soundness failure could enable forged proofs with potentially catastrophic consequences.
To make security assessments consistent, the Ethereum Foundation created soundcalc, which estimates security using current cryptographic bounds and proof-system parameters. The first milestone asks participating teams to integrate their components and circuits into the tool. Later targets pair security levels with proof-size limits: 100-bit provable security and proofs no larger than 600 KiB by the Glamsterdam milestone, followed by 128-bit security and proofs no larger than 300 KiB by H-star. Teams are also expected to document their recursion architecture and explain—or formally establish—why it is sound.
The author points to techniques such as compact polynomial commitments, grinding, and carefully designed recursion as possible ways to meet both security and proof-size goals. Stabilizing zkVM architectures is also presented as a prerequisite for formal verification: once systems change less, critical components can be verified and specifications can better match the deployed code. The Foundation plans to clarify the milestones, publish technical guidance, and update Ethproofs to highlight security alongside performance.
ELI5
zkEVMs have learned to make proofs quickly. Now they need to show that those proofs are really trustworthy. The plan is to give teams shared tools and clear targets, while keeping proofs small enough to send around the network. 
Writers main point
Fast proving is no longer enough: secure L1 zkEVMs need strong, measurable, and eventually formal security foundations.