Ethereum overhaul 2026 blueprint, this time abandoning "gradualism"

Author: Chloe, ChainCatcher

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

However, the greater the ambition of the blueprint, the more doubts arise about its delivery capability—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: Ethereum Achieving 10,000 TPS by 2029

Ethereum researcher Justin Drake released a roadmap sketch called Strawmap on February 25, aiming to reveal Ethereum’s L1 vision and future upgrade timeline. The blueprint sets five “North Star” goals: ultra-fast L1 performance, gigagas throughput, teragas scaling on L2, post-quantum L1 security, and native L1 private transfers. The ultimate targets are 10,000 transactions per second on L1 and 10 million TPS on L2.

The plan envisions seven upgrades over approximately six-month cycles, covering consensus, data, and execution layers. Vitalik Buterin expressed support, and in the past two weeks, he has also published detailed technical articles dissecting the core dimensions of this roadmap.

Strategic Focus: Scaling Ethereum L1 and Restructuring the Execution Layer

Vitalik’s arguments show that, unlike the past few years emphasizing L2 rollups and light L1, the current vision aims to significantly enhance 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 of 12-second slots.

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

Long-term scaling relies on two pillars: ZK-EVM and Blob. On the ZK-EVM path, 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 system,” where a block must be validated by at least three out of five proof systems.

For 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 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 Restructuring: 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 a factor of four. This change will significantly improve data efficiency:

• Data bandwidth: approximately 4x reduction in costs, a leap for light clients like Helios.
• Proof speed: using BLAKE3, speed increases by about 3x; with Poseidon variants, potential 100x acceleration.
• 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.

An even more ambitious proposal involves VM (virtual machine) migration. Currently, ZK provers are often written in RISC-V; if EVM could run directly on RISC-V, it would eliminate translation overhead between two virtual machines, greatly enhancing provability. The deployment plan involves three steps:

1. First, let the new VM handle existing precompiled contracts.
2. Then, allow 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

A replacement path is emerging: Vitalik proposes “Lean consensus,” 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 launch, processing only 256–1,024 signatures per slot, without STARK aggregation, greatly lowering engineering barriers.

2. Data Availability: KZG Commitments and Proofs

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 goals and staged 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 wallet addresses.

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 very costly—about 20 times more than SNARKs—making privacy protocols and L2 applications expensive. Vitalik proposes introducing a “Validation Frame” via EIP-8141, enabling off-chain aggregation of complex signatures and proofs.

Using recursive proofs, verification data that could be hundreds of MBs can be compressed into a tiny STARK proof on-chain, saving block space and reducing costs. This also allows immediate verification during mempool processing, ensuring low-cost, high-efficiency operations even under quantum threats.

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 outside the realm of possibility; now, it’s becoming a trend.”

He personally tested using a laptop running gpt-oss:20b, completing backend code for a blog in an hour; with more powerful models like kimi-2.5, he expects to do it in one go. AI’s efficiency gains are no longer linear—they are transforming Ethereum’s delivery speed.

He advocates sharing AI-driven benefits equally between speed and security—using AI to generate large 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; the process of fighting bugs and implementation inconsistencies remains, 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 had been said five years ago, it would have been almost unthinkable in Ethereum development.

Slow Delivery Pace and Real-World Challenges

However, openly sharing such complex technical content always raises questions about whether Ethereum can deliver on these promises on time.

Historically, Ethereum’s development has been slower than expected. The Merge, initially targeted for late 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.

This time, Ethereum has less room for delay. Competition is intensifying, quantum threats are real, and AI-driven productivity revolutions are underway. These factors are pushing Ethereum to abandon gradualism; at this critical turning point, the 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, a paradigm shift in thinking—without a clear schedule—may be the hardest step in moving beyond gradualism.