zkEVM: EVM-совместимые ZK

ZK-Rollups обещают мгновенную финализацию вместо 7-дневного ожидания. Но есть проблема: EVM создавалась в 2014 году для исполнения смарт-контрактов, а не для генерации криптографических доказательств. KECCAK256 - стандартный хеш Ethereum - в 600 раз дороже для ZK-proving, чем специализированная альтернатива. 256-битные числа не влезают в математические поля ZK-систем. Dynamic jumps ломают предсказуемость circuit. Виталик Бутерин предложил четыре типа zkEVM - от полной копии Ethereum (proving за часы) до собственного языка Cairo (proving за минуты). Как инженеры балансируют между совместимостью и скоростью, и почему этот выбор определяет архитектуру всех L2-решений?

• **Scroll** (Type 2) запустился в mainnet с полной EVM-эквивалентностью - Solidity-контракты деплоятся без изменений, но proving занимает 10-30 минут на batch из 1000 транзакций
• **zkSync Era** (Type 4) обрабатывает миллионы транзакций через собственный компилятор zksolc (Solidity → Yul → IR), жертвуя совместимостью inline assembly ради proving за минуты
• **StarkNet** (Type 4) создал язык Cairo с нуля для ZK-proving, а SHARP (Shared Prover) агрегирует proofs от разных приложений, снизив стоимость proving на 90%

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

• ZK Rollups: zkSync, StarkNet
• zk-SNARK: From Theory to Practice

Types 1-4: спектр совместимости Виталика

Мы уже знаем, что ZK-Rollups генерируют validity proofs для транзакций. Но ключевой вопрос: **что именно доказывается?** Можно доказывать исполнение EVM-байткода один к одному с Ethereum - или компилировать Solidity в совершенно другое представление и доказывать уже его. В 2022 году Виталик Бутерин предложил классификацию из **четырёх типов zkEVM**, которая стала стандартом индустрии. Каждый тип - это точка на спектре между **полной совместимостью** с Ethereum и **максимальной скоростью proving**.

Чтобы понять, почему нужны разные типы, вспомним аналогию. Представьте, что вам нужно перевести книгу с русского на китайский, но при этом **доказать**, что перевод верный. **Type 1** - вы сохраняете оригинальный текст, шрифт, вёрстку и доказываете пословный перевод. Невероятно точно, но мучительно медленно. **Type 4** - вы пересказываете смысл на китайском своими словами. Быстро, но оригинал не восстановить.

Спектр типов - не вопрос «какой лучше». Это инженерный trade-off. **Type 1** (Taiko) нужен тем, кто хочет, чтобы L2 был *точной копией* Ethereum - полезно для Ethereum-like цепей, которые хотят наследовать безопасность L1 без любых компромиссов. **Type 2** (Scroll, Polygon zkEVM) - сладкое место для DeFi-протоколов: контракты мигрируют без изменений, а proving достаточно быстрый для продакшна.

**Type 4** - радикальный подход. zkSync Era компилирует Solidity через цепочку `Solidity → Yul → zkSync IR` с помощью компилятора **zksolc**. Стандартный Solidity-код работает, но байткод принципиально отличается от EVM. StarkNet пошёл ещё дальше - создал собственный язык **Cairo**, спроектированный для ZK-proving с нуля. Cairo 2.0 синтаксически напоминает Rust (с ownership и borrow checker), но требует от разработчиков изучения нового языка. Зато каждая операция Cairo эффективно доказуема - нет «тяжёлых» opcodes.

**Type 2.5 - тонкая, но важная разница.** В EVM каждый opcode имеет фиксированную gas cost (например, ADD = 3 gas, SSTORE = 20,000 gas). В zkEVM Type 2 gas costs идентичны Ethereum. Но в Type 2.5 они изменены, чтобы отражать **реальную стоимость proving** опкода. KECCAK256 в ZK-цепи в 600 раз дороже для proving, чем ADD. Если оставить gas costs как в Ethereum, злоумышленник может написать контракт, забивающий batch тысячами KECCAK-вызовов - proving будет непропорционально дорогим. Type 2.5 повышает gas cost KECCAK в ZK-контексте, защищая prover от DoS-атаки.

Proving EVM: почему это так сложно

Теперь мы понимаем спектр типов zkEVM. Но почему вообще нужны компромиссы? Почему нельзя просто взять EVM и «обернуть» его в ZK-proof? Ответ: **EVM спроектирована для исполнения, а не для доказательства**. Когда Виталик создавал EVM в 2014 году, он думал о гибкости Turing-complete машины - не о том, чтобы каждый шаг можно было эффективно представить как систему полиномиальных constraints. EVM полна решений, которые для обычного исполнения нормальны, но для ZK-proving - катастрофа.

Первая проблема - **256-битная арифметика**. EVM оперирует 256-битными целыми числами (uint256). Но ZK-proof systems работают над конечными полями (finite fields), где размер элемента обычно ~254 бита (для кривой BN254) или ~255 бит (BLS12-381). Число 2^256 - 1 **не помещается** в поле. Каждая арифметическая операция EVM требует **разбиения** на несколько field-элементов и проверки переполнения, что превращает одну операцию ADD в десятки constraints.

Вторая проблема - ещё серьёзнее: **KECCAK256**. Ethereum использует эту хеш-функцию повсюду: вычисление storage slots, адреса контрактов, корни Merkle Patricia Trie. Но KECCAK256 построена на побитовых операциях (XOR, rotations, bit permutations), которые крайне неэффективны в арифметических ZK-цепях. Одна операция KECCAK256 требует ~150,000 constraints. Для сравнения, ZK-friendly хеш **Poseidon** использует только арифметические операции в поле и требует ~250 constraints - разница в **600 раз**.

Третья группа проблем - **паттерны доступа к памяти и storage**. EVM stack - это LIFO-структура глубиной 1024 элемента. EVM memory - byte-addressable, растёт динамически. Storage - key-value хранилище с 256-битными ключами и значениями. Все эти структуры требуют доказательства **каждого чтения и записи**: prover должен показать, что значение, прочитанное из storage slot X, действительно было записано туда ранее. Это создаёт огромное количество lookup constraints.

**Dynamic jumps - особенно проблематичны.** EVM opcode JUMP берёт адрес назначения из стека (динамически). В обычном исполнении это нормально - просто перейти по адресу. Но для ZK-цепи prover должен знать путь исполнения **заранее**, чтобы построить circuit. Dynamic jumps означают, что circuit должен покрывать **все возможные пути** или использовать дорогие conditional constraints. Это одна из причин, почему Type 4 zkEVM (zkSync) компилирует Solidity в другое представление - можно устранить dynamic jumps на этапе компиляции.

Circuit Constraints: opcodes становятся уравнениями

Мы разобрались, *почему* EVM сложно доказывать. Теперь посмотрим, *как* это делается на практике. Ключевая идея - подход **execution trace table** (таблица трейса исполнения). Каждый шаг выполнения EVM становится **строкой** в огромной таблице. Столбцы - программный счётчик (PC), opcode, операнды, результат, состояние стека, состояние памяти. ZK-proof доказывает: «каждая строка таблицы корректно следует из предыдущей согласно правилам EVM».

Но трейс исполнения - это только половина картины. Для доказательства корректности нужны **lookup tables** - вспомогательные таблицы, к которым основной трейс обращается. **ROM table** хранит байткод контрактов: «в позиции PC=5 байткод содержит opcode 0x01 (ADD)». **RAM table** хранит историю чтений/записей в memory и storage. **Stack table** отслеживает состояние стека после каждого шага.

Важно различать **preprocessing** (подготовку) и **online proving** (генерацию proof). Preprocessing включает: компиляция constraint system, генерация proving/verification keys, оптимизация lookup tables. Это делается **один раз** при развёртывании zkEVM. Online proving - генерация proof для конкретного batch транзакций: заполнение execution trace, вычисление witness, генерация polynomial commitments. Preprocessing может занимать часы, но его стоимость амортизируется на миллионы блоков. Online proving - это то, что происходит для каждого нового batch.

**Custom constraints - секрет оптимизации.** Разные zkEVM-проекты создают специализированные constraints для частых операций. Scroll использует «super circuits» - мега-constraint, объединяющий все подтаблицы в единую систему. Polygon zkEVM разработал «state machine» подход, где каждый opcode - отдельный автомат с минимальным числом constraints. Эти оптимизации - ноу-хау каждого проекта и одна из причин, почему proving times так отличаются между zkEVM.

Performance: бенчмарки, агрегация и путь к real-time

Мы разобрали, что доказывают zkEVM (Types 1-4), почему это сложно (256 бит, KECCAK, memory access), и как opcodes превращаются в constraints (execution trace + lookup tables). Остаётся главный вопрос: **насколько это быстро и дорого на практике?** Proving performance - не академический вопрос. От него зависит, как быстро пользователь получит финализацию, сколько будет стоить транзакция, и жизнеспособна ли вообще вся идея zkEVM.

**Proof aggregation** - ключевая стратегия снижения L1-стоимости. Вместо публикации proof для каждого batch, prover агрегирует несколько batches в **один рекурсивный proof**. Scroll публикует aggregated proof каждые ~20-60 минут, покрывающий несколько batches. zkSync Era использует многоуровневую агрегацию: chunk proofs → batch proof → final SNARK proof. StarkNet применяет **SHARP** (Shared Prover) - общий prover, который агрегирует proofs от разных приложений (StarkNet, dYdX, Sorare) в один STARK proof, затем оборачивает его в SNARK для дешёвой L1-верификации.

Полная стоимость zkEVM-транзакции складывается из трёх компонентов: 1. **L1 data posting** - публикация state diffs или calldata на L1 (после EIP-4844 - в blobs), это ~60-80% стоимости 2. **proof verification** - верификация aggregated proof на L1, ~5-15% стоимости (амортизируется на весь batch) 3. **off-chain proving** - оплата GPU-вычислений prover, ~10-25% стоимости. Bottleneck - data posting, а не proving. Поэтому EIP-4844 (proto-danksharding) с blob-транзакциями снизил стоимость L2-транзакций в 10-100 раз.

**Real-time proving** - ситуация, когда proof генерируется за время, сопоставимое с block time L2 (~1-2 секунды). Это устранит задержку между исполнением транзакции и её финализацией на L1. Несколько направлений ведут к этой цели: 1. **hardware acceleration** - FPGA и ASIC-чипы, спроектированные специально для ZK-операций (FFT, MSM, NTT), обещают 10-100x ускорение по сравнению с GPU 2. **новые proof systems** - Binius работает над binary fields (более эффективными для побитовых операций EVM), GKR использует сумм-проверки вместо commitment schemes 3. **continuation proofs** - proving начинается параллельно с исполнением, не дожидаясь завершения блока.

**Decentralized prover networks создают новые проблемы.** Если proving децентрализован, prover видит содержание транзакций до финализации - это создаёт риск MEV (Maximal Extractable Value). Prover может задерживать proof для определённых транзакций или отдавать приоритет своим. Кроме того, hardware requirements для proving высоки ($200K-$1M), что может привести к централизации, аналогичной Bitcoin-майнинговым пулам. Proof markets должны решать эти проблемы через механизмы commit-reveal, slashing и fair ordering.

**Закон Мура для ZK-proving.** С 2022 по 2025 год стоимость proving снижалась примерно в 2 раза ежегодно. Polygon zkEVM в 2023 тратил ~$0.10 на транзакцию на proving; в 2025 - ~$0.01. StarkNet перешёл на SHARP (Shared Prover), агрегирующий proofs от нескольких приложений, что снизило per-app cost на 90%. Если тренд сохранится, к 2027 году proving стоимость станет пренебрежимо малой, а основной cost driver L2-транзакций останется data posting на L1.

Итоги

• **Types 1-4** - спектр совместимости по классификации Виталика. Type 1 (Taiko) - полная эквивалентность Ethereum, proving за часы. Type 2 (Scroll, Polygon zkEVM) - EVM opcodes идентичны, внутренности оптимизированы, proving 10-30 мин. Type 2.5 - как Type 2, но gas costs отражают ZK-стоимость opcodes. Type 4 (zkSync Era, StarkNet) - другой байткод/язык, proving за минуты
• **EVM не спроектирована для ZK**: 256-битная арифметика не помещается в ~254-битные поля (ADD → 10+ constraints), KECCAK256 требует ~150,000 constraints vs ~250 у Poseidon (600x overhead), динамические jumps ломают предсказуемость circuit, паттерны memory/storage access создают массу lookup constraints
• **Opcodes → constraints** через execution trace table: каждый шаг EVM = строка с селектором opcode. ROM table верифицирует байткод, RAM table - read/write consistency для memory и storage. Типичный Ethereum-блок = 100M-500M constraints. Preprocessing (одноразовый) vs online proving (каждый batch)
• **Performance** определяется hardware (GPU → FPGA → ASIC), proof aggregation (рекурсивные proofs снижают L1 cost до 0.0003/tx) и proof systems (Binius, GKR). Bottleneck стоимости - data posting (~61%), не proving. Real-time proving (секунды) ожидается к 2026-2027 через ASIC и continuation proofs
• Возвращаясь к hook: EVM в 600 раз дороже для ZK из-за KECCAK256, но инженеры нашли выход - спектр типов zkEVM, где каждый проект выбирает свою точку баланса. Совместимость и скорость - не враги, а trade-off, и рынок решает, какой баланс оптимален для каждого use case

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

zkEVM находится на пересечении ZK-криптографии, масштабирования L2 и архитектуры EVM:

• ZK-Rollups: zkSync, StarkNet — Фундамент zkEVM: validity proofs, prover/verifier асимметрия, proof aggregation. zkEVM - это конкретная реализация proving для EVM-совместимых цепей
• zk-SNARK: глубокое погружение — Математическая основа: pairing-based криптография, polynomial commitments (KZG), Groth16/PLONK - proof systems, которые zkEVM используют для генерации и верификации proofs
• PLONK и Universal Setup — Ключевая proof system для zkEVM: universal setup (не нужна новая ceremony для каждого circuit), custom gates позволяют оптимизировать constraints для EVM opcodes
• EVM: Ethereum Virtual Machine — Архитектура, которую zkEVM доказывает: stack machine, opcodes, gas metering, storage model. Понимание EVM необходимо для понимания, почему proving сложен

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

• Type 2 zkEVM сохраняет полную EVM-совместимость, а Type 4 жертвует ей ради скорости. Если hardware для proving будет дешеветь в 2x ежегодно, исчезнет ли преимущество Type 4? Или ZK-нативный дизайн (Cairo, zkSync IR) открывает возможности, принципиально недоступные EVM?
• StarkNet создал собственный язык Cairo, требуя от разработчиков учить новый стек. Solana сделала то же с Rust вместо Solidity - и привлекла огромную экосистему. Может ли Cairo повторить этот путь, или EVM-совместимость - непреодолимый network effect?
• Decentralized prover networks обещают устранить single point of failure. Но если proving требует GPU-кластеров за $200K-$1M, не приведёт ли децентрализация к олигополии из 3-5 крупных provers - аналогично тому, как 3 mining-пула контролируют >50% хешрейта Bitcoin?

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

• crypto-34-zkp-basics