Ethereum Roadmap: Surge, Verge, Purge, Splurge

The Merge перевёл Ethereum на Proof-of-Stake, но это был только первый шаг. Транзакция на L2 всё ещё стоила 1-2, full нода требовала 300+ ГБ SSD, а потеря seed-фразы означала потерю всех средств. Виталик Бутерин опубликовал roadmap из пяти этапов - Surge, Verge, Purge, Splurge - план превращения Ethereum из «медленного и дорогого» в «100,000 TPS с кошельком удобнее Apple Pay». Каждый этап решает конкретную проблему: масштабирование данных, размер нод, раздувание state, удобство кошельков.

• **EIP-4844 (март 2024):** после активации Cancun upgrade стоимость транзакций на Arbitrum и Optimism упала в 10-100 раз - с $0.50-2.00 до $0.01-0.05. Base (L2 от Coinbase) обрабатывает миллионы транзакций в день по цене меньше цента
• **ERC-4337 (март 2023):** Safe (бывший Gnosis Safe) управляет активами на 100+ млрд через smart contract wallets. Приложения вроде Worldcoin используют AA для onboarding миллионов пользователей без seed-фраз - вход через биометрию
• **State bloat:** полный state Ethereum вырос с 1 ГБ (2015) до 300+ ГБ (2024). Без The Purge через 5 лет запуск ноды потребует терабайтный SSD - угроза децентрализации

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

• The Merge: From PoW to PoS

Proto-Danksharding: EIP-4844 и blob-транзакции

После The Merge Ethereum перешёл на Proof-of-Stake, но главная проблема осталась: **Layer 2 решения** (Optimism, Arbitrum, Base) публикуют данные в Ethereum L1, и это стоит дорого. Rollup должен записать каждую транзакцию пользователя в calldata блока L1. Calldata обрабатывается EVM и хранится навсегда - за это L2 платит gas по обычным тарифам. Результат: транзакция на Arbitrum стоит $0.50–$2.00, хотя вычисления происходят off-chain.

**EIP-4844** (Proto-Danksharding), активированный в Cancun upgrade 13 марта 2024 года, ввёл новый тип данных - **blobs** (Binary Large Objects). Blob - это 128 КБ данных, которые **не** попадают в EVM и **не** хранятся навсегда. Blobs доступны только ~18 дней, после чего ноды их удаляют (pruning). Этого достаточно для L2, потому что за 18 дней любой может скачать данные и проверить rollup.

Каждый blob верифицируется через **KZG commitment** - это криптографическое обязательство (48 байт), которое позволяет доказать, что blob содержит определённые данные, без передачи всего blob. KZG commitment записывается в блок навсегда, а сам blob - только на ~18 дней. Это обеспечивает data availability: любой может проверить, что L2 предоставил честные данные.

Ключевая деталь: у blobs **свой собственный gas market**, полностью отделённый от execution gas. Target - 3 blobs на блок (384 КБ), максимум - 6 blobs (768 КБ). Blob gas price работает по алгоритму, аналогичному EIP-1559: если в блоках больше 3 blobs - цена растёт экспоненциально, если меньше - падает. Это значит, что даже при высоком gas price на обычные транзакции, blobs могут стоить копейки.

Verkle Trees: путь к stateless клиентам

Сегодня Ethereum хранит всё состояние (балансы, storage контрактов, код) в структуре данных под названием **Merkle Patricia Trie (MPT)**. Это дерево с branching factor 16 (каждый узел имеет до 16 дочерних). Чтобы доказать, что определённый аккаунт имеет определённый баланс, нужно предоставить **proof** - путь от корня дерева до листа.

Проблема MPT: **размер proof огромный**. Для одного значения proof содержит все sibling хеши на каждом уровне дерева. При глубине ~30 и branching factor 16 proof для одного значения занимает **~4 КБ**. Чтобы верифицировать блок, full node должна иметь всё состояние (~300+ ГБ) локально. Это делает невозможным **stateless client** - ноду, которая верифицирует блоки, не храня полное состояние.

Название **Verkle** = **Vec**tor commitment + Me**rkle** tree. Вместо хеширования дочерних узлов (как в Merkle) используются **vector commitments** - криптографические примитивы, позволяющие «открыть» одно значение из вектора с помощью компактного proof. Два кандидата: **IPA** (Inner Product Argument) - не требует trusted setup, и **KZG** - более компактный, но требует trusted setup (уже проведён для EIP-4844).

**EIP-6800** описывает переход Ethereum на Verkle trees. План: **overlay transition** - новые данные пишутся в Verkle tree, старые остаются в MPT. Постепенно аккаунты «мигрируют» при обращении. Это позволяет обойтись без hard fork, останавливающего сеть. Конечная цель - **stateless clients**: ноды, которые верифицируют блоки, получая proof вместе с блоком, без хранения полного state.

**Stateless clients - зачем?** Сейчас запуск full node требует ~300+ ГБ SSD и часы на синхронизацию. С Verkle trees и stateless verification можно будет верифицировать блоки, имея только ~150 КБ proof данных к каждому блоку. Это радикально снижает требования к нодам и увеличивает децентрализацию.

The Purge: борьба со state bloat

Каждый аккаунт, каждый storage слот смарт-контракта, каждый байт кода - всё это **state** Ethereum. Каждая full нода обязана хранить полный state, чтобы валидировать транзакции. Проблема: state только растёт. Создать аккаунт стоит 20,000 gas (SSTORE), а хранить его - **бесплатно навсегда**. Это классическая трагедия общих ресурсов.

**The Purge** - этап roadmap, посвящённый уменьшению требований к нодам. Он включает несколько компонентов: **history expiry** (EIP-4444), **state expiry**, и **Portal Network** для доступа к историческим данным.

**History Expiry (EIP-4444)** - самый близкий к реализации компонент. Идея: ноды не обязаны хранить блоки старше ~1 года. Исторические данные нужны для исследователей, аналитиков, block explorers - но не для валидации новых блоков. EIP-4444 позволит full нодам хранить только ~30 ГБ последней истории вместо ~1 ТБ полной цепочки.

**State Expiry** - более радикальный подход. Идея: аккаунты и storage слоты, к которым не обращались N эпох (~1–2 года), «засыпают» - они остаются в дереве, но выносятся из «горячего» state. Чтобы «разбудить» аккаунт, нужно предоставить **witness proof** (доказательство его последнего состояния). Для этого необходимо **address space extension** - расширение адресов с 20 до 32 байт, чтобы включить эпоху создания.

**Portal Network** решает проблему доступа к историческим данным. Это P2P-сеть, построенная на DHT (Distributed Hash Table), где каждая нода хранит только часть истории. Хочешь блок #1,000,000? Portal Network найдёт ноду, которая его хранит, и доставит данные. Это позволяет full нодам сбросить историю, не теряя к ней доступ.

Account Abstraction: кошельки нового поколения

В Ethereum существуют два типа аккаунтов: **EOA** (Externally Owned Account) - управляется приватным ключом, и **Contract Account** - управляется кодом. Проблема: EOA жёстко ограничен. Единственный способ авторизации - подпись одним приватным ключом (ECDSA secp256k1). Потерял ключ - потерял всё. Нет мультиподписей, нет social recovery, нет лимитов трат, нет батчинга транзакций.

**Account Abstraction (AA)** - идея, что логика аккаунта (авторизация, оплата gas, верификация подписи) должна быть **программируемой**. Вместо жёсткого ECDSA - произвольная логика в смарт-контракте. **ERC-4337** (март 2023) реализует AA без изменения протокола Ethereum, используя альтернативную инфраструктуру поверх существующей сети.

Ключевые компоненты ERC-4337: - **UserOperation** - структура, заменяющая транзакцию. Содержит callData (что выполнить), signature (в любом формате), paymaster (кто платит gas) - **Bundler** - off-chain сервис, который собирает UserOperations и отправляет их как обычную транзакцию в EntryPoint контракт - **EntryPoint** - singleton контракт (один на всю сеть), который валидирует и исполняет UserOperations - **Paymaster** - контракт, который оплачивает gas за пользователя. Это позволяет gasless транзакции: пользователь не держит ETH

**Native Account Abstraction (RIP-7560)** - следующий шаг. ERC-4337 работает поверх протокола (на уровне контрактов), что добавляет overhead (~42,000 gas за EntryPoint логику). RIP-7560 предлагает встроить AA в сам протокол Ethereum, убрав посредников. Транзакция от smart wallet будет первоклассной сущностью, как сегодня транзакция от EOA.

**Paymaster меняет UX радикально.** Представь: новый пользователь скачал приложение, создал кошелёк через Face ID (Passkey), совершил первую транзакцию - и ни разу не видел слово «gas», не покупал ETH, не видел hex-адрес. Paymaster оплатил gas, Passkey заменил seed-фразу, smart wallet позволил batch. Это уровень UX, сравнимый с Apple Pay.

Итоги

• **Proto-Danksharding (EIP-4844)** - blob-транзакции с отдельным gas market, 128 КБ данных, хранящихся ~18 дней. KZG commitments гарантируют целостность. Результат: L2 комиссии снизились в 10-100 раз после Cancun upgrade
• **Verkle Trees (The Verge)** - замена MPT с proof ~150 Б вместо ~4 КБ. Vector commitments (IPA/KZG) с branching factor 256 делают возможными stateless клиенты - верификация блоков без хранения 300+ ГБ state
• **The Purge** - борьба со state bloat через history expiry (EIP-4444), state expiry (засыпание неактивных аккаунтов) и Portal Network (DHT для исторических данных). Цель: full нода на обычном ноутбуке
• **Account Abstraction (ERC-4337)** - smart contract wallets с social recovery, session keys, batch транзакциями и Paymasters для gasless UX. Путь от seed-фразы к Apple Pay, упомянутому в начале как ориентир удобства

Связанные темы

Roadmap Ethereum строится на фундаменте предыдущих концепций и формирует будущее экосистемы:

• The Merge: переход на Proof-of-Stake — The Merge - первый этап roadmap. Все последующие улучшения (Surge, Verge, Purge, Splurge) строятся на фундаменте PoS
• KZG Commitments — KZG commitments - криптографическая основа blob-транзакций (EIP-4844) и один из кандидатов для vector commitments в Verkle trees
• Деревья хешей и структуры данных — Verkle trees - эволюция Merkle trees с vector commitments вместо хеширования, сохраняющая свойства верифицируемости при компактных proofs
• Data Availability — Proto-Danksharding решает проблему data availability для L2 rollups - blobs гарантируют доступность данных без постоянного хранения

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

• Proto-Danksharding хранит blobs ~18 дней. Что произойдёт, если L2 rollup окажется в dispute и потребуются данные, удалённые после pruning? Как архитектура решает эту проблему?
• Verkle trees делают возможными stateless клиенты, но кто-то всё равно должен хранить полный state для генерации proofs. Не создаёт ли это новую форму централизации?
• ERC-4337 реализует Account Abstraction без изменения протокола. Какие trade-offs (gas overhead, сложность, attack surface) по сравнению с Native AA (RIP-7560) - и почему сообщество выбрало этот путь первым?

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

• dist-14-sharding