Ethereum Roadmap: Surge, Verge, Purge, Splurge

The Merge moved Ethereum to Proof-of-Stake, but that was only the first step. A transaction on L2 still cost $1-2, a full node required 300+ GB of SSD, and losing a seed phrase meant losing all funds. Vitalik Buterin published a roadmap with five phases - Surge, Verge, Purge, Splurge - a plan to transform Ethereum from "slow and expensive" into "100,000 TPS with a wallet more convenient than Apple Pay". Each phase solves a specific problem: data scaling, node size, state bloat, wallet usability.

• **EIP-4844 (March 2024):** after the Cancun upgrade, transaction costs on Arbitrum and Optimism dropped 10–100× - from $0.50-2.00 to $0.01-0.05. Base (Coinbase's L2) processes millions of transactions per day at under a cent
• **ERC-4337 (March 2023):** Safe (formerly Gnosis Safe) manages $100B+ in assets via smart contract wallets. Apps like Worldcoin use AA to onboard millions of users without seed phrases - login via biometrics
• **State bloat:** Ethereum's full state grew from 1 GB (2015) to 300+ GB (2024). Without The Purge, running a node will require a terabyte-class SSD in 5 years - a threat to decentralization

Предварительные знания

• The Merge: From PoW to PoS

Proto-Danksharding: EIP-4844 and Blob Transactions

After The Merge, Ethereum moved to Proof-of-Stake, but the main problem remained: **Layer 2 solutions** (Optimism, Arbitrum, Base) publish data to Ethereum L1, and this is expensive. A rollup must write every user transaction into the calldata of an L1 block. Calldata is processed by the EVM and stored forever - so L2s pay gas at regular rates. Result: a transaction on Arbitrum costs $0.50–$2.00, even though computation happens off-chain.

**EIP-4844** (Proto-Danksharding), activated in the Cancun upgrade on March 13, 2024, introduced a new data type - **blobs** (Binary Large Objects). A blob is 128 KB of data that does **not** enter the EVM and is **not** stored forever. Blobs are available for ~18 days, after which nodes prune them. This is sufficient for L2s, because within 18 days anyone can download the data and verify the rollup.

Each blob is verified through a **KZG commitment** - a cryptographic commitment (48 bytes) that allows proving a blob contains certain data without transmitting the entire blob. The KZG commitment is stored in the block forever, while the blob itself is kept for only ~18 days. This ensures data availability: anyone can verify that the L2 provided honest data.

A key detail: blobs have **their own gas market**, completely separate from execution gas. The target is 3 blobs per block (384 KB), maximum 6 blobs (768 KB). Blob gas price works via an algorithm analogous to EIP-1559: if blocks contain more than 3 blobs - the price grows exponentially; fewer - it falls. This means that even when regular transaction gas prices are high, blobs can cost almost nothing.

Verkle Trees: The Path to Stateless Clients

Today Ethereum stores all state (balances, contract storage, code) in a data structure called the **Merkle Patricia Trie (MPT)**. It is a tree with a branching factor of 16 (each node has up to 16 children). To prove that a certain account has a certain balance, you must provide a **proof** - a path from the root to the leaf.

The problem with MPT: **proof sizes are huge**. For a single value, the proof contains all sibling hashes at each level. With a depth of ~30 and a branching factor of 16, a proof for one value takes **~4 KB**. To verify a block, a full node must have the entire state (~300+ GB) locally. This makes a **stateless client** impossible - a node that verifies blocks without storing the full state.

The name **Verkle** = **Vec**tor commitment + Me**rkle** tree. Instead of hashing child nodes (as in Merkle), **vector commitments** are used - cryptographic primitives that allow "opening" one value from a vector with a compact proof. Two candidates: **IPA** (Inner Product Argument) - no trusted setup required, and **KZG** - more compact but requires a trusted setup (already performed for EIP-4844).

**EIP-6800** describes Ethereum's transition to Verkle trees. The plan: **overlay transition** - new data is written into the Verkle tree, old data stays in the MPT. Gradually accounts "migrate" when they are accessed. This avoids a hard fork that stops the network. The end goal is **stateless clients**: nodes that verify blocks by receiving a proof alongside the block, without storing the full state.

**Why stateless clients?** Today running a full node requires 300+ GB SSD and hours of sync time. With Verkle trees and stateless verification, blocks could be verified with only ~150 KB of proof data per block. This dramatically lowers the hardware requirements for nodes and increases decentralization.

The Purge: Fighting State Bloat

Every account, every contract storage slot, every byte of code - all of this is Ethereum **state**. Every full node must store the complete state to validate transactions. The problem: state only grows. Creating an account costs 20,000 gas (SSTORE), but storing it is **free forever**. This is a classic tragedy of the commons.

**The Purge** is the roadmap phase dedicated to reducing node requirements. It includes several components: **history expiry** (EIP-4444), **state expiry**, and the **Portal Network** for accessing historical data.

**History Expiry (EIP-4444)** is the component closest to implementation. The idea: nodes are not required to store blocks older than ~1 year. Historical data is needed by researchers, analysts, and block explorers - but not for validating new blocks. EIP-4444 will allow full nodes to store only ~30 GB of recent history instead of ~1 TB of the full chain.

**State Expiry** is a more radical approach. The idea: accounts and storage slots that have not been accessed for N epochs (~1–2 years) "go dormant" - they remain in the tree but are removed from "hot" state. To "wake up" an account, you must provide a **witness proof** (a proof of its last known state). This requires **address space extension** - expanding addresses from 20 to 32 bytes to include the creation epoch.

**Portal Network** solves the problem of accessing historical data. It is a P2P network built on DHT (Distributed Hash Table), where each node stores only a portion of history. Want block #1,000,000? Portal Network will find a node that holds it and deliver the data. This allows full nodes to drop history without losing access to it.

Account Abstraction: Next-Generation Wallets

Ethereum has two account types: **EOA** (Externally Owned Account) - controlled by a private key, and **Contract Account** - controlled by code. The problem: EOA is rigidly limited. The only authorization method is a signature from a single private key (ECDSA secp256k1). Lose the key - lose everything. No multisig, no social recovery, no spend limits, no transaction batching.

**Account Abstraction (AA)** is the idea that account logic (authorization, gas payment, signature verification) should be **programmable**. Instead of hard-coded ECDSA - arbitrary logic in a smart contract. **ERC-4337** (March 2023) implements AA without changing the Ethereum protocol, using alternative infrastructure on top of the existing network.

Key ERC-4337 components: - **UserOperation** - a structure replacing a transaction. Contains callData (what to execute), signature (in any format), paymaster (who pays gas) - **Bundler** - an off-chain service that gathers UserOperations and submits them as a regular transaction to the EntryPoint contract - **EntryPoint** - a singleton contract (one for the whole network) that validates and executes UserOperations - **Paymaster** - a contract that pays gas on behalf of the user. This enables gasless transactions: the user does not hold ETH

**Native Account Abstraction (RIP-7560)** is the next step. ERC-4337 works on top of the protocol (at the contract level), adding overhead (~42,000 gas for EntryPoint logic). RIP-7560 proposes to bake AA into the Ethereum protocol itself, removing intermediaries. A transaction from a smart wallet would be a first-class entity, just as a transaction from an EOA is today.

**Paymaster radically changes UX.** Imagine: a new user downloads an app, creates a wallet via Face ID (Passkey), completes their first transaction - and never saw the word "gas", never bought ETH, never saw a hex address. Paymaster paid the gas, Passkey replaced the seed phrase, the smart wallet enabled batching. This is Apple Pay–level UX.

Key Ideas

• **Proto-Danksharding (EIP-4844)** - blob transactions with a separate gas market, 128 KB of data stored ~18 days. KZG commitments guarantee integrity. Result: L2 fees dropped 10–100× after the Cancun upgrade
• **Verkle Trees (The Verge)** - replacing MPT with ~150 B proofs instead of ~4 KB. Vector commitments (IPA/KZG) with a branching factor of 256 make stateless clients possible - verifying blocks without storing 300+ GB of state
• **The Purge** - fighting state bloat via history expiry (EIP-4444), state expiry (dormant accounts), and Portal Network (DHT for historical data). Goal: a full node on an ordinary laptop
• **Account Abstraction (ERC-4337)** - smart contract wallets with social recovery, session keys, batch transactions, and Paymasters for gasless UX. The path from seed phrases to Apple Pay, mentioned in the opening as a UX benchmark

Related Topics

The Ethereum roadmap builds on the foundations of previous concepts and shapes the future of the ecosystem:

• The Merge: Transition to Proof-of-Stake — The Merge is the first stage of the roadmap. All subsequent improvements (Surge, Verge, Purge, Splurge) are built on the PoS foundation
• KZG Commitments — KZG commitments are the cryptographic foundation of blob transactions (EIP-4844) and one of the candidates for vector commitments in Verkle trees
• Hash-Based Structures — Verkle trees are an evolution of Merkle trees with vector commitments instead of hashing, preserving verifiability while enabling compact proofs
• Data Availability — Proto-Danksharding solves the data availability problem for L2 rollups - blobs guarantee data availability without permanent storage

Вопросы для размышления

• Proto-Danksharding stores blobs for ~18 days. What happens if an L2 rollup is in a dispute and requires data that was deleted after pruning? How does the architecture solve this problem?
• Verkle trees make stateless clients possible, but someone still has to store the full state to generate proofs. Doesn't this create a new form of centralization?
• ERC-4337 implements Account Abstraction without changing the protocol. What are the trade-offs (gas overhead, complexity, attack surface) compared to Native AA (RIP-7560) - and why did the community choose this path first?

Связанные уроки

• dist-14-sharding