Author: Chloe, ChainCatcher
Over the past two weeks, Ethereum founder Vitalik Buterin has published a series of in-depth technical posts on X, covering core topics such as scaling roadmaps, quantum attack resistance, account abstraction, execution layer rearchitecture, and AI-accelerated development, widely referred to as the "2026 Ethereum Major Upgrade Blueprint." Behind this series of posts is the Ethereum Foundation’s concurrent release of the Strawmap roadmap framework—a document outlining a plan to push Ethereum L1 throughput to 10,000 TPS by 2029.
However, the larger the ambition of the blueprint, the more skepticism arises regarding its ability to deliver, especially considering that, historically, Ethereum’s delivery timeline has consistently lagged behind expectations. Is Ethereum truly ready to bid farewell to “incrementalism” and embrace radical restructuring this time?
Strawmap roadmap: Ethereum achieving 10,000 TPS by 2029
On February 25, Ethereum Foundation researcher Justin Drake released a roadmap titled Strawmap, outlining the vision and future upgrade timeline for Ethereum L1. The blueprint establishes five key “north star” goals: ultra-fast L1 performance, L1 gigagas throughput, L2 teragas scaling, post-quantum L1 security, and native L1 private transactions. The ultimate quantitative targets are 10,000 transactions per second on L1 and 10 million transactions per second on L2.
This plan is expected to progress through seven forks, with each upgrade cycle lasting six months, encompassing changes to the consensus, data, and execution layers. Ethereum founder Vitalik Buterin has expressed support for this plan and has recently published a series of in-depth technical posts on X over the past two weeks, breaking down the core dimensions of the roadmap.
Strategic focus: Prioritizing Ethereum L1 scaling and execution layer reconstruction
Vitalik'sargument shows: Unlike the strategy of the past few years, which prioritized L2 Rollups and minimized L1, the current vision is to significantly enhance L1's own scalability in the short term while maintaining the long-term shift.
1. Short-term initiative: Glamsterdam upgrade
In the short-term roadmap, the upcoming Glamsterdam upgrade will introduce Block-Level Access Lists (BALs) to enable parallel validation, overcoming the efficiency bottlenecks of sequential processing, while advancing Enshrined Proposer-Builder Separation (ePBS) to optimize node utilization of 12-second slots.
2. Long-term process: ZK-EVM and Blob evolution
Long-term scaling is supported by two pillars: ZK-EVM and Blobs. On the ZK-EVM path, a small number of validators are expected to adopt ZK-EVM clients by the end of 2026, with gradual expansion and enhanced security starting in 2027, ultimately aiming to achieve a “3-of-5 mandatory multi-proof mechanism,” where a block must be validated by at least three out of five proof systems to be confirmed.
On the Blob development path, PeerDAS (Data Availability Sampling) will continue to evolve, aiming to increase data processing capacity to approximately 8 MB/s. The core of this technology enables nodes to verify data by downloading only small fragments, significantly boosting throughput while effectively lowering hardware requirements for nodes. On the other hand, to meet the demands of future large-scale adoption, the Ethereum mainnet will transition to storing block data directly in Blob space, replacing the previous costly and permanently stored calldata model. This shift is primarily intended to optimize the data承载 structure and reshape Ethereum’s scaling path at the data layer.
3. Execution Layer Restructuring: Switch to a binary state tree, replacing EVM
Vitalik pointed out that 80% of Ethereum’s current proof efficiency bottleneck stems from an outdated architecture. According to EIP-7864, switching from the current “hexadecimal Keccak MPT state tree” to a “binary state tree” is expected to reduce branch lengths by a factor of four. This change will bring significant improvements in data efficiency:
Data bandwidth: Costs reduced by approximately 4x, a monumental leap for lightweight clients like Helios.
Proof speed: Approximately 3x faster with BLAKE3; up to 100x faster with Poseidon variants.
Gas optimization: The design of the storage slot "page" (slots 64–256) enables DApps to save over 10,000 Gas per transaction when reading or writing adjacent data.
More ambitiousproposal is VM (virtual machine) migration, as current ZK provers are mostly written in RISC-V; if EVM could run directly on RISC-V, eliminating translation overhead between the two virtual machine layers, the system's provability would be significantly enhanced. The current deployment roadmap is planned in three steps:
1. First, have the new VM take over the existing precompiled contracts.
2. Re-enable users to deploy new VM contracts
3. Eventually rewrite the EVM itself as a smart contract running on the new VM.
This ensures backward compatibility, with the final conversion cost requiring only a gas fee recalibration.
Quantum Threat Mitigation Roadmap: Addressing the Four Major Technical Vulnerabilities of Ethereum
Regarding the critical issue of post-quantum L1 security, Vitalik explicitly mentioned in a technical deep-divethat Ethereum currently has four quantum vulnerabilities, as follows:
1. Consensus layer: BLS signatures
The replacement path for the consensus layer is beginning to take shape: Vitalik has proposed a "Lean Consensus" solution, introducing hash-based signature variants combined with STARKs for aggregation and compression to achieve quantum resistance. However, Vitalik added that before full "Lean Consensus" is implemented, a "Lean Usable Chain" version will launch first, requiring only 256 to 1,024 signatures per slot and operating without STARK aggregation for now, significantly lowering the engineering barrier.
2. Data Availability: KZG Commitments and Proofs
In terms of data availability, Vitalik proposes replacing the existing "KZG commitments" with "quantum-resistant STARKs," but this presents two major trade-offs:
First, STARKs lack the linearity of KZG, making it difficult to support efficient 2D data sampling; thus, Ethereum has opted for a more conservative 1D DAS approach (such as PeerDAS), prioritizing network robustness over maximal scalability.
Second, because STARK proofs are large, developers must address the engineering challenge of “proofs larger than data” through complex techniques such as recursive proofs. In summary, Vitalik believes that this quantum-resistant path remains practically feasible through simplified technical goals and phased optimization, but it requires a substantial amount of engineering effort.
3. Externally Owned Account (EOA): ECDSA signature
For securing externally owned accounts (EOAs), since the current ECDSA signatures are highly vulnerable to quantum computers, Vitalik favors transitioning all accounts to smart contracts via "native account abstraction," enabling users to flexibly switch to quantum-resistant signature algorithms without abandoning their existing wallet addresses.
4. Application Layer: ZK proofs relying on KZG or Groth16
Finally, at the application layer, the main challenge is the extremely high Gas cost of quantum-resistant STARK proofs, which is about 20 times that of current SNARKs, making them prohibitively expensive for privacy protocols and L2s. Vitalik proposes introducing a "Validation Frame" via EIP-8141 to enable the off-chain aggregation of large numbers of complex signatures and proofs.
Through recursive proof technology, verification data that originally reached hundreds of MB can be compressed into a tiny STARK proof on-chain, saving block space and significantly reducing usage costs—even enabling instant verification at the mempool stage, allowing users to operate various decentralized applications affordably and efficiently in the era of quantum threats.
AI as an Accelerator: Completing Ethereum's 2030 Roadmap in Weeks
Beyond technical architecture upgrades, Vitalik’s recent tweet emphasized that AI is accelerating Ethereum’s development. He retweeted an experiment in which a developer built a prototype of the 2030 Ethereum roadmap in two weeks using “vibe-coding,” and commented: “Six months ago, this wasn’t even within the realm of possibility—now it’s becoming a trend.”
Even Vitalik himself tested it firsthand, using a gpt-oss:20b model running on his laptop to complete the blog’s backend code in just one hour; with a more powerful model like kimi-2.5, he expects he could “get it done in one go.” It’s clear that AI’s impact on efficiency is no longer linear—it’s accelerating the delivery pace of Ethereum’s roadmap.
To this end, he advocates allocating AI’s benefits “half to speed, half to security,” using AI to generate large-scale test cases, applying formal verification to core modules, and creating multiple independent implementations of the same logic for cross-validation. Vitalik’s assessment is that, in the foreseeable future, you cannot swap a single prompt for a highly secure program—struggling with bugs and implementation inconsistencies remains inevitable—but this process can be accelerated fivefold.
Finally, he proposed the possibility that the Ethereum roadmap could be completed faster than expected, with security standards higher than anticipated. “Bug-free code, long regarded as an idealistic fantasy, may now become possible.” This statement would have been nearly unthinkable in the context of Ethereum development five years ago.
Slow delivery pace and real-world challenges
However, disclosing such extensive technical details to the market means the Ethereum roadmap can never escape the possibility of these commitments being fulfilled on time.
Historically, Ethereum’s delivery timeline has consistently been slower than expected. The Merge was delayed from an initial target of “end of year” in early 2020 to September 2022; the implementation of EIP-4844 (Proto-Danksharding) also took several years. Such delays are typically due to factors like security audits, multi-client coordination, and decentralized governance.
But this time, Ethereum has little time left for gradualism. Intensifying competition, the tangible threat of quantum computing, and the productivity revolution driven by AI are forcing Ethereum to fully abandon its incremental approach. Standing at a historic crossroads where standing still means falling behind, the old model of gentle, step-by-step upgrades may no longer be sufficient to realize its vision of becoming the world’s settlement layer.
And Vitalikrecently called foremphasized that this transformation is not merely a technical overhaul—he urged the community to completely abandon path dependency at the application layer and uphold the core principles of censorship resistance, openness, privacy, and security (CROPS), rebuilding application design from first principles.
Technology can have a roadmap, but the upgrade of thinking has no forked timeline—this may be the hardest step in letting go of "incrementalism."