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 Achieves 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, L1 gigagas throughput, L2 teragas scaling, post-quantum L1 security, and native L1 private transfers. The ultimate quantitative targets are 10,000 transactions per second on L1 and 10 million on L2.

The plan envisions seven forks, with upgrades every six months, covering consensus, data, and execution layers. Vitalik Buterin expressed support, and in the past two weeks, he has also published detailed technical articles dissecting core aspects of the 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 shift.

1. Short-term: Glamsterdam Upgrade

The upcoming Glamsterdam upgrade will introduce “Block-Level Access Lists (BALs)” to support parallel verification, breaking the previous sequential processing bottleneck, and will 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 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 boosting 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 fourfold. This change will significantly improve data efficiency:

• Data bandwidth: approximately 4x reduction in costs, a leap for light clients like Helios.
• Proof speed: about 3x faster with BLAKE3; potentially 100x faster with Poseidon variants.
• Storage 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 migration. Currently, ZK provers are mostly RISC-V based; if EVM could run directly on RISC-V, eliminating translation layers, the system’s provability would greatly improve. The deployment plan involves three steps:

1. First, let 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 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 a “Lean consensus” approach, introducing hash-based signatures combined with STARKs for aggregation and compression to resist quantum attacks. He adds that before full “Lean consensus” implementation, a “lite” version of the chain 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 adopts a conservative 1D DAS (e.g., PeerDAS) prioritizing network robustness over maximum scalability.
• STARK proofs are large; developers must use recursive proofs to handle “proofs larger than data.” Overall, Vitalik believes that with phased technical goals and engineering efforts, this path is feasible, though demanding.

3. External Owned Accounts (EOA): ECDSA Signatures

ECDSA signatures are highly vulnerable to quantum attacks. Vitalik favors integrating native account abstraction (AA), allowing users to switch to quantum-resistant signature algorithms without abandoning existing wallet addresses.

4. Application Layer: KZG or Groth16-based ZK Proofs

At the application level, quantum-resistant STARK proofs are costly—about 20x the current 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 (originally hundreds of MB) can be compressed into a tiny on-chain STARK proof, saving space and cost, and enabling immediate verification even in mempool, ensuring low-cost, high-efficiency operations amid 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 with a laptop running gpt-oss:20b, generating backend blog code in an hour; with a more powerful 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 mismatches remains, but it can be accelerated fivefold.

He also 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 and Real-World Challenges

However, the more complex these technical promises, the more uncertain their timely fulfillment. Historically, Ethereum’s delivery has often lagged expectations: The Merge was delayed from late 2020 to September 2022; EIP-4844 (Proto-Danksharding) took years to implement. These delays are usually due to security audits, multi-client coordination, and decentralized governance.

This time, Ethereum has less time to spare. Competition is intensifying, quantum threats are real, and AI-driven productivity revolution is pressing Ethereum to abandon gradualism altogether. Standing at a pivotal moment, the gentle, incremental approach may no longer suffice for Ethereum’s vision of becoming the global settlement layer.

Vitalik’s recent calls also highlight that this transformation is not just technical but involves community-wide shifts. 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 scheduled fork—may be the hardest step in moving beyond gradualism.