Ethereum overhaul 2026 blueprint, this time abandoning "gradualism"

Written by: Chloe, ChainCatcher

Over the past two weeks, Ethereum founder Vitalik Buterin has published several in-depth technical articles on X, covering scalability routes, quantum resistance, account abstraction, execution layer reconstruction, and AI-accelerated development—collectively dubbed the “Ethereum Major Overhaul Blueprint 2026.” Behind this series of publications is the Ethereum Foundation’s release of the Strawmap roadmap sketch, a plan to increase Ethereum’s L1 throughput to 10,000 TPS by 2029.

However, the greater the ambition of the blueprint, the more skepticism arises about its deliverability—after all, historically, Ethereum’s development pace has often been slower than expected. Is Ethereum truly ready to move beyond gradualism and embrace radical restructuring?

Strawmap Roadmap: Achieving 10,000 TPS on Ethereum by 2029

On February 25, Ethereum Foundation researcher Justin Drake released a roadmap sketch called Strawmap, outlining Ethereum L1’s vision and future upgrade timeline. The blueprint 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 targets are 10,000 transactions per second on L1 and 10 million on L2.

This plan aims to be advanced through seven forks, with upgrades every six months, covering consensus, data, and execution layers. Vitalik Buterin expressed support for this approach, publishing detailed technical analyses on X over the past two weeks to dissect the core dimensions of the roadmap.

Strategic Focus: Scaling Ethereum L1 and Rebuilding the Execution Layer

Vitalik’s arguments show a shift: unlike the past few years’ focus on L2 rollups and lightweight L1s, the current vision is to significantly boost L1 scalability in the short term while maintaining a long-term transition.

1. Short-term: Glamsterdam Upgrade

The upcoming Glamsterdam upgrade will introduce “Block-Level Access Lists (BALs)” to support parallel validation, breaking the previous sequential processing bottleneck, and will also advance the separation of proposers and builders (Enshrined Proposer-Builder Separation, ePBS), optimizing node utilization during 12-second slots.

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

Long-term scaling relies on two pillars: ZK-EVM and Blob. For ZK-EVM, by late 2026, a small number of validators are expected to adopt ZK-EVM clients first, expanding in 2027 with enhanced security. The goal is to implement a “3-of-5 multi-proof mechanism,” requiring a block to be validated by at least three out of five proof systems.

Regarding Blob development, PeerDAS (Data Availability Sampling) will continue to iterate, aiming to increase data processing capacity to about 8 MB/sec. The core idea is that nodes can verify data by downloading only small data fragments, greatly improving throughput and lowering hardware requirements. Additionally, to accommodate future large-scale adoption, Ethereum mainnet will shift to storing block data directly in Blob space, replacing the costly and permanently stored calldata model. This change aims to optimize data structure and reshape Ethereum’s scalability path from the data layer.

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

Vitalik notes that 80% of Ethereum’s proof efficiency bottlenecks stem from outdated architecture. According to EIP-7864, switching from the current “hexadecimal Keccak MPT state tree” to a “binary state tree” could reduce branch length by fourfold. This transformation will significantly improve data efficiency:

• Data bandwidth: costs reduced by about 4x, a major leap for light clients like Helios.
• Proof speed: using BLAKE3 hashing can speed up by approximately 3x; Poseidon variants could potentially accelerate by 100x.
• Access optimization: designing storage slots (“pages” of 64–256 slots) allows DApps to save over 10,000 Gas per transaction when reading/writing adjacent data.

A more ambitious proposal involves migrating the VM (Virtual Machine). Currently, ZK provers are mostly written in RISC-V; if EVM can run directly on RISC-V, it would eliminate translation overhead between two virtual machines, greatly enhancing system provability. The deployment plan involves three steps:

1. First, have the new VM handle existing precompiled contracts.
2. Then, enable users to deploy new VM contracts.
3. Finally, rewrite EVM itself as a smart contract running on the new VM.

This approach ensures backward compatibility, with the final transition only requiring re-calibration of Gas costs.

Quantum Resistance Roadmap: Addressing Ethereum’s Four Major Technical Weaknesses

Vitalik explicitly states that Ethereum currently has four quantum vulnerabilities:

1. Consensus Layer: BLS Signatures

The path to replacing consensus layer signatures is emerging: Vitalik proposes a “Lean consensus” approach, introducing hash-based signature variants combined with STARKs for aggregation and compression to resist quantum attacks. He adds that before full “Lean consensus” implementation, a “lean usable chain” version will go live, processing only 256 to 1,024 signatures per slot, without STARK aggregation initially, greatly lowering engineering barriers.

2. Data Availability: KZG Commitments and Proofs

For data availability, Vitalik suggests replacing current “KZG commitments” with quantum-resistant STARKs, but this involves trade-offs:

• STARKs lack the linearity of KZG, making efficient 2D data sampling difficult. Ethereum thus opts for a conservative 1D DAS (e.g., PeerDAS), prioritizing network robustness over maximum scalability.
• STARK proofs are large; developers must use recursive proofs to address the “proofs larger than data” challenge. Overall, Vitalik believes that with phased technical simplification and optimization, this quantum resistance path remains feasible, though it requires substantial engineering effort.

3. External Owned Accounts (EOA): ECDSA Signatures

ECDSA signatures are highly vulnerable to quantum attacks. Vitalik favors integrating all accounts into smart contracts via “native account abstraction,” allowing users to switch to quantum-resistant signature algorithms without abandoning existing wallets.

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

At the application level, the main challenge is that quantum-resistant STARK proofs are currently about 20 times more gas-expensive than SNARKs, making them too costly for privacy protocols and L2s. Vitalik proposes introducing a “Validation Frame” via EIP-8141, enabling off-chain aggregation of complex signatures and proofs.

Using recursive proofs, large verification data (hundreds of MB) can be compressed into a tiny on-chain STARK proof, saving block space and reducing costs. This also allows immediate verification during the mempool stage, ensuring users can operate decentralized applications efficiently and securely in a quantum-threat environment.

AI as an Accelerator: Completing Ethereum 2030 Roadmap in Weeks

Beyond technical upgrades, Vitalik emphasizes that AI is accelerating Ethereum development. He shared an experiment where developers built a prototype of the 2030 Ethereum roadmap in two weeks using vibe-coding, commenting: “Six months ago, this was even considered impossible; now it’s becoming a trend.”

He personally tested running GPT-OSS:20B on a laptop, generating backend blog code in an hour; with more powerful models like Kimi-2.5, he expects to “do it all at once.” AI’s efficiency gains are no longer linear; it is transforming the delivery speed of Ethereum’s roadmap.

He advocates sharing AI-driven benefits equally between speed and security—using AI to generate large-scale test cases, perform formal verification of core modules, and produce multiple independent implementations for cross-validation. His view: in the foreseeable future, you can’t replace high-security code with a single prompt, and the process of fighting bugs and inconsistencies will persist, but it can be accelerated fivefold.

Finally, he suggests that Ethereum’s roadmap could be completed faster than expected, with higher safety standards. “Bug-free code, long considered an idealistic fantasy, may now become possible.” If this statement had been made five years ago, it would have been almost unthinkable in the Ethereum development context.

Slow Delivery and Real-World Challenges

However, revealing such complex technical content publicly, Ethereum’s roadmap always faces the challenge of whether these promises will be fulfilled on time.

Historically, Ethereum’s delivery has been slower than expected. The Merge, initially scheduled for “end of 2020,” was delayed until September 2022; EIP-4844 (Proto-Danksharding) also took years to implement. These delays are often due to security audits, multi-client coordination, and decentralized governance.

But this time, Ethereum has little time to spare. Competition is intensifying, quantum threats are real, and AI-driven productivity revolutions are pushing Ethereum to abandon gradualism. Standing at a pivotal moment of “no progress means retreat,” the old gentle incremental approach may no longer suffice for Ethereum’s vision of becoming a global settlement layer.

Vitalik’s recent calls also highlight that this transformation is not just technical restructuring; he urges the community to abandon path dependencies at the application layer, safeguarding core principles of censorship resistance, open source, privacy, and security (CROPS), and to rethink application design from first principles.

While technical roadmaps exist, upgrading thinking itself lacks a schedule—perhaps that is the hardest step in moving beyond gradualism.