Ethereum co-founder Vitalik Buterin has proposed a new framework for Layer-2 (L2) rollup security that could bring faster finality and stronger trust guarantees to Ethereum’s scaling ecosystem.
In a recent proposal, Buterin outlined a roadmap built around a hybrid-proof architecture that combines zero-knowledge proofs, optimistic rollups, and trusted execution environments (TEEs) while avoiding overreliance on any single system.
The proposal arrives as Ethereum’s L2 landscape matures. Several rollups have reached Stage 1 on Ethereum’s scaling roadmap, and upcoming upgrades — like Pectra and Fusaka — are expected to significantly expand the availability of data blobs for rollup use.
Buterin said the focus is now on pushing these rollups to Stage 2, which requires a higher degree of trustlessness and faster transaction finality. In the short term, he believes the most robust approach is a three-prover system, where two out of three mechanisms must validate a rollup’s state root to achieve finality.
Under this model, if both a ZK prover and a TEE prover approve a state root, the result is finalized immediately. If only one approves, the system falls back to an optimistic model that requires a seven-day challenge period.
The optimistic layer acts as a final arbiter, preventing semi-trusted systems from overriding decisions when more trustless systems disagree.
Trustless finality
Buterin emphasized that this architecture is carefully designed to meet the specific security and decentralization goals outlined for Stage 2 rollups.
It provides fast finality in normal operations, ensures that trust-minimized proof systems cannot be overridden by semi-trusted components, and reduces dependence on the current generation of ZK systems, which remain vulnerable to bugs and shared-code exploits.
He also introduced a mechanism for a security council to serve as a safeguard. This council would be able to immediately upgrade the TEE logic in case of failure and make delayed changes to the ZK or optimistic systems.
In rare scenarios — such as provers producing contradicting outcomes — the council would have the authority to intervene instantly, preserving system integrity.
According to Buterin, this combination — one ZK prover, one optimistic prover, and one TEE — represents the only viable way to achieve Ethereum’s Stage 2 goals without sacrificing speed or security.
ZK and OP systems are based on fundamentally different mathematical assumptions, making the likelihood of shared vulnerabilities extremely low. As such, pairing them with a TEE strikes a practical balance that is unlikely to fail in tandem.
Scaling with Blobs and aggregated proofs
Looking beyond proof architecture, Buterin also addressed Ethereum’s evolving data layer. He pointed to the Pectra upgrade, expected within a few weeks, which will increase blob space to six units per block.
A subsequent upgrade, Fusaka, could boost that number to as many as 72, drastically expanding the data bandwidth available to rollups. More blob space reduces congestion and makes L2 transactions cheaper and more scalable.
The roadmap also called attention to a missing piece in Ethereum’s infrastructure: a standardized, ecosystem-wide proof aggregation layer. Buterin argued that applications across the Ethereum stack — from rollups and privacy protocols to wallet recovery tools — should not have to submit individual zero-knowledge proofs.
Instead, a shared aggregation mechanism would allow all such applications to combine their outputs into a single, unified proof. This would dramatically lower gas costs by spreading the roughly 500,000 gas burden of proof submission across all participants.
Buterin noted that the Ethereum community is already on track to produce ZK-EVMs capable of generating proofs within a single slot, even under worst-case conditions.
As these systems mature and eliminate critical bugs, TEEs could eventually be phased out entirely. In that scenario, Ethereum rollups would achieve full trustlessness, with instant finality and zero reliance on semi-trusted components.
Mentioned in this article
