Ethereum Overhaul 2026 Blueprint, this time to abandon "gradualism"

Author: Chloe, ChainCatcher

In the past two weeks, Ethereum founder Vitalik Buterin has intensively published several technical long articles on X, covering core topics such as scaling routes, quantum attack resistance, account abstraction, execution layer reconstruction, and AI-accelerated development, which has been referred to by the outside world as the "2026 Ethereum Major Overhaul Blueprint." Behind this series of publications is the Strawmap route sketch framework released simultaneously by the Ethereum Foundation, a document that plans to advance Ethereum L1 throughput to the level of 10,000 TPS by 2029.

However, the greater the ambition of the blueprint, the more doubts arise about its delivery capability, as historically, Ethereum's delivery pace has always been slower than expected. Is Ethereum really ready to say goodbye to "incrementalism" and embrace radical reconstruction?

Strawmap Route Sketch: Achieving 10,000 TPS for Ethereum by 2029

Ethereum Foundation researcher Justin Drake released a route sketch named Strawmap on February 25, aiming to reveal the vision for Ethereum L1 and the future upgrade timeline. The blueprint sets five major "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 goal is for L1 to process 10,000 transactions per second, with L2 reaching 10 million transactions per second.

This plan is expected to advance through seven forks, with an upgrade cycle of every six months, covering various changes in the consensus layer, data layer, and execution layer. In response, Ethereum founder Vitalik Buterin expressed support, also intensively publishing technical long articles on X in the past two weeks, breaking down the core dimensions of the roadmap.

Strategic Focus: Concentrating on Ethereum L1 Scaling and Execution Layer Reconstruction

Vitalik's arguments show that, unlike the past few years' focus on L2 Rollups and light L1 strategies, the current vision aims to significantly enhance L1's own scaling capabilities in the short term while maintaining a long-term shift.

1. Short-term Progress: Glamsterdam Upgrade

In the short-term plan, the upcoming Glamsterdam upgrade will introduce "Block-Level Access Lists (BALs)" to support parallel validation, breaking the efficiency bottleneck of sequential processing in the past, while also advancing the separation of native proposers and builders (Enshrined Proposer-Builder Separation, ePBS) to optimize node utilization of the 12-second time slots.

2. Long-term Progress: ZK-EVM and Blob Evolution

Long-term scaling will be supported by two main pillars: ZK-EVM and Blob. On the ZK-EVM path, it is expected that by the end of 2026, a small number of validators will adopt the ZK-EVM client, with the proportion expanding and security being strengthened starting in 2027. The ultimate goal is to achieve a "3-of-5 mandatory multi-proof mechanism," meaning a block must be validated by at least three out of five proof systems to take effect.

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

3. Execution Layer Reconstruction: Switching to Binary State Trees, Replacing EVM

Vitalik pointed out that the current proof efficiency bottleneck in Ethereum comes 80% from outdated architecture. According to EIP-7864, it is expected that after switching from the current "hexadecimal Keccak MPT state tree" to a "binary state tree," the branch length can be effectively reduced by four times. This transformation will bring significant improvements in data efficiency:

• Data bandwidth: Costs reduced by about four times, which is a qualitative leap for light clients like Helios.

• Proof speed: If using BLAKE3 computation, speeds can increase by about three times; if using Poseidon variants, potential speed increases can reach 100 times.

• Access optimization: The design of storage slot "pages" (64--256 slots) allows DApps to save over 10,000 Gas per transaction when reading and writing adjacent data.

A more ambitious proposal is the migration of the VM (Virtual Machine), as current ZK provers are mostly written in RISC-V. If the EVM can run directly in RISC-V, eliminating the translation overhead between the two layers of virtual machines, the overall system's provability will be greatly enhanced. The current deployment path is planned in three steps:

1. First, let the new VM take over existing precompiled contracts.

2. Then, open up user deployment of new VM contracts.

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

This move ensures backward compatibility, and the final conversion cost will only require recalibrating Gas fees.

Quantum Threat Roadmap: Addressing Four Major Technical Vulnerabilities of Ethereum

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

1. Consensus Layer: BLS Signatures

The replacement path for the consensus layer has begun to take shape: Vitalik proposed a "Lean consensus" plan, introducing a hash-based signature variant combined with STARKs for aggregation and compression to achieve resistance against quantum attacks. However, Vitalik added that before the comprehensive implementation of "lean consensus," a "lean usable chain" version will be launched first, requiring only 256 to 1,024 signatures per slot, and can operate without STARK aggregation, significantly lowering engineering thresholds.

2. Data Availability: KZG Commitments and Proofs

In terms of data availability, Vitalik proposed replacing the existing "KZG commitments" with STARKs that have "quantum-resistant characteristics," but this faces two major trade-offs:

First, STARKs lack the linear properties of KZG, making it difficult to support efficient 2D data sampling. Therefore, Ethereum has chosen a more conservative 1D DAS (like PeerDAS) path, prioritizing network robustness over extreme scaling.

Second, due to the large size of STARK proofs, developers need to solve the engineering challenge of "proofs being larger than data" through complex engineering such as recursive proofs. In summary, Vitalik believes that by simplifying technical goals and optimizing in phases, this quantum-resistant path remains feasible from an engineering perspective, but the required engineering effort is substantial.

3. Externally Owned Accounts (EOA): ECDSA Signatures

In protecting externally owned accounts (EOA), since the current ECDSA signatures are extremely vulnerable to quantum computers, Vitalik prefers to use "native account abstraction (native AA)" to turn all accounts into contracts, allowing users to flexibly switch quantum-resistant signature algorithms without abandoning existing wallet addresses.

4. Application Layer: Relying on KZG or Groth16 ZK Proofs

Finally, in 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 introducing a "Validation Frame" through EIP-8141, allowing a large number of complex signatures and proofs to be aggregated off-chain.

By using recursive proof technology, the originally hundreds of MB of verification data can ultimately be compressed into a very small STARK proof on-chain, saving block space and significantly reducing usage costs, even allowing for instant verification during the Mempool stage, enabling users to operate various decentralized applications in a low-cost and efficient manner in the era of quantum threats.

AI as an Accelerator: Completing the Ethereum 2030 Roadmap in Weeks

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

Even Vitalik himself tested this, using a laptop to run the gpt-oss:20b model, completing the backend code for a blog in one hour; if he switched to the more powerful kimi-2.5, he expected to "get it done in one go." It can be said that AI's improvement in efficiency is no longer linear; it is changing the delivery speed of the Ethereum roadmap.

In this regard, he advocates sharing the benefits brought by AI "half for speed, half for security," using AI to generate large-scale test cases, perform formal verification on core modules, and generate multiple independent implementations for the same logic for cross-comparison. Vitalik's judgment is that in the foreseeable future, you cannot exchange a prompt for a piece of high-security program code, and the process of battling bugs and implementation inconsistencies still exists, but this process can be improved fivefold.

Finally, he proposed a possibility that the Ethereum roadmap will be completed faster than the outside world expects, and the security standards will be higher than expected. "Bug-free program code, long regarded as an idealistic fantasy, may now become possible." This statement, if placed in the context of Ethereum development five years ago, would have been almost impossible to utter.

Slow Delivery Pace and Real-World Challenges

However, publicly sharing so much complex technical content with the market means that the Ethereum roadmap can never escape the possibility of these commitments being delivered on time.

Historically, Ethereum's delivery pace has always been slower than expected. The Merge was delayed from the initial "end of 2020" expectation to September 2022; the implementation of EIP-4844 (Proto-Danksharding) also took several years. Such delays are usually due to factors like security audits, multi-client coordination, and decentralized governance.

However, this time, Ethereum has little time left for sluggishness. The relentless pressure from competitors, the real challenges posed by quantum threats, and the productivity revolution triggered by AI are forcing Ethereum to completely say goodbye to "incrementalism"; standing at a historical turning point of "no progress means regression," the past gentle iterative approach may no longer support Ethereum's vision of becoming a global settlement layer.

Vitalik's recent call also points out that this transformation is not just a technical reconstruction; he urges the community to completely abandon path dependence at the application layer, upholding the core principles of censorship resistance, open source, privacy, and security (CROPS), and to start from first principles in application design.

Technology can have a roadmap, but the upgrade of thinking does not have a fork timeline; this may be the hardest step in saying goodbye to "incrementalism."