Standing at this historical turning point where "not moving forward means falling behind," the gentle, incremental iterations of the past may no longer be enough to support Ethereum's vision of becoming a global settlement layer. This time, Ethereum doesn't have much time left to be sluggish.

Article author and source: Chloe, ChainCatcher

Over the past two weeks, Ethereum founder Vitalik Buterin has released a series of lengthy technical articles on X, covering core topics such as scaling roadmaps, quantum attack resistance, account abstraction, execution layer restructuring, and AI-accelerated development. These articles have been dubbed the "2026 Ethereum Overhaul Roadmap." Behind this series of posts is the Ethereum Foundation's simultaneous release of the Strawmap roadmap framework, a document outlining a plan to push Ethereum's L1 throughput to 10,000 TPS by 2029.

However, the more ambitious the blueprint, the more questions arise about its delivery capabilities. After all, historically, Ethereum's delivery pace has always been slower than expected. Is Ethereum truly ready to bid farewell to "gradualism" and usher in a radical refactoring this time?

Strawmap Roadmap: Ethereum to achieve 10,000 TPS by 2029

On February 25th, Ethereum Foundation researcher Justin Drake released a roadmap titled Strawmap , designed to reveal the vision and future upgrade timeline for Ethereum's L1. This roadmap sets five "North Star" goals: ultra-fast L1 performance, L1 gigagas throughput, L2 teragas scaling, post-quantum L1 security, and native L1 privacy transfers. The ultimate quantitative goals are 10,000 transactions per second for L1 and 10 million transactions per second for L2.

This plan is expected to be implemented through seven forks, with an upgrade cycle of six months, covering various changes to the consensus layer, data layer, and execution layer. Ethereum founder Vitalik Buterin has expressed his support and has published numerous technical articles on X over the past two weeks, breaking down the core dimensions of the roadmap.

Strategic Focus: Ethereum L1 scaling and execution layer refactoring

Vitalik's argument shows that, unlike the strategy of focusing on L2 rollup and neglecting L1 in the past few years, the current vision is to significantly improve the scalability of L1 itself in the short term while maintaining long-term shifts.

1. Short-term progress: Glamsterdam upgrade

In the short term, the upcoming Glamsterdam upgrade will introduce "Block-Level Access Lists (BALs)" to support parallel verification, breaking the efficiency bottleneck of the past sequential processing, and at the same time promoting Enshrined Proposer-Builder Separation (ePBS) to optimize the utilization of the 12-second time slot by the nodes.

2. Long-term process: Evolution of ZK-EVM and Blob

Long-term scaling is supported by two main pillars: ZK-EVM and Blob. On the ZK-EVM path, it is expected that a small number of validators will adopt the ZK-EVM client by the end of 2026, with the adoption rate increasing and security strengthened from 2027 onwards. The ultimate goal is to achieve a "3-of-5 mandatory multiple proof mechanism," meaning a block must be verified by at least three of the five proof systems to be valid.

Along the Blob development path, PeerDAS (Data Availability Sampling) will continue to iterate, aiming to increase data processing capacity to approximately 8 MB/s. The core of this technology lies in allowing nodes to complete verification by downloading only a small number of data fragments, significantly increasing throughput while effectively lowering the hardware barrier for nodes. On the other hand, to meet the demands of future large-scale adoption, the Ethereum mainnet will shift to storing block data directly in the Blob space, replacing the previously expensive and permanently stored calldata model. This shift is primarily aimed at optimizing the data storage structure, reshaping Ethereum's scaling path at the data layer.

3. Execution layer refactoring: Switching to a binary state tree to replace the EVM

Vitalik pointed out that 80% of Ethereum's current proof efficiency bottlenecks stem from its outdated architecture. According to EIP-7864, it is expected that switching from the current "hexadecimal Keccak MPT state tree" to a "binary state tree" will effectively shorten branch length by a factor of four. This change will bring a significant improvement in data efficiency.

• Data bandwidth: Costs are reduced by about 4 times, which is a significant leap forward for light clients such as Helios.
• Proof of speed: If BLAKE3 is used, the speedup is about 3 times; if the Poseidon variant is used, the potential speedup is up to 100 times.
• Access optimization: The storage slot “page” design (64–256 slots) allows DApps to save more than 10,000 gas per transaction when reading and writing adjacent data.

A more ambitious proposal is VM (Virtual Machine) migration . Currently, most ZK provers are written in RISC-V. If the EVM can run directly in RISC-V, eliminating the translation overhead between the two virtual machine layers, the provability of the entire system will be significantly improved. The current deployment path is planned in three steps:

1. First, let the new VM take over the existing pre-compiled contracts.

2. Reopen user deployment of new VM contracts

3. Finally, the EVM itself is rewritten as a smart contract running on the new VM.

This ensures backward compatibility, and the final conversion cost only requires a recalibration of gas fees.

Roadmap to Combat Quantum Threats: Addressing Ethereum's Four Major Technical Vulnerabilities

Regarding the critical issue of post-quantum L1 security, Vitalik explicitly stated in his technical article that Ethereum currently has four quantum vulnerabilities, as follows:

1. Consensus Layer: BLS Signature

The replacement path for the consensus layer is beginning to take shape: Vitalik proposed the "Lean consensus" scheme, introducing a hash-based signature variant and using STARKs for aggregation and compression to achieve resistance to quantum attacks. However, Vitalik added that before the full implementation of "Lean consensus," a "lean and usable chain" version will be launched first, requiring only 256 to 1,024 signatures to be processed per slot, and can operate without STARK aggregation for the time being, significantly reducing the engineering threshold.

2. Data Availability: KZG Commitment and Proof

Regarding data availability, Vitalik proposed replacing the existing "KZG commitment" with "quantum-resistant STARKs," but this faces two major trade-offs:

First, STARKs lack the linearity of KZG, making it difficult to support efficient 2D data sampling. Therefore, Ethereum chooses a more conservative 1D DAS (such as PeerDAS) path, prioritizing network robustness rather than pursuing extreme scaling.

Secondly, due to the large size of STARK proofs, developers need to solve the engineering problem of "proofs being larger than data" through complex engineering methods such as recursive proofs. In summary, Vitalik believes that by simplifying the technical goals and optimizing in stages, this quantum-resistant path is still feasible in engineering, but the amount of engineering required is enormous.

3. External Holding Account (EOA): ECDSA Signature

Regarding the protection of External Accounts (EOAs), since the current ECDSA signature is extremely vulnerable to quantum computers, Vitalik tends to contract all accounts through "native account abstraction," allowing users to flexibly switch to quantum-resistant signature algorithms without having to abandon their existing wallet addresses.

4. Application Layer: ZK proofs relying on KZG or Groth16

Finally, at the application layer, the main challenge is that the gas cost of quantum-resistant STARK proofs is extremely high, about 20 times that of current SNARKs, which is too expensive for privacy protocols and L2. Vitalik proposed to introduce a "Validation Frame" through EIP-8141 to aggregate a large number of complex signatures and proofs off-chain.

By using recursive proof technology, the original verification data, which was hundreds of MB, can be compressed into a tiny STARK proof on the chain. This not only saves block space but also significantly reduces usage costs. It can even complete verification in real time at the Mempool stage, allowing users to operate various decentralized applications in a low-cost and efficient manner in the era of quantum threats.

AI as an accelerator: Ethereum 2030 roadmap to be completed in weeks

In addition to upgrades to the technical architecture, Vitalik's recent tweets emphasized that AI is accelerating the development of Ethereum. He retweeted an experiment by developers who "built a prototype of the 2030 Ethereum roadmap in two weeks using vibe-coding," commenting, "Six months ago, this was not even within the realm of possibility, but now it has become a trend."

Even Vitalik himself tested it out, using the gpt-oss:20b model running on his laptop to complete the blog's backend code in an hour; with the more powerful kimi-2.5, he expected to be able to "get it done in one go." It's fair to say that AI's efficiency improvements are growing non-linearly, and it's changing the delivery speed of the Ethereum roadmap.

In response, he advocates allocating half of the benefits of AI to speed and half to security, using AI to generate large-scale test cases, perform formal verification of core modules, and generate multiple independent implementations of the same logic for cross-comparison. Vitalik's judgment is that in the foreseeable future, you cannot exchange a prompt for a highly secure piece of code; the struggle with bugs and implementation inconsistencies will still exist, but this process can be improved by 5 times.

Finally, he also raised the possibility that the Ethereum roadmap will be completed faster than expected, and that security standards will be higher than anticipated. "Bug-free code, long considered an idealistic fantasy, may now become a reality." This statement, placed in the context of Ethereum development five years ago, would have been almost impossible.

Slow delivery pace and real-world challenges

However, with so much complex technical information being made public, the Ethereum roadmap will always be hampered by the possibility of these promises being fulfilled on time.

Historically, Ethereum's delivery pace has always been slower than expected. The Merge, initially anticipated at the end of 2020, was delayed until September 2022; the implementation of EIP-4844 (Proto-Danksharding) also took several years. These delays are typically due to factors such as security audits, multi-client coordination, and decentralized governance.

This time, however, Ethereum doesn't have much time left to be sluggish. The relentless advance of competitors, the real challenge of the quantum threat, and the productivity revolution brought about by AI are forcing Ethereum to completely abandon "gradualism." Standing at a historical turning point where "if you don't move forward, you fall behind," the gentle, incremental iterations of the past may no longer be enough to support Ethereum's vision of becoming a global settlement layer.

Vitalik 's recent appeal also points out that this transformation is not just a technical restructuring. He calls on the community to completely abandon path dependence at the application layer, uphold the core of censorship resistance, open source, privacy, and security (CROPS), and start afresh from first principles in application design.

Technology can have a roadmap, but the upgrading of thinking has no branching timetable. This may be the most difficult step in saying goodbye to "gradualism".