Back to Articles
Feb 24, 20265 hours ago

ETH2030: Agentic Coding ETH Client for 2030+ Roadmap

Y
YQ@yq_acc

AI Summary

This article presents a bold and unprecedented experiment: a single developer, using AI-assisted coding, has built a complete reference implementation of Ethereum's entire 2030+ technical roadmap. The project, called ETH2030, compiles 65 planned upgrades across eight complex phases into one functional codebase to answer a critical question—do these ambitious, interdependent pieces actually fit together? The author made a bet with Vitalik Buterin that this was possible, and the resulting software, while not production-ready, passes thousands of official tests and syncs with the live network, offering a unique lens on Ethereum's future.

Two weeks ago I made a bet with Vitalik that one person could agentic-code an Ethereum client targeting the entire 2030+ roadmap. Completed-roadmap Ethereum is a genuinely extraordinary machine - 10,000+ TPS on L1, finality in seconds instead of 15 minutes, solo staking for 1 ETH, stateless nodes on a $7 Raspberry Pi, over a million TPS across L1+L2 - but that future depends on 65 planned upgrades across eight phases actually fitting together. The specs are scattered across dozens of EIPs, many still in draft. Nobody had tried to build all of them into one codebase to see if they compose. So I did.

ETH2030 (eth2030.com, https://github.com/jiayaoqijia/eth2030) is the result - an experimental reference implementation targeting the draft EF Protocol L1 roadmap, a working document from Ethereum's core protocol researchers (Ansgar, Barnabe, Francesco, Justin) mapping eight upgrade phases from Glamsterdam (mid-2026) through the Giga-Gas era (2030+). Built with agentic coding - Claude Code (Opus 4.6), approximately 6 days, $5,750 in API costs, 2.77 billion tokens. It passes all 36,126 official Ethereum state tests, embeds go-ethereum v1.17.0 for mainnet connectivity, and covers everything from Block Access Lists to post-quantum cryptography to a full RISC-V CPU for zero-knowledge proofs.

We want to be upfront: this is not a production client. We are not client developers. What we have is a rough draft - 702,000 lines of Go that compile, pass tests, and sync with the network. The competitive pressure to validate this roadmap is real. Firedancer is already in production on Solana. MegaETH launched targeting 100K TPS. Monad's parallel EVM is on mainnet. Ethereum's roadmap is more ambitious than any of them, but we cannot afford to discover the pieces do not fit together in 2030. We need people who know this deeply to look at the code, find what we got wrong, and help the community understand which parts need rethinking before client teams commit years of production engineering.

What the roadmap actually says

The L1 roadmap organizes Ethereum's roadmap into three layers - consensus, data, and execution - across eight named upgrade phases. The strategic framing uses five pillars: Beast Mode (raw throughput), Lean Mode (node efficiency via Verkle and history expiry), Fort Mode (post-quantum hardening), Decentralization (1 ETH solo staking, distributed building), and Fast Finality (3-slot finality, quick slots). Each phase introduces features across all three layers simultaneously, which is what makes the roadmap both ambitious and architecturally risky. You cannot ship 3SF without BALs, and you cannot ship BALs without gas repricing, and you cannot ship gas repricing without also adjusting the blob schedule and PeerDAS parameters. The coupling is real.

Architecture that holds up

The cleanest decision in ETH2030 is how it integrates with go-ethereum. Rather than forking geth, the project imports go-ethereum v1.17.0 as a Go module and wraps it through a single adapter package at pkg/geth/ - the only location in the entire 50-package codebase that imports go-ethereum. The adapter has four files: processor.go (block processing via gethcore.ApplyMessage), extensions.go (13 custom precompiles via evm.SetPrecompiles()), statedb.go (state creation backed by geth's real trie DB), and config.go (fork name mapping). Everything above this layer - consensus, data availability, rollups, zkVM, post-quantum crypto - is eth2030-native code.

This separation is what makes 100% EF state test conformance possible. The 36,126 test vectors run through go-ethereum's production EVM with eth2030's types mapped through the adapter. The eth2030-geth binary goes further: it embeds a complete go-ethereum node - Pebble database, RLPx P2P, devp2p discovery, snap sync - and injects 13 custom precompiles at Glamsterdam, Hogota, and I+ fork timestamps. The result syncs with Sepolia testnet (verified at ~9,000 headers/sec) and connects to mainnet, while carrying the full roadmap implementation on top.

What building all 65 items actually teaches me

There are things you learn from reading a specification and things you only learn from implementing one. These eight findings emerged from writing, compiling, and testing 94+ EIPs against each other in a single codebase.

Where it falls apart

The most immediate production gap is cryptographic performance. ETH2030 uses pure-Go implementations for BLS12-381, KZG, ZK proofs, Verkle IPA, and post-quantum lattice operations. Production clients use optimized C (supranational/blst), Rust (go-eth-kzg), and mixed C/Go (gnark). The performance difference is typically 10-100x. A validator running eth2030's pure-Go BLS would miss attestation deadlines by an order of magnitude.

The consensus implementation is architecturally complete but operationally untested. 3-slot finality, quick slots, PQ attestations, the 1M attestation scaler, jeanVM aggregation - all have Go implementations with validation functions. None have ever processed a real attestation from a live beacon chain. The gap between "ValidateAttestation() returns nil" and "survives a reorg attack during peak MEV" is measured in years of engineering.

The gigagas target deserves particular scrutiny. GigagasConfig specifies 1B gas/sec with 16 parallel execution slots. Current Ethereum processes ~5M gas/sec total. The BAL parallel execution framework has a conflict detector, scheduler pipeline, and dependency graph. In theory it works. In practice, parallel execution against real-world state - with reentrancy guards, cross-contract callbacks, MEV bundle dependencies, and ERC-20 approval patterns that force serialization - is a fundamentally harder problem than parallel execution against synthetic tests.

What the completed roadmap delivers

If every item on the roadmap ships - all 65, across all eight phases - what does Ethereum become? The numbers from the eth2030 implementation, cross-referenced with EF projections and the specification parameters hardcoded in the reference client, describe a machine almost unrecognizable from what runs today. Every major dimension improves by one to three orders of magnitude, with one notable exception that gets worse - and that exception tells you something important about the cost of real security.

How it compares

Every other project in this space builds one piece of the puzzle. ETH2030 is the only implementation spanning the entire Ethereum roadmap - all eight phases, all three layers, all 65 items. That breadth is both its unique value and its fundamental limitation.

Five-year question

There is a kind of knowledge you can only get from building something. Reading the EIP-7928 specification tells you that Block Access Lists track state dependencies for parallel execution. Implementing it tells you that reverted calls, EXTCODEHASH lookups on empty accounts, and system contract interactions all generate state accesses that need tracking - and that the conflict graph is denser than anyone expects from reading the transaction pool alone. A reference implementation generates not production-quality code, but production-quality questions.

The distance between 5 million gas per second and 1 billion is not merely quantitative. It is the distance between Ethereum as a settlement layer and Ethereum as a global execution platform. Whether that gap closes by 2030 depends on four engineering realities no specification or reference implementation can resolve. Parallel execution under adversarial MEV, where searchers deliberately construct state access patterns designed to force serialization. Post-quantum migration for 200 million existing ECDSA accounts without breaking backward compatibility. ZK proving latency - current state of the art is 7.4 seconds on 24 GPUs, but quick slots run every 6 seconds. And whether the Ethereum community can sustain coordinated progress across all three layers simultaneously, because the roadmap is not a menu - you do not get to pick gigagas without BALs, or 3SF without quick slots, or native rollups without the ZK stack underneath.

The coupling that the eth2030 implementation reveals in its E2E tests is the same coupling that makes the roadmap fragile to delays. If Glamsterdam ships late, Hogota's multidimensional gas has no foundation. If PeerDAS slips, native rollups lose their data availability. The roadmap composes beautifully when everything ships on schedule. Roadmaps rarely ship on schedule.

And yet. All 65 items fit into a single codebase. The types align. The interfaces connect. Thirty-six thousand state tests pass. The node syncs with mainnet. That is more than most five-year technology roadmaps achieve before anyone writes a line of code. The completed-roadmap Ethereum - PayPal-scale L1 throughput, finality in seconds, solo staking for $3,000, stateless validation on commodity hardware, quantum-resistant cryptography - is a genuinely compelling vision. It composes. Whether it ships is a different question, and it is the right question for the community to be asking now, with code on the table, rather than in 2030 when the answers are more expensive.