zkEVM (zero-knowledge Ethereum Virtual Machine) — это версия виртуальной машины Ethereum, адаптированная для работы с доказательствами с нулевым разглашением (validity proofs) и при этом максимально совместимая с существующей экосистемой EVM: смарт-контрактами, тулчейном, стандартами токенов.
Идея zkEVM — позволить ZK-rollup’у (ZK-rollup) исполнять обычные EVM-контракты, а на L1 (Ethereum) публиковать только краткое криптографическое доказательство корректности вычислений, а не сами вычисления.
Зачем вообще нужен zkEVM
Классическая EVM создавалась без учёта ZK-доказательств. Для ZK-rollup’ов это создаёт две большие проблемы:
- Неподходящая «математика» для доказательств.
EVM оперирует 256-битными словами, в то время как zk-схемы естественно работают над простыми полями. Появляются дополнительные проверки диапазонов и вспомогательные ограничения, что «раздувает» ZK-цепочки.
- Сложные и разнородные операции.
Стековая архитектура, хранилище, память, precompile-контракты, KECCAK, подписи, калл-стек — всё это тяжело и дорого аккуратно отразить в ZK-цепях.
zkEVM — попытка «научить» виртуальную машину Ethereum быть дружелюбной к ZK-доказательствам, не ломая при этом всё, что уже есть в экосистеме:
- оставить разработчикам Solidity и знакомый тулчейн;
- но внутри реализовать VM и окружение так, чтобы их было можно эффективно «запихнуть» в zk-схему.
Классификация zkEVM по Виталику Бутерину
В 2022 году Виталик Бутерин предложил классификацию zkEVM по степени совместимости с Ethereum и EVM. Она описывает спектр от максимальной совместимости (но дорогих доказательств) до максимальной эффективности (но с жертвами в совместимости).
| Тип zkEVM | Уровень совместимости | Ключевая идея и особенности |
|---|---|---|
| Type 1 | Полная эквивалентность Ethereum | ZK-доказательства строятся для *настоящего* Ethereum: те же блоки, те же правила, те же клиенты. Никаких изменений протокола — идеально для верификации самих блоков Ethereum, но очень дорого по вычислениям. |
| Type 2 | Полная эквивалентность EVM | Воссоздаётся поведение EVM на уровне байткода, но без строгого требования совпадать с *каждой* деталью Ethereum (хэштри, формат блоков и т.п.). Совместимость с кодом и тулчейном близка к 100 %, но доказательства всё ещё тяжёлые. |
| Type 2.5 | EVM-equivalent, но с иными газ-костами | EVM сохраняется, но некоторые операции получают другие газ-косты (например, «дорогие» опкоды и precompile). Это ускоряет построение доказательств, но ломает часть приложений, которые завязаны на конкретные затраты газа. |
| Type 3 | Почти EVM-equivalent | Разрешаются изменения в деталях EVM (хранилище, precompile, часть опкодов), чтобы упростить ZK-схемы и ускорить prover. Большинство dApp работают из коробки, но совместимость уже не идеальна. |
| Type 4 | Совместимость на уровне исходного кода | Контракты на Solidity/Vyper компилируются «сверху вниз» в ZK-friendly формат. Байткод EVM может не поддерживаться напрямую. Это самый быстрый и простой путь к zk-rollup’у, но и самый «далёкий» от оригинальной EVM. |
Примеры проектов и их место в спектре
Конкретный rollup со временем может «мигрировать» по шкале, но условно можно привести следующие примеры:
- Polygon zkEVM, Linea, Scroll — стремятся к высоким уровням совместимости (Type 2–3): почти EVM-equivalent, с отдельными допущениями ради производительности.
- zkSync Era — ближе к Type 4: делает упор на компиляцию кода и ZK-эффективность, а не на байткод-эквивалентность.
- Taiko и другие проекты нового поколения — публично заявляют цель достичь более высокой EVM-эквивалентности (Type 1–2) при приемлемых затратах на доказательства.
Важно помнить:
- классификация — не жёсткий стандарт, а инженерный язык для описания компромиссов;
- один и тот же проект может эволюционировать: например, идти от Type 3 к Type 2 по мере оптимизации proving-системы и реализации.
Архитектура zkEVM-rollup’а
Типичный zkEVM-rollup над Ethereum включает несколько ключевых компонентов:
- Sequencer.
Собирает транзакции пользователей, сортирует их и исполняет на уровне L2-цепочки с использованием zkEVM.
- zkEVM-исполнитель.
Реализует правила EVM (с поправкой на тип zkEVM), ведёт состояние аккаунтов и хранилища, считает газ и события.
- Prover.
По результатам исполнения строит validity proof: компактное ZK-доказательство того, что переход состояния корректен.
- Контракт rollup’а на L1.
Принимает:
- данные о транзакциях или сжатые обновления состояния;
- validity proof и новый корень состояния L2.
Проверяет proof и обновляет свою запись о состоянии rollup’а.
- Мосты и менеджер выводов.
Отвечают за депозиты/выводы активов между L1 и L2. После того как соответствующий proof принят на L1, активы можно безопасно считать доступными к выводу.
zkEVM vs «обычные» ZK-rollup’ы
До появления zkEVM ZK-rollup’ы в основном:
- поддерживали ограниченный набор операций (простые переводы токенов, обмены по фиксированным правилам);
- требовали специального кода под конкретный rollup (своё API, свои ограничения, ограниченный набор логики).
С появлением zkEVM:
- rollup становится общего назначения: можно запускать любые EVM-dApp (DeFi, NFT, игры, инфраструктуру);
- reuse Ethereum-стека:
- язык Solidity;
- привычные фреймворки и тестовые окружения;
- привычные кошельки и RPC-инструменты;
- появляется возможность мигрировать существующие приложения из L1 или других EVM-совместимых сетей без переписывания с нуля.
Именно поэтому zkEVM часто называют «связывающим звеном» между миром ZK-доказательств и экосистемой Ethereum.
Компромисс: совместимость vs эффективность доказательств
Главный инженерный вопрос при проектировании zkEVM:
Сколько совместимости с «чистой» EVM мы готовы сохранить, и сколько за это готовы заплатить в виде тяжёлых доказательств?
- Полная эквивалентность EVM и Ethereum (Type 1–2):
- плюс: максимальная совместимость с кодом, тулчейном, безопасностью и моделями аудита;
- минус: огромные ZK-цепочки, долгие и дорогие prover’ы, сложная децентрализация proving-инфраструктуры.
- «Адаптированная» EVM (Type 3–4):
- плюс: более быстрые и дешёвые доказательства, легче выйти в прод и децентрализоваться;
- минус: несовместимость с частью приложений и инструментов, необходимость адаптации и аудита под новую среду.
Часто решения принимают гибридный путь:
- сохраняют совместимость с уровня Solidity/ABI/стандарты токенов;
- но меняют детали байткода, хранилища, gas-костов и окружения, чтобы сделать ZK-схемы проще и короче.
zkEVM и роль в L2-экосистеме Ethereum
В контексте Layer 2 над Ethereum zkEVM-rollup’ы:
- конкурируют с optimistic-rollup’ами (см. сравнение optimistic vs ZK);
- предлагают:
- быстрый и «жёсткий» вывод (после валидации proof’а на L1);
- сильные гарантии корректности состояния;
- но требуют более сложной криптографической и инфраструктурной базы.
В целом:
- optimistic-rollup проще реализовать и проще сделать EVM-эквивалентным, но UX вывода завязан на challenge-период и быстрые мосты;
- zkEVM-rollup сложнее и дороже в реализации, но в перспективе может дать:
- лучшее сочетание скорости и безопасности;
- дополнительные сценарии (приватность, off-chain-вычисления, компактные light-клиенты).
Практическое значение zkEVM для разработчиков и пользователей
Для разработчика dApp zkEVM означает:
- возможность писать на привычном стеке (Solidity, EVM-tooling);
- запускать dApp на сетях с низкими комиссиями и быстрым подтверждением;
- потенциально получать больше пользователей за счёт лучшего UX (дёшево и быстро, но с безопасностью Ethereum L1).
Важно:
- проверять, к какому типу zkEVM ближе та или иная сеть;
- понимать, какие ограничения накладывает выбранная реализация (поддержка опкодов, gas-модель, особенности хранилища).
Для пользователя zkEVM-сетей:
- внешний UX похож на другие EVM-совместимые сети:
- тот же кошелёк;
- те же dApp и адреса контрактов (часто);
- но важно помнить про:
- риски мостов между L1 и L2;
- централизацию sequencer’а и prover’а;
- отличия в моделях безопасности (rollup vs validium и др.) — см. data availability.
FAQ по zkEVM
Что отличает zkEVM от обычной EVM? Обе исполняют один и тот же код смарт-контрактов, но zkEVM ещё и «обёрнута» в ZK-схему: каждое изменение состояния может быть снабжено validity proof, который проверяется на L1. Обычная EVM такой «внешней» криптографической проверки не требует — корректность обеспечивается консенсусом и повторным исполнением.
Любой ZK-rollup — это zkEVM? Нет. Ранние ZK-rollup’ы часто поддерживали только простые операции (переводы, обмены по фиксированным правилам). zkEVM — это именно попытка сделать общего назначения ZK-rollup, способный исполнять широкий спектр EVM-dApp.
Почему до сих пор нет «идеального» Type 1 zkEVM в проде? Потому что это крайне тяжёлая инженерная задача: нужно отразить *всю* сложность Ethereum (клиент, блоки, хранилище, opcodes) в ZK-схемах без упрощений, а затем сделать prover достаточно быстрым и дешёвым для массового использования и децентрализации.
Может ли одна и та же сеть сменить тип zkEVM? Да. Проекты могут запускаться как более «лёгкий» Type 3–4, а затем, по мере оптимизации proving-стека, двигаться к большей совместимости (Type 2 и выше), не ломая экосистему.
Какой подход «победит» — optimistic или zkEVM? Скорее всего, оба будут сосуществовать. Optimistic-rollup останутся важными благодаря зрелости и простоте, а zkEVM-сети займут ниши, где критичны быстрые выводы, повышенные требования к безопасности и/или специфические ZK-сценарии.