Author: Chloe, ChainCatcher

In the past two weeks, Ethereum founder Vitalik Buterin has released a series of technical long articles on X, covering core topics such as scaling strategies, quantum attack resistance, account abstraction, execution layer reconstruction, and AI acceleration of development, referred to by outsiders as the "2026 Ethereum Major Overhaul Blueprint." Behind this series of publications is the framework of the Strawmap route outline, a document that plans to advance Ethereum L1 throughput to the 10,000 TPS level by 2029.

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

Strawmap Route Outline: Achieving 10,000 TPS by 2029

Ethereum Foundation researcher Justin Drake released a route outline named Strawmap, aimed at revealing the vision and future upgrade timeline for Ethereum L1. The blueprint sets five major "North Star" goals: high-speed L1 performance, L1 gigagas throughput, L2 teragas scaling, post-quantum L1 security, and native L1 privacy transfers. The final quantitative goal is to process 10,000 transactions per second in L1 and reach 10 million transactions per second in L2.

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 his support and has intensely published technical long 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'sargument shows: Unlike the strategy in past years of emphasizing L2 rollups and lighter L1, the current vision aims to significantly enhance L1 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 previous sequential processing efficiency bottleneck, and simultaneously promoting the separation of native proposers and builders (Enshrined Proposer-Builder Separation, ePBS), optimizing node utilization for the 12-second time slot.

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

The long-term scaling is supported by two 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 ZK-EVM clients, and starting in 2027, the proportion will be expanded and security enhanced, with the ultimate goal of achieving a "3-of-5 mandatory multiparty proof mechanism," where a block must be verified by at least three of five proof systems to be effective.

On the Blob developmental path, PeerDAS (Data Availability Sampling) will continue to iterate, aiming to enhance data processing capacity to approximately 8 MB/s. The core of this technology is to allow nodes to only need to download a small amount of data fragments to complete verification, greatly increasing throughput while effectively reducing the hardware thresholds 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 previous costly and permanently stored calldata model. This transformation 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 Tree, Replacing EVM

Vitalik points 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 "16 hex Keccak MPT state tree" to the "binary state tree," the branch length will be effectively reduced by a factor of four. This transformation will bring significant improvements in data efficiency:

• Data Bandwidth: Cost reduction by approximately four times, which represents a qualitative leap for light clients like Helios.

• Proof Speed: If using BLAKE3 operations, it speeds up by about three times; if using Poseidon variants, potential speedup could reach 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.

An even more ambitiousproposal is the VM (Virtual Machine) migration. Currently, ZK provers are mostly written in RISC-V. If the EVM can run directly in RISC-V, it will eliminate the translation overhead between the two virtual machines, significantly improving the provability of the entire system. The current deployment path is planned in three steps:

1. First, let the new VM inherit the existing precompiled contracts

2. Then allow users to deploy new VM contracts

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

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

Quantum Threat Roadmap: Addressing Ethereum's Four Major Technical Vulnerabilities

Regarding the critical issue of post-quantum L1 security, Vitalik clearly mentioned in his technical long article that there are currently four quantum vulnerabilities in Ethereum:

1. Consensus Layer: BLS Signatures

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

2. Data Availability: KZG Commitments and Proofs

On the data availability front, Vitalik proposed replacing the current "KZG commitments" with STARKs that have "quantum-resistant" properties. However, this faces two significant trade-offs:

First, STARKs lack the linear characteristics of KZG, making it difficult to support efficient 2D data sampling. Therefore, Ethereum chose a more conservative 1D DAS path (such as PeerDAS) to prioritize network robustness over extreme scaling.

Secondly, due to the larger size of STARK proofs, developers need to solve the engineering challenge of "proofs 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 quite substantial.

3. Externally Owned Accounts (EOA): ECDSA Signatures

Regarding the protection of externally owned accounts (EOA), due to the current ECDSA signatures being extremely weak against quantum computers, Vitalik leans towards implementing "native account abstraction" to convert all accounts into contracts, allowing users to flexibly switch quantum-resistant signature algorithms without discarding their existing wallet addresses.

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

Finally, on the application layer, the main challenge is that quantum STARK proofs have extremely high Gas costs, approximately 20 times that of current SNARKs, making it too expensive for privacy protocols and L2. Vitalik proposed introducing the "Validation Frame" through EIP-8141 to allow a large number of complex signatures and proofs to be aggregated off-chain.

By utilizing recursive proof technology, verification data originally reaching hundreds of MB can ultimately be compressed into a very small STARK proof on-chain, saving not only block space but also significantly reducing usage costs. It could even allow instant verification during the Mempool stage, enabling users to continue operating various decentralized applications in a cost-effective and efficient manner in the age of quantum threats.

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

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

Even Vitalik himself has tested this, using a laptop running the gpt-oss:20b model to complete the backend code for a blog in just one hour; if using a more powerful kimi-2.5 model, he expects he could accomplish it "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 allocating "half of the benefits of AI to speed and half to security," utilizing AI to generate large-scale test cases, performing formal verification on core modules, and generating multiple independent implementations of the same logic for cross-comparison. Vitalik's judgment is: in the foreseeable future, you cannot exchange a prompt for high-security program code, and the process of grappling with bugs and inconsistencies in implementations still exists, but this process can be enhanced fivefold.

Finally, he suggested the possibility that the Ethereum roadmap could be completed faster than expected by the outside world, with security standards higher than anticipated. "Bug-free program code, which has long been considered an idealistic fantasy, may now become possible." This statement, if placed in the context of Ethereum development five years ago, would have been almost unimaginable.

Slow Delivery Pace and Real-World Challenges

However, by publicly revealing such intricate technical details to the market, the Ethereum roadmap can never avoid the possibility of these commitments being delivered on time.

Historically, Ethereum's delivery pace has always been slower than expected. The Merge was postponed from the early 2020 expectation of "by the end of the year" all the way to September 2022; the rollout 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.

However, this time, Ethereum doesn't have much time left to be sluggish. The continuous pressure from competitors, the real challenges posed by quantum threats, coupled with the productivity revolution triggered by AI, is forcing Ethereum to completely bid farewell to "incrementalism"; standing at a historical turning point where "no progress means regression," the past gentle and incremental iterations may no longer be sufficient to support Ethereum's vision of becoming the global settlement layer.

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

Technology may have a roadmap, but the upgrade of thinking has no fork timeline; this may be the hardest step in bidding farewell to "incrementalism."

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。