Ethereum 2029 Roadmap Explained: A Complete Overhaul—But This Ship Must Not Stop
TechFlow Selected TechFlow Selected
Ethereum 2029 Roadmap Explained: A Complete Overhaul—But This Ship Must Not Stop
Seven upgrades, a complete overhaul—but the chain must never stop.
Navigating Web3 tides with focused insightsAuthor: James/Snapcrackle
Translated and compiled by TechFlow
TechFlow Introduction: Ethereum researcher Justin Drake has unveiled the “Strawmap”—the first structured Ethereum upgrade roadmap with explicit timelines and performance targets. Vitalik Buterin called it “extremely important” and described its cumulative effect as a “Ship of Theseus”-style reconstruction of Ethereum’s core. This article is currently the clearest long-form explanation of the Strawmap—covering how it works, its five goals, and its seven planned upgrades—accessible even to non-technical readers.
Full text below:
Ethereum has just released its most detailed upgrade plan ever: seven upgrades, five objectives, one large-scale rebuild.
If you’re wondering who this guide is written for—the “non-expert” it assumes—you’re looking at him.
Ethereum researcher Justin Drake published what he calls the “Strawmap”: a schedule of seven major proposed upgrades extending through 2029. Ethereum co-founder Vitalik Buterin called it “extremely important” and described its cumulative effect as a “Ship of Theseus”-style reconstruction of Ethereum’s core.
This metaphor is worth unpacking.
The Ship of Theseus is an ancient Greek thought experiment: if you replace each wooden plank of a ship one by one, until every original plank has been replaced, is it still the same ship?
That’s precisely what the Strawmap proposes for Ethereum.
By 2029, every major component of the system will have been replaced—but there is no scheduled “big-bang rewrite” downtime. The goal is backward-compatible upgrades that keep the chain running while swapping planks—though node operators will still need to update their software, and edge cases may shift. It’s a full rebuild disguised as incremental upgrades. Strictly speaking, while both consensus-layer and execution-layer logic are being rebuilt, state (user balances, contract storage, and historical records) remains preserved across all forks. “The ship is rebuilt while carrying cargo.” All aboard!
“Why not just start from scratch?” Because you can’t reboot—and doing so would destroy what gives Ethereum value: applications already deployed, funds already in motion, trust already established. You must replace the planks while the ship sails.
“Strawmap” merges “strawman” (a deliberately imperfect draft proposal meant to invite critique) and “roadmap.” So this isn’t a promise—it’s the starting point for debate. But it *is* the first time Ethereum builders have assembled a structured, time-bound, performance-targeted upgrade path.
This work involves the world’s top cryptographers and computer scientists—and it’s all open source. No licensing fees. No vendor contracts. No enterprise sales teams. Any company, any developer, any country can build on it. JPMorgan Chase benefits from these upgrades exactly the same way a three-person startup in São Paulo does.
Imagine a coalition of the world’s top engineers rebuilding the financial plumbing of the internet from the ground up—and you get direct access.
How Ethereum Works (60-Second Version)
Before discussing where it’s going, let’s clarify what it is today.
Ethereum is essentially a shared global computer. Rather than a single company operating one server, thousands of independent operators worldwide run identical copies of the same software.
These operators independently verify transactions. Some—called validators—also stake ETH as collateral. If a validator attempts to cheat, their staked ETH is slashed. Every 12 seconds, validators reach consensus on which transactions occurred and in what order. This 12-second window is called a “slot.” Every 32 slots (roughly 6.4 minutes) form an “epoch.”
True finality—the moment a transaction becomes irreversible—takes about 13–15 minutes, depending on where your transaction falls within the epoch cycle.
Ethereum processes roughly 15–30 transactions per second (TPS), depending on transaction complexity. By comparison, the Visa network handles over 65,000 TPS. That gap is why most Ethereum applications today run on “Layer 2” networks—independent systems that batch large numbers of transactions and submit only cryptographic summaries back to Ethereum’s main layer for security guarantees.
The system enabling all those operators to reach consensus is called the “consensus mechanism.” Ethereum’s current consensus mechanism works well and has been battle-tested—but it was designed for an earlier era, limiting the network’s upper capability ceiling.
The Strawmap aims to solve all these issues—one upgrade at a time.
The Five Core Goals of the Strawmap
The roadmap organizes everything around five goals. Ethereum is already live, moving billions of dollars daily—but real constraints limit what can be built on it. These five goals aim to remove those constraints.
1. Fast L1: Sub-Second Finality
Today, sending a transaction on Ethereum takes ~13–15 minutes before it’s truly confirmed—i.e., irreversible, complete, and non-revertible.
Solution: Replace the engine that enables all operators to reach consensus. Goal: Achieve finality within a single slot via one round of voting. Minimmit is a leading candidate under research—a protocol designed for ultra-fast consensus, though its exact design remains under refinement. What matters is the target: finality within a single slot. Slot time itself will also shrink: proposed progression is 12 → 8 → 6 → 4 → 3 → 2 seconds.
Finality isn’t just about speed—it’s about certainty. Think of wire transfers: the time between “sent” and “settled” is the window where things can still go wrong. For million-dollar payments, bond settlements, or real estate transfers on-chain, that 13-minute uncertainty is a serious problem. Compressing it to sub-second times fundamentally changes what this network can do—not just for crypto-native apps, but for *any* value-transfer use case.
2. Gigagas L1: 300x Faster
Ethereum’s mainnet processes ~15–30 TPS—that’s the bottleneck.
Solution: Strawmap targets 1 gigagas of execution capacity per second—translating to ~10,000 TPS for typical transactions (exact figures depend on operation complexity, as different operations consume varying amounts of gas). Core technology: zero-knowledge proofs (ZK proofs).
The simplest analogy: right now, every operator on the network must recompute every operation to verify correctness—like asking every employee in a company to independently redo every colleague’s math problem. Secure? Yes. Extremely inefficient? Also yes. ZK proofs let you verify a compact mathematical receipt proving the computation is correct—same level of trust, minimal work required.
Software generating these proofs is still too slow. Current versions take minutes to hours for complex work. Shrinking that to seconds—roughly a 1,000x speedup—is an active research challenge, not just an engineering one. Teams like RISC Zero and Succinct are advancing rapidly—but this remains frontier work.
10,000 TPS on mainnet plus fast finality means simpler architecture, fewer moving parts, and fewer points of failure.
3. Teragas L2: 10 Million TPS Across Fast Lanes
For truly massive throughput (and customization needs), you’ll still need Layer 2 networks. Today, L2s hit ceilings constrained by how much data Ethereum’s mainnet can process for them.
Solution: A technique called “data availability sampling” (DAS). Instead of every operator downloading all data to verify its existence, each checks random samples and uses mathematics to verify the full dataset is intact. Like checking whether a 500-page book is truly on the shelf—randomly flipping to 20 different pages; if they’re all present, you can statistically conclude the rest is too.
PeerDAS launched with the Fusaka upgrade, laying the foundation for everything in the Strawmap. Scaling to the full target means iterative expansion: each fork increases data capacity, with network stability stress-testing at every step.
10 million TPS across the L2 ecosystem opens doors impossible on any blockchain today. Think global supply chains—every product and shipment represented as digital tokens; or millions of connected devices generating verifiable data; or micro-payment systems processing fractions of a cent. These workloads overwhelm any existing network—but fit comfortably—even generously—at 10 million TPS.
4. Post-Quantum L1: Preparing for Quantum Computers
Ethereum’s security relies on mathematical problems extremely hard for today’s computers to break. This applies across the entire system—including signatures users generate when sending transactions, and signatures validators use to reach consensus. Once sufficiently powerful, quantum computers could break both, potentially allowing someone to forge transactions or steal funds.
Solution: Migrate to new cryptographic methods (hash-based schemes) believed resistant to quantum attacks. This is a later-stage upgrade because it touches nearly every part of the system—and the new methods require vastly more data (kilobytes instead of bytes), altering the economic calculus for block size, bandwidth, and storage across the entire network.
The quantum threat to today’s cryptography may still be years—or even decades—away. But if you’re building infrastructure intended to last—infrastructure that may hold trillions of dollars in value—“we’ll deal with it later” isn’t a real answer.
5. Private L1: Confidential Transactions
Everything on Ethereum is public by default. Unless you use privacy-focused applications like Railgun, or privacy-first L2s like zkSync or Aztec, every transaction, amount, and counterparty is visible to anyone.
Solution: Build confidential transfers directly into Ethereum’s core. Technical goal: Enable the network to verify transaction validity (sender has sufficient funds, math is correct) *without* exposing actual details. You can prove “this is a valid $50,000 payment” without revealing who paid whom—or why.
Workarounds exist today. In February 2026, EY and StarkWare announced Nightfall on Starknet, bringing privacy-preserving transactions to L2. But workarounds add complexity and cost. Building privacy into the base layer eliminates middleware entirely.
This also converges with post-quantum work: whatever privacy scheme is built must *also* be quantum-resistant. Two problems that must be solved together. Solve this, and a major barrier to mass adoption disappears.
The Seven Forks (Upgrades)
The Strawmap proposes seven upgrades—roughly every six months—starting with Glamsterdam. Each upgrade is deliberately scoped to change only one or two major things, because if something goes wrong, you need to know exactly what caused it.
The first upgrade after Fusaka (already live, laying groundwork via PeerDAS and data tuning) is Glamsterdam, restructuring how transaction blocks are assembled.
Hegotá follows with further structural improvements. Remaining forks (I through M) extend through 2029, progressively rolling out faster consensus, ZK proofs, expanded data availability, quantum-resistant cryptography, and privacy features.
Why Until 2029?
Because some of these problems genuinely remain unsolved.
Replacing the consensus mechanism is the hardest. Imagine replacing airplane engines mid-flight—with thousands of co-pilots required to agree on every change. Each modification demands months of testing and formal verification. And compressing epoch time below 4 seconds eventually hits physical limits: light-speed round-trip signals around Earth take ~200ms—so at some point, you’re racing against physics.
Making ZK provers fast enough is another frontier challenge. The gap between current speeds (minutes) and target speeds (seconds) is ~1,000x—requiring both mathematical breakthroughs and specialized hardware.
Scaling data availability is less difficult—but more operationally tractable. The math checks out; the challenge lies in executing carefully on a live network holding hundreds of billions in value.
Post-quantum migration is an operational nightmare: new signatures are far larger, reshaping economics across the board.
Native privacy adds political sensitivity atop technical difficulty. Regulators worry privacy tools enable money laundering. Engineers must build something *private enough to be useful*, yet *transparent enough to satisfy compliance*—and *quantum-resistant* too.
These cannot proceed simultaneously. Some upgrades depend on others: you can’t scale to 10,000 TPS without mature ZK proofs; you can’t scale L2s without data availability work. These dependency chains define the timeline.
Given what’s being attempted, 3.5 years is actually quite aggressive.
2029?
First, there’s a variable. The Strawmap explicitly states: “This current draft assumes human-led development. AI-driven development and formal verification could dramatically compress the timeline.”
In February 2026, a developer named YQ bet Vitalik that a single person could program the entire Ethereum system for the 2030+ roadmap using AI agents. Within weeks, he released ETH2030: an experimental Go execution client claiming ~713,000 lines of code, implementing all 65 items in the Strawmap—and labeled as running on testnet and mainnet.
Is it production-ready? No. As Vitalik noted, it almost certainly contains critical bugs everywhere—and in some cases, stub implementations where the AI didn’t even attempt full versions. But Vitalik’s response deserves close reading: “Six months ago, even something like this was far beyond the realm of possibility. What matters is the direction of the trend… People should remain open to the *possibility*—not certainty!—that the Ethereum roadmap will be completed far faster than expected, and with security standards far higher than expected.”
Vitalik’s core insight is that using AI correctly isn’t just about going faster—it’s about allocating half the gains to speed and half to security: more testing, more mathematical verification, more independent implementations of the same thing.
The Lean Ethereum project is conducting machine-checked formal verification of parts of the cryptography and proof stack. Bug-free code—long dismissed as idealistic fantasy—may soon become baseline expectation.
The Strawmap is a coordination document—not a commitment. Its goals are ambitious, its timeline aspirational, and its execution depends on hundreds of independent contributors.
But the real question isn’t whether each goal hits its deadline. It’s whether you want to build *on* this trajectory—or compete *against* it.
And all this—research, breakthroughs, cryptographic migrations—is happening openly, freely, and accessibly to anyone… That’s the part of this story that deserves far more attention than it’s received.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@Snapcrackle
