Автор: Chloe, ChainCatcher
За последние две недели основатель Ethereum Виталик Бутерин опубликовал в X несколько технических статей, охватывающих ключевые темы, такие как масштабируемость, защита от квантовых атак, абстракция аккаунтов, реконструкция исполнительного уровня и ускорение разработки с помощью ИИ, что было названо внешними наблюдателями «дорожной картой крупномасштабной модернизации Ethereum 2026». За этой серией публикаций стоит одновременно выпущенный Ethereum Foundation фреймворк Strawmap — документ, в котором планируется довести пропускную способность L1 Ethereum до уровня 10000 TPS к 2029 году.
Однако чем амбициознее план, тем больше сомнений возникает в его способности выполнить обещания, ведь, оглядываясь на историю, Ethereum всегда отставал от запланированных сроков. Готов ли Ethereum на этот раз отказаться от «постепенности» и перейти к радикальной реконструкции?
Strawmap: Ethereum достигнет 10000 TPS к 2029 году
Исследователь Фонда Ethereum Джастин Дрейк 25 февраля опубликовал документ под названием Strawmap, раскрывающий видение и график будущих обновлений Ethereum L1. Этот план устанавливает пять ключевых «северных звезд»: сверхбыстрая производительность L1, пропускная способность L1 в гигагазы, масштабирование L2 до терагазов, постквантовая безопасность L1 и нативная приватность транзакций L1. Конечные количественные цели: 10 000 транзакций в секунду на L1 и 10 миллионов транзакций в секунду на L2.
Этот план предполагает продвижение через семь форков с циклом обновления каждые шесть месяцев, охватывая изменения в консенсусном, данных и исполнительном уровнях. За это выступает основатель Ethereum Виталик Бутерин, который за последние две недели активно публиковал на X подробные технические статьи, разбирая ключевые аспекты дорожной карты.

Стратегический приоритет: фокус на масштабировании Ethereum L1 и реорганизации исполнительного уровня
Виталикааргументы показывают: в отличие от стратегии последних лет, ориентированной на L2 Rollup и сокращении роли L1, текущая цель — сохранить долгосрочную тенденцию, одновременно значительно повысив масштабируемость L1 в краткосрочной перспективе.
1. Краткосрочный процесс: апгрейд Glamsterdam
В краткосрочном плане предстоящее обновление Glamsterdam введет списки доступа на уровне блока (Block-Level Access Lists, 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 МБ/с. Основная суть технологии заключается в том, что узлы могут выполнять проверку, загружая лишь небольшие фрагменты данных, что значительно увеличивает пропускную способность и одновременно снижает аппаратные требования к узлам. С другой стороны, для удовлетворения потребностей будущего масштабного внедрения основная сеть Ethereum перейдет на прямое хранение данных блоков в пространстве Blob, заменив прежнюю дорогостоящую и требующую постоянного хранения модель calldata. Этот переход направлен на оптимизацию структуры хранения данных и переформирование пути масштабирования Ethereum на уровне данных.
3. Реорганизация исполнительного уровня: переход на бинарное дерево состояний вместо EVM
Vitalik указывает, что текущий узкий канал эффективности доказательства в Ethereum на 80% обусловлен устаревшей архитектурой. Согласно EIP-7864, после перехода от текущей «шестнадцатеричной Keccak MPT-дерево состояний» к «бинарному дереву состояний» длина ветвей сократится в четыре раза. Это изменение значительно повысит эффективность обработки данных:
Пропускная способность данных: снижение затрат примерно в 4 раза, что является качественным прорывом для легких клиентов, таких как Helios.
Скорость доказательства: при использовании BLAKE3 ускорение составляет примерно в 3 раза; при использовании варианта Poseidon потенциальное ускорение может достигать 100 раз.
Оптимизация депозитов и выводов: дизайн слотов «страниц» (64–256 слотов) позволяет dapp экономить более 10 000 газа за транзакцию при чтении и записи смежных данных.
Более амбициознымпредложением является миграция ВМ (виртуальной машины), поскольку текущие ZK-протоколы в основном написаны на RISC-V; если EVM сможет работать непосредственно на RISC-V, устраняя потери на трансляцию между двумя уровнями виртуальных машин, общая доказуемость системы значительно возрастет. Текущий план внедрения включает три этапа:
1. Сначала пусть новая ВМ примет существующие предварительно скомпилированные смарт-контракты
2. Снова открыть возможность для пользователей развертывать новые контракты VM
3. В конечном итоге переписать сам EVM в виде смарт-контракта, работающего на новой ВМ.
Это обеспечивает обратную совместимость, а окончательная стоимость конверсии составляет только повторную настройку комиссий за газ.
План защиты от квантовых угроз: устранение четырех основных технических уязвимостей Ethereum
По ключевому вопросу постквантовой безопасности L1 Vitalik в технической статье четко отметил, что на текущем этапе Ethereum имеет четыре квантовых уязвимости, которые перечислены ниже:
1. Уровень консенсуса: подпись BLS
Путь замены консенсусного слоя уже намечается: Виталик предложил решение «Lean consensus» (упрощённый консенсус), вводящее варианты подписей на основе хеширования (Hash-based) в сочетании со STARKs для агрегации и сжатия, чтобы обеспечить устойчивость к квантовым атакам. Однако Виталик добавил, что до полного внедрения «упрощённого консенсуса» будет запущена версия «упрощённой рабочей цепочки», которая будет обрабатывать всего 256–1024 подписей за слот и сможет функционировать без агрегации STARK, значительно снижая инженерные требования.
2. Доступность данных: Комументы и доказательства KZG
В отношении доступности данных Виталик предлагает заменить существующие «KZG-обязательства» на «STARKs с квантовой устойчивостью», но это сопряжено с двумя основными компромиссами:
Во-первых, STARKs не обладают линейными свойствами KZG, что затрудняет эффективную 2D-выборку данных, поэтому Ethereum выбрал более консервативный путь 1D DAS (например, PeerDAS), отдавая приоритет устойчивости сети, а не максимальному масштабированию.
Во-вторых, поскольку доказательства STARK имеют большой размер, разработчикам необходимо решить инженерную проблему «доказательство больше данных» с помощью сложных методов, таких как рекурсивные доказательства. В целом, Виталик считает, что этот квантово-устойчивый путь остается практически осуществимым благодаря упрощению технических целей и поэтапной оптимизации, однако требует огромных инженерных усилий.
3. Внешний владеемый аккаунт (EOA): подпись ECDSA
В целях защиты аккаунтов, находящихся во внешнем управлении (EOA), поскольку существующая подпись ECDSA крайне уязвима перед квантовыми компьютерами, Виталик склоняется к тому, чтобы через «натуральную абстракцию аккаунтов (native AA)» превратить все аккаунты в смарт-контракты, позволяя пользователям гибко менять квантово-устойчивые алгоритмы подписи, не отказываясь от существующих адресов кошельков.
4. Уровень приложений: ZK-доказательства, зависящие от KZG или Groth16
Наконец, на уровне приложений основной проблемой является чрезвычайно высокая стоимость газа для квантово-устойчивых доказательств STARK — она примерно в 20 раз выше, чем у текущих SNARKs, что слишком дорого для протоколов конфиденциальности и L2. Виталик предлагает ввести «рамку проверки (Validation Frame)» через EIP-8141, чтобы агрегировать большое количество сложных подписей и доказательств вне цепочки.
С помощью технологии рекурсивных доказательств исходные данные для проверки, размером в сотни мегабайт, могут быть сжаты до крайне маленького STARK-доказательства, размещаемого в блокчейне, что не только экономит место в блоках, но и значительно снижает стоимость использования, позволяя даже на этапе Mempool мгновенно выполнять проверку, обеспечивая пользователям возможность эффективно и недорого использовать различные децентрализованные приложения в эпоху квантовых угроз.
AI в роли ускорителя: выполнение дорожной карты Ethereum 2030 за несколько недель
Помимо обновления архитектуры, недавние твиты Виталика подчеркивают, что ИИ ускоряет процесс разработки Ethereum. Он перепостил эксперимент разработчика, который за две недели построил прототип дорожной карты Ethereum 2030 с помощью vibe-coding, и прокомментировал: «Шесть месяцев назад это даже не входило в рамки возможного, теперь это стало трендом».
Даже сам Виталик лично протестировал: он написал бэкенд-код для блога за один час, используя модель gpt-oss:20b, запущенную на ноутбуке; при использовании более мощной модели kimi-2.5 он ожидает, что сможет «сделать это за один раз». Можно сказать, что повышение эффективности благодаря ИИ уже не линейно — он меняет скорость реализации дорожной карты Ethereum.
Он предлагает распределить выгоды от ИИ поровну между скоростью и безопасностью: использовать ИИ для генерации масштабных тестовых случаев, применять формальную верификацию к ключевым модулям и создавать несколько независимых реализаций одной и той же логики для взаимной проверки. По мнению Виталика, в обозримом будущем невозможно получить высокобезопасный код программы всего лишь одним запросом — борьба с багами и несоответствиями реализации всё ещё существует, но этот процесс можно ускорить в пять раз.
Наконец, он также отметил возможность того, что дорожная карта Ethereum будет реализована быстрее, чем ожидалось внешними наблюдателями, и с более высокими стандартами безопасности. «Программный код без ошибок, долгое время считавшийся идеалистической фантазией, теперь, возможно, станет возможным». Такое утверждение пять лет назад в контексте разработки Ethereum было бы практически невозможно.

Slow delivery pace and real-world challenges
Однако публикация такого объема сложных технических материалов на рынке всегда оставляет вопрос о возможности своевременного выполнения этих обязательств в рамках дорожной карты Ethereum.
Из исторических данных видно, что график внедрения Ethereum всегда отставал от ожиданий. The Merge был перенесен с первоначального прогноза на «конец года» в начале 2020 года до сентября 2022 года; реализация EIP-4844 (Proto-Danksharding) также заняла несколько лет. Такие задержки обычно связаны с факторами, такими как безопасностные аудиты, координация между несколькими клиентами и децентрализованное управление.
Но на этот раз у Ethereum осталось мало времени на постепенные изменения. Наступление конкурентов, реальные вызовы со стороны квантовых угроз и революция производительности, вызванная ИИ, вынуждают Ethereum полностью отказаться от «постепенности»; стоя на историческом переломном моменте «либо продвигайся вперед, либо отступай», прежний мягкий подход с небольшими итерациями, возможно, уже не сможет поддержать видение Ethereum как глобального уровня расчетов.
А Виталиксвежие призывытакже подчеркивают, что это изменение — это не просто техническая перестройка; он требует от сообщества полностью отказаться от зависимости от устоявшихся путей на уровне приложений, сохранив ключевые принципы: сопротивление цензуре, открытость, конфиденциальность и безопасность (CROPS), и начать заново проектировать приложения с первых принципов.
Технологии могут иметь дорожную карту, но обновление мышления не имеет графика разветвления — возможно, именно это является самым сложным шагом в прощании с «постепенностью».

