Как L1 zkEVM переписывает спецификацию Ethereum: эволюция от Rollup к верифицируемым вычислениям

С 2025 года сообщество разработчиков Ethereum демонстрирует беспрецедентную интенсивность обновлений и переосмысления своей роли в криптоэкосистеме. На фоне дискуссий о ценовой динамике ETH, Фонд Ethereum представил амбициозный дорожный план (Strawmap), который описывает техническую эволюцию протокола на ближайшие годы. Спецификация — это не просто технические улучшения — это качественная трансформация самого Ethereum: от расчетного слоя для L2 до проверяемой основы доверия для всей децентрализованной экономики.

Эта трансформация означает, что каждый шаг выполнения состояния L1 можно будет сжать и проверить с помощью нулевых знаний. Это не копирование проектов zkEVM для L2 (zkSync, Starknet, Scroll), а принципиально иная цель: преобразование самого исполнительного слоя Ethereum в систему, совместимую с ZK. Если L2 zkEVM — это построение ZK-мира поверх Ethereum, то L1 zkEVM — это трансформация самого Ethereum на этот уровень.

Три направления трансформации: от программируемого реестра до проверяемой инфраструктуры

Развитие Ethereum за последние десять лет сопровождалось постепенной эволюцией его концептуальной базы и технических приоритетов. Первый период (2015–2020) фокусировался на том, что Ethereum — это программируемый реестр, способный на большее, чем Bitcoin. Смарт-контракты, DeFi, NFT, DAO — всё выросло из этой базовой истории о универсальности вычислений на блокчейне.

Второй период (2021–2023) сместил акцент на масштабирование через решения Layer 2. С ростом стоимости газа обычные пользователи не могли позволить себе транзакции на L1, и решения Rollup начали доминировать. Ethereum постепенно переосмыслил себя как уровень данных и финальности, предоставляя безопасную базу для L2. The Merge и EIP-4844 служили именно этой цели.

Третий период (2024–2025 годы) ознаменован более глубоким рефлексией. Парадокс заключался в том, что расцвет L2 привел к демонтажу ценности L1: пользователи мигрировали на Arbitrum, Base, Optimism и редко взаимодействовали напрямую с L1. Это вызвало критический вопрос в сообществе: где брать ценность L1, если L2 забирают всех пользователей?

Анализ ключевых технологических направлений Strawmap дает ответ. Verkle Tree, Stateless Client, формальная верификация EVM, нативная поддержка ZK — все эти векторы указывают в одну сторону: наделить Ethereum L1 собственной проверяемостью. Это качественное изменение, которое станет кульминацией L1 zkEVM.

Спецификация — это фундамент: почему 8 рабочих линий меняют архитектуру Ethereum

Связь технических изменений в Strawmap лучше всего понять, рассматривая 8 рабочих линий как единую архитектурную систему, где каждый компонент поддерживает другие.

Рабочая линия 1: Формальная спецификация EVM как основа

Спецификация — это не абстрактная концепция — это математическое определение каждой инструкции и правила трансформации состояния. Сейчас поведение EVM определяется реализациями клиентов (Geth, Nethermind), а не формальной спецификацией. Это означает, что поведение может отличаться в крайних случаях. Для написания ZK-килов невозможно работать с нечеткой системой. Поэтому первая и важнейшая рабочая линия — формализовать каждый аспект EVM так, чтобы его можно было математически проверить.

Рабочая линия 2: Замена хеш-функций на ZK-совместимые

Ethereum активно использует Keccak-256, который весьма затратен для ZK-килов. Основная задача — постепенно заменить Keccak на ZK-дружелюбные функции (Poseidon, Blake серии) во внутренних компонентах, особенно в деревьях состояния и Merkle-доказательствах. Это системное изменение, поскольку хеш-функции пронизывают весь протокол.

Рабочая линия 3: Verkle Tree вместо Merkle Patricia Tree

Verkle Tree заменяет хеш-цепочки векторными компромиссами, уменьшая размер свидетельств в десятки раз. Для L1 zkEVM это означает: меньше данных для подтверждения блока, быстрее генерация доказательств, а также что Verkle Tree — ключевое условие реализуемости L1 zkEVM вообще.

Рабочая линия 4: Безстановные клиенты (Stateless Clients)

Безстановные клиенты могут верифицировать блоки без локального хранения полной базы данных состояния — нужны только данные witness. Это тесно связано с Verkle Tree, поскольку практическая реализуемость зависит от размера свидетельств. Для L1 zkEVM это имеет двойной эффект: уменьшает аппаратные требования к узлам и задает четкие границы входных данных для доказательств.

Рабочая линия 5: Стандартизация ZK-доказательств

L1 zkEVM требует зрелой системы генерации доказательств, но поле ZK очень фрагментировано. Цель этой линии — определить стандартизированный интерфейс на уровне протокола, позволяя конкурировать разным системам. Команда PSE (Privacy and Scaling Explorations) обладает большим опытом в этом.

Рабочая линия 6: Разделение исполнительного и консенсусного уровней

Сейчас исполнительный уровень (EL) и консенсусный уровень (CL) взаимодействуют через Engine API. В L1 zkEVM каждое изменение состояния требует генерации ZK-доказательства, а это может превысить интервал между блоками. Нужно разделить выполнение и генерацию доказательств без нарушения консенсуса — выполнение быстрое, доказательства генерируются асинхронно.

Рабочая линия 7: Рекурсивные и агрегированные доказательства

Генерация доказательства для одного блока затратна, но рекурсивная агрегация нескольких блоков в одно доказательство значительно снизит затраты на верификацию. Прогресс здесь напрямую определит стоимость работы L1 zkEVM.

Рабочая линия 8: Инструменты разработчика и совместимость с EVM

Все низкоуровневые модернизации должны быть прозрачными для разработчиков смарт-контрактов: десятки тысяч контрактов не должны стать непригодными. Эта линия наиболее недооценена, но часто является самой затратной по времени. Каждое обновление EVM требовало массивных тестов на обратную совместимость. Изменения L1 zkEVM превосходят предыдущие, и объем работы с инструментарием возрастет в разы.

Почему именно сейчас: переоценка Ethereum как проверяемой инфраструктуры

Выпуск Strawmap приходится на период сомнений относительно ценовой динамики ETH, но истинная ценность — в переосмыслении Ethereum как долгосрочной инфраструктуры.

Для разработчиков Strawmap дает определенность направления и уверенность в инвестициях времени. Для пользователей эти улучшения превращаются в заметный опыт: транзакции подтверждаются за секунды, активы без перебоев перемещаются между L1 и L2, приватность становится встроенной функцией, а не дополнением.

Объективно, L1 zkEVM не появится быстро — полная реализация ожидается в 2028–2029 годах или позже. Однако это переосмысление ценностного предложения Ethereum кардинально. Если L1 zkEVM будет успешным, Ethereum перестанет быть лишь уровнем расчетов для L2 и станет проверяемой основой доверия для всего Web3, позволяя любому состоянию цепочки математически отслеживаться до цепочки Ethereum ZK-доказательств.

Это также влияет на долгосрочную позицию экосистемы L2. Когда у L1 появятся собственные ZK-возможности, роль L2 эволюционирует — от «решения для безопасного масштабирования» к «специализированной среде выполнения». Какие L2 найдут свое место в этой новой архитектуре, станет самым интересным эволюционным процессом ближайших лет.

Самое важное — это то, что L1 zkEVM демонстрирует уникальную способность Ethereum: одновременно продвигать восемь взаимозависимых технических линий, каждая из которых — это проект многолетней длительности, сохраняя децентрализованный способ координации. Это и есть истинная инженерная амбиция.

Эволюция через спецификацию: от ориентированности на Rollup к проверяемым вычислениям

Эволюция нарратива Ethereum — от «модели, ориентированной на Rollup» 2021 года до Strawmap 2026 — отражает четкую траекторию: масштабирование не может зависеть только от L2, L1 и L2 должны развиваться совместно и синергично.

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

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