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 articles on X, covering core topics such as scaling routes, quantum 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, aimed at revealing 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 articles on X over 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 Rollup 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 promoting the separation of native proposers and builders (Enshrined Proposer-Builder Separation, ePBS) to optimize node utilization of the 12-second time slot.
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 first adopt the ZK-EVM client, with the proportion expanding and security being strengthened from 2027 onwards. 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 is to allow nodes to validate by downloading only a small amount of data fragments, significantly increasing throughput while effectively lowering the hardware threshold for nodes. On the other hand, to meet the demand for large-scale adoption in the future, the Ethereum mainnet will shift to storing block data directly in Blob space, replacing the previously expensive and permanently stored calldata model. This transition 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, speedup of about three times; if using Poseidon variant, potential speedup of up to 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 the 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 provability of the system 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 only requires recalibrating Gas fees.
Quantum Threat Roadmap: Addressing Four Major Technical Vulnerabilities of Ethereum
Regarding the key issue of post-quantum L1 security, Vitalik explicitly mentioned in his technical 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 quantum resistance. 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 the engineering threshold.
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 (such as 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 is still feasible from an engineering perspective, but the required engineering effort is quite substantial.
3. Externally Owned Accounts (EOA): ECDSA Signatures
In terms of 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 verification data originally reaching hundreds of MB 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 has personally tested this, using a laptop to run the gpt-oss:20b model, completing the backend code for a blog in one hour; if using the more powerful kimi-2.5, he expects 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 for sharing the benefits brought by AI "half for speed, half for security," utilizing AI to generate large-scale test cases, perform formal verification on core modules, and generate multiple independent implementations for cross-comparison of the same logic. Vitalik's judgment is that in the foreseeable future, you cannot exchange a prompt for a piece of high-security program code; the process of battling bugs and inconsistencies in implementation still exists, but this process can be improved by five times.
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 anticipated. "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 will always face the possibility of these commitments being fulfilled on time.
Historically, Ethereum's delivery pace has always been slower than expected. The Merge was delayed from the initial "end of the year" expectation in early 2020 to September 2022; the implementation of EIP-4844 (Proto-Danksharding) also took several years. These delays are usually due to factors such as security audits, multi-client coordination, and decentralized governance.
However, this time, Ethereum has little time left for a slow pace. 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 values 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 timetable; this may be the most challenging step in saying goodbye to "incrementalism."
















