Большой ремонт Ethereum 2026: на этот раз откажемся от «прогрессивизма»

Автор: Chloe, ChainCatcher

За последние две недели основатель Ethereum Виталик Бутерин активно публиковал на X серию технических статей, охватывающих маршруты масштабирования, противодействие квантовым атакам, абстракцию аккаунтов, реконструкцию уровня исполнения и ускоренное развитие с помощью ИИ. Эти публикации получили название «План крупной реконструкции Ethereum 2026». За ними стоит набросок маршрута Strawmap, опубликованный одновременно Фондом Ethereum, — документ, предусматривающий увеличение пропускной способности L1 до уровня 10000 TPS к 2029 году.

Однако, чем амбициознее план, тем больше возникают сомнений в его реализуемости, ведь история показывает, что реализация Ethereum идет медленнее запланированного. Встает вопрос: готов ли Ethereum оставить «эволюционный» подход и перейти к радикальной реконструкции?

Маршрут Strawmap: Ethereum к 2029 году с 10000 TPS

Исследователь Фонда Ethereum Джастин Дрейк 25 февраля опубликовал маршрутный план Strawmap, раскрывающий видение и график обновлений L1. В рамках этого плана поставлены пять «северных звезд»: высокая производительность L1, пропускная способность GigaTPS, масштабирование L2 до TeraTPS, квантобезопасность L1 и нативные приватные транзакции.

Цель — обработка 10 000 транзакций в секунду на L1 и 10 миллионов на L2. План предполагает семь хардфорков с полугодовым циклом, охватывающих изменения в слоях консенсуса, данных и исполнения. Виталик Бутерин выразил поддержку, а за последние две недели он также публиковал на X серию технических статей, разбирающих ключевые аспекты этого маршрута.

Стратегический фокус: масштабирование Ethereum L1 и реконструкция уровня исполнения

Виталик подчеркивает: в отличие от стратегии последних лет, сосредоточенной на L2 Rollups и легком L1, текущий план предполагает одновременно долгосрочный переход и краткосрочное значительное увеличение возможностей масштабирования L1.

1. Краткосрочные меры: обновление Glamsterdam

В рамках ближайших планов — обновление Glamsterdam, которое введет «списки доступа на уровне блока (BALs)» для поддержки параллальной проверки, что устранит узкое место последовательной обработки. Также будет реализована идея разделения предложителей и строителей (Enshrined Proposer-Builder Separation, ePBS), что повысит эффективность использования слотов в 12 секунд.

2. Долгосрочные меры: развитие ZK-EVM и Blob

Долгосрочное масштабирование опирается на два столпа: ZK-EVM и Blob. В рамках ZK-EVM к концу 2026 года планируется внедрение первых клиентов с ZK-EVM, а к 2027 году — расширение их числа и усиление безопасности. Конечная цель — реализовать «3 из 5» механизм подтверждения, при котором блок считается валидным, если он подтвержден тремя из пяти систем доказательств.

В направлении Blob — развитие PeerDAS (выборка данных для доступности), которое должно повысить пропускную способность до 8 МБ/с. Технология позволяет узлам проверять данные, скачивая лишь небольшие фрагменты, что значительно повышает масштабируемость и снижает требования к оборудованию. Также планируется перенос данных блоков в Blob вместо дорогостоящего и постоянного хранения calldata, что оптимизирует структуру данных и расширяет масштабируемость.

3. Реконструкция уровня исполнения: переход к бинарным деревьям состояний

Виталик отмечает, что 80% узких мест в эффективности доказательств связаны с устаревшей архитектурой. Согласно EIP-7864, переход с «16-ричной Keccak MPT» к «бинарным деревьям состояний» сократит длину ветвей в 4 раза, что даст значительный прирост эффективности:

• Снижение затрат на пропускную способность примерно в 4 раза — важный шаг для легких клиентов вроде Helios.
• Ускорение доказательств: при использовании BLAKE3 — в 3 раза, при Poseidon — до 100 раз.
• Оптимизация доступа: хранение слотов в «страницах» (64–256 слотов) позволяет сэкономить более 10 000 Gas на транзакцию при чтении/записи соседних данных.

Более амбициозный проект — миграция виртуальной машины (VM). В настоящее время ZK-верификаторы пишутся на RISC-V, и если EVM сможет работать напрямую на RISC-V, это устранит издержки трансляции между виртуальными машинами и повысит доказуемость системы. Планируется три этапа:

1. Передача существующих предкомпилированных контрактов на новую VM.
2. Разрешение пользователям разворачивать новые VM-контракты.
3. Переписывание самой EVM под новую VM.

Это обеспечит обратную совместимость и снизит издержки при переходе.

Дорожная карта против квантовых угроз: устранение 4 уязвимых точек Ethereum

Виталик выделяет четыре ключевых уязвимости в безопасности Ethereum перед квантовыми атаками:

1. Консенсус: BLS-подписи

Планируется заменить текущие подписи на основе BLS на более квантобезопасные, используя хэшированные подписи и STARKs для агрегации. Пока что, до полной реализации «легкого консенсуса», будет запущена версия цепочки с обработкой 256–1024 подписей за слот, без STARK-агрегации, что снизит сложность.

2. Доступность данных: KZG и STARKs

Виталик предлагает заменить KZG-подписи на STARKs, обладающие квантовой стойкостью. Однако STARKs не поддерживают эффективную 2D-выборку данных из-за отсутствия линейных свойств, поэтому Ethereum выберет более консервативный путь — использование 1D DAS (например, PeerDAS). Также объем STARK-доказательств большой, что требует сложных рекурсивных методов для уменьшения размера. В целом, путь возможен, но требует значительных инженерных усилий.

3. Внешние аккаунты (EOA): ECDSA

ECDSA — уязвимы к квантовым атакам, поэтому планируется внедрение «нативной абстракции аккаунтов» (native AA), которая позволит пользователям менять алгоритмы подписи без смены адресов.

4. Приложения: ZK-доказательства на основе KZG или Groth16

Главная проблема — квантовая стойкость STARKs делает их очень дорогими (в 20 раз дороже SNARKs). Виталик предлагает ввести «Validation Frame» (EIP-8141), позволяющий агрегировать подписи и доказательства вне цепи, а затем сжать их в компактное доказательство для размещения в блоке. Это снизит затраты и ускорит проверку, обеспечивая безопасность и эффективность в эпоху квантовых угроз.

ИИ как ускоритель: завершение дорожной карты Ethereum к 2030 году за несколько недель

Виталик подчеркивает, что ИИ ускоряет разработку Ethereum. Он делится экспериментом: за две недели с помощью vibe-coding создал прототип дорожной карты Ethereum 2030. Он отмечает, что всего за час его ноутбук с GPT-OSS:20B написал бэкенд для блога, а при использовании более мощных моделей — можно сделать это за один раз. ИИ уже меняет скорость реализации планов.

Он предлагает использовать ИИ для ускорения тестирования, формальной верификации и генерации различных реализаций, что может увеличить скорость разработки в 5 раз. Виталик считает, что в обозримом будущем невозможно полностью заменить безопасность программ с помощью одного промпта, но этот процесс можно значительно ускорить.

Он также предполагает, что дорожная карта Ethereum может завершиться быстрее и безопаснее, чем ожидается, — «без ошибок код, давно считающийся утопией, может стать реальностью». Если бы это было пять лет назад, это казалось невозможным.

Медленная реализация и реальные вызовы

Однако, несмотря на амбициозные планы, Ethereum сталкивается с реальными проблемами: история показывает, что реализация идет медленнее запланированного. The Merge задержался с 2020 года до 2022, а внедрение EIP-4844 — растянулось на годы. Обычно задержки связаны с аудитами, координацией клиентов и децентрализацией.

Сейчас же времени у Ethereum остается мало. Конкуренты усиливают давление, квантовые угрозы становятся реальностью, а развитие с помощью ИИ требует кардинальных изменений. Виталик призывает отказаться от постепенных подходов и полностью переосмыслить архитектуру, ориентируясь на принципы открытости, приватности и безопасности (CROPS). Важна не только техническая дорожная карта, но и мышление, которое должно эволюционировать без привязки к старым путям — это, возможно, самый сложный шаг в отказе от «эволюционизма».