---- The one-year sprint of zkEVM has ended; can it take off in 2026?
Over the past year, the zkEVM ecosystem has achieved an almost impossible engineering leap:
The Ethereum block verification time has been compressed from 16 minutes to 16 seconds, costs have decreased by 45 times, and mainstream zkVMs can now complete 99% of mainnet block verifications within 10 seconds on target hardware.
From 'theoretically feasible' to 'engineerable'.
However, the Ethereum Foundation (EF) sent a very clear signal on December 18:
Speed is no longer the focus; security is.
EF states that without sufficiently strong security support, real-time proof is not an advantage but a burden. The reason is quite realistic—recently, several mathematical conjectures relied upon by STARK's zkEVM have been disproven, directly lowering the actual security level. This is not a performance issue, but a systemic risk.
From this moment on, the evaluation criteria for zkEVM have fundamentally changed.
⸻
From 'faster' to 'can it be trusted'
When EF proposed the comprehensive goal of real-time proof in July, it had already planted the seeds:
Latency, hardware, and throughput are just surface layers; provable security is the underlying constraint.
Now this line has been completely clarified:
L1 level zkEVM must achieve 128-bit security. There is no room for negotiation.
The reason is simple:
Once the proof system is falsified, the consequence is not 'rollback a transaction', but that tokens can be minted out of thin air, and L1 state can be permanently tampered with.
This is a risk at the settlement layer level and cannot be comforted by 'the probability is very small.'
⸻
The three-phase 'security countdown' provided by EF
EF has simultaneously announced a very hardcore roadmap, integrating zkEVM into a unified security measurement system for the first time:
① Before the end of February 2026
All zkEVM teams must connect to EF's soundcalc tool for a unified security assessment standard.
② Before the end of May (Glamsterdam phase)
Achieve about 100-bit security as a transitional threshold.
③ Before the end of December (H-star conclusion)
Achieve 128-bit provable security, and
👉 A formal security argument for the topology of recursive proofs must be provided.
This step is as difficult as the performance breakthrough itself.
⸻
The technology is not absent, but the difficulty has been severely underestimated.
The solutions mentioned by EF, such as WHIR, JaggedPCS, and recursive topologies, can indeed improve efficiency and compress proof sizes without sacrificing security.
But real challenges still exist:
• Real-time proof has not yet truly run on-chain; the actual burden on verifiers remains unknown.
• Security parameters need to be dynamically adjusted with the progress of mathematical research.
• Not all zkEVM teams have the ability to meet the standards on time.
• The formal verification of recursive architecture is still in its early stages.
In other words:
This is not a process of 'upgrading together', but a brutal security elimination race.
⸻
Once successful, the impact will be very significant.
If zkEVM truly achieves L1 level 128-bit security:
• Ethereum can safely raise the Gas Limit.
• Expand block capacity without sacrificing staking feasibility.
• L1 has evolved from 'expensive but trustworthy' to a highly throughput credible settlement layer.
• The boundary between L2 and L1 at the execution layer will begin to blur.
This is not the victory of a single Rollup, but a reassessment of the Ethereum settlement layer's capabilities.
⸻
The performance sprint has ended; the security race has just begun.
What zkEVM needs to answer next is not 'how much faster can it be',
But:
Without relying on mathematical conjectures that may fail at any time,
Is it really sufficient to support assets worth hundreds of billions?
This will be 2026, the most core and realistic mainline of the Ethereum ecosystem.
