zkVM доказывает, что программа была выполнена по правилам выбранной виртуальной машины и дала заявленный результат. zkEVM решает более узкую задачу: доказывает корректность исполнения, совместимого с Ethereum Virtual Machine, включая opcodes, газ, память, хранилище и изменение состояния аккаунтов.
Обе архитектуры превращают длинное вычисление в компактное доказательство, которое verifier проверяет дешевле повторного исполнения. Разница не в силе криптографии сама по себе, а в том, какую машину описывает доказательная система и какой код можно запустить без преобразований.
Что означает VM в доказательной системе
Виртуальная машина задаёт набор инструкций и точные правила изменения состояния. Обычный процессор читает инструкцию, меняет регистры и память, затем переходит к следующему шагу. Доказуемая VM дополнительно превращает каждый шаг в математические ограничения, чтобы prover мог подтвердить правильность всей трассы исполнения.
На вход подаются программа, данные и начальное состояние. На выходе появляются результат, конечное состояние и proof. Verifier получает только необходимые публичные значения и проверяет, что существует допустимая трасса, связывающая вход с выходом. Он не обязан воспроизводить миллионы шагов.
При этом приставка zk не всегда означает, что все данные скрыты. Многие системы используют SNARK или STARK ради краткости и проверяемости, оставляя входы и результат публичными. Нулевая разглашаемость – отдельное свойство конфигурации доказательства.
Что именно доказывает zkVM
Универсальная zkVM обычно основана на собственной инструкции или на знакомой архитектуре вроде RISC-V. Разработчик компилирует программу на поддерживаемом языке в гостевой код. Prover исполняет этот код, фиксирует trace и доказывает, что каждая инструкция соответствует спецификации VM.
Публичное утверждение может звучать так: программа с данным хешем получила открытый вход X, использовала некоторый закрытый witness и вернула результат Y. Доказательство подтверждает вычисление, но не истинность исходных данных. Если в программу передали ложную цену или поддельный документ, корректная zkVM честно докажет обработку ложного входа.
Такая машина подходит не только для блокчейна. В ней можно проверять подписи, строить Merkle-деревья, обрабатывать журнал событий, запускать игровой движок или доказывать выполнение аналитического алгоритма. Цена универсальности – дополнительные инструкции, память, ввод-вывод и расходы prover.
Что именно доказывает zkEVM
zkEVM описывает правила EVM. Для rollup утверждение обычно связывает предыдущий state root, пакет транзакций и новый state root. Доказательство подтверждает, что транзакции были разобраны, opcodes выполнены, газ учтён, вызовы и возвраты обработаны, а storage изменился именно по правилам выбранной версии Ethereum.
На Ethereum verifier contract проверяет proof и принимает новое обязательство состояния L2. Он не знает смысл приложения: swap, NFT или кредит для него являются последовательностями инструкций. Безопасность ZK-rollup и его связь с публикацией данных подробнее разобраны в статье о ZK-rollups.
Термин zkEVM не гарантирует полного совпадения с Ethereum. Одни реализации стремятся доказать существующие блоки EVM без изменений, другие адаптируют opcodes, компилятор или правила газа ради более дешёвого prover. Поэтому проверять нужно конкретную спецификацию совместимости, а не одно название.
Пример различия на одной задаче
Представим программу, которая проверяет тысячу подписей и вычисляет новый баланс. В zkVM разработчик пишет обычную программу для гостевой среды. Доказательство говорит: этот бинарный код получил такие публичные обязательства и вернул новый корень после корректного исполнения инструкций VM.
В zkEVM та же логика оформляется как EVM-транзакции и смарт-контракты. Доказательство говорит: пакет транзакций корректно изменил состояние EVM от одного корня к другому. Оно включает семантику аккаунтов, calldata, storage, revert, газ и другие правила Ethereum, даже если прикладной задаче нужна только проверка подписей.
Первый путь может быть эффективнее для специализированного вычисления. Второй удобнее, если уже есть Solidity-контракты, кошельки, RPC и инструменты Ethereum. Выбор определяется тем, что важнее – свобода программы или совместимость с существующей экосистемой.
Из каких частей состоит proof pipeline
Гостевая программа. Код, результат которого требуется доказать. В zkEVM этим кодом фактически являются транзакции и контракты EVM.
Witness. Данные, необходимые для исполнения: значения памяти, ветви Merkle-деревьев, подписи и другие промежуточные элементы. Часть может оставаться закрытой.
Execution trace. Таблица шагов машины. Она показывает значения регистров, opcodes, обращения к памяти и другие переходы.
Arithmetization. Перевод правил VM в полиномиальные или иные алгебраические ограничения. Они запрещают prover предъявить недопустимый шаг.
Prover. Тяжёлая система, которая строит proof по trace. Она может использовать GPU, распределённые узлы и рекурсию.
Verifier. Компактный алгоритм или смарт-контракт, проверяющий proof и публичные входы. Его низкая стоимость и однозначность позволяют вынести проверку на L1.
Публичные входы важнее названия
Доказательство всегда относится к конкретному утверждению. Если verifier получил только хеш программы и число на выходе, он не подтверждает происхождение входных данных. Если rollup не связал proof с правильным предыдущим state root, chain ID и данными пакета, математически верное доказательство может подтверждать не тот контекст.
Для zkEVM обычно важны старый и новый корни состояния, обязательство данных, хеши блоков и параметры цепочки. Для zkVM набор определяет приложение. Разработчик должен однозначно сериализовать входы, зафиксировать версию гостевой программы и исключить повторное использование доказательства в другой сети.
Поэтому аудит verifier и обвязки не менее важен, чем аудит VM. Ошибка в контракте, выборе verification key или привязке публичных входов способна обойти корректную криптографию.
Совместимость и производительность
zkEVM наследует сложность EVM, которая проектировалась не для ZK-доказательств. Keccak, динамическая память, состояние аккаунтов и некоторые opcodes дорого представлять в ограничениях. Зато разработчик получает Solidity, привычную модель аккаунтов и возможность переносить приложения с меньшими изменениями.
zkVM может выбрать более дружественные доказательствам хеши, инструкцию и модель памяти. Но существующий EVM-контракт нельзя просто объявить гостевой программой: понадобится компиляция, эмуляция или переписывание логики. Каждая прослойка добавляет отличия и поверхность ошибок.
Реальная скорость зависит не только от типа VM. Важны proof system, размер поля, lookup-таблицы, рекурсия, параллелизм, аппаратное ускорение и доля операций ввода-вывода. Сравнивать заявления «быстрее» без одной программы, одинакового оборудования и одного уровня безопасности бессмысленно.
Рекурсия и агрегация
Большое вычисление можно разделить на сегменты, доказать каждый отдельно, а затем создать proof, проверяющий другие proofs. Это называется рекурсией. Она позволяет распараллелить работу и получить один компактный итог для L1.
zkVM часто использует рекурсию, чтобы объединить шаги длинной программы. zkEVM агрегирует доказательства блоков или нескольких компонентов: CPU, память, storage и подписи. Итоговый verifier видит один proof, хотя внутри была иерархия.
Рекурсия не делает исходные данные доступными. Она подтверждает корректность вложенных утверждений. Для rollup всё равно нужен механизм data availability, иначе независимый участник не сможет восстановить состояние. Отличие расчёта от хранения данных полезно сопоставить с обзором модульной Celestia.
Где встречаются обе архитектуры
zkEVM чаще используется в Ethereum L2 и исследованиях доказательства самого L1. Примеры разных компромиссов можно увидеть в обзоре Linea и обзоре Scroll. Их архитектуры нельзя оценивать только по совместимости: важны данные, sequencer, мост и upgrade-права.
zkVM применяется как универсальный вычислительный сопроцессор, основа доказуемой цепочки, средство проверки сторонней программы или компонент rollup. Проект может запустить EVM внутри zkVM, но тогда появляются два слоя семантики: инструкции внешней машины и эмулируемые правила EVM.
Граница бывает размытой. Некоторые zkEVM состоят из нескольких специализированных машин, а универсальная zkVM получает ускорители для криптографии. Название помогает понять цель, но окончательный ответ даёт спецификация: какой байткод принимается и какое состояние связывают публичные входы.
Основные риски
- Ошибка ограничений. Circuit может разрешить переход, которого нет в спецификации VM.
- Ошибка verifier. Контракт способен принять некорректный proof или неправильные публичные входы.
- Несовпадение версий. Prover, verifier и гостевая программа могут использовать разные правила.
- Централизация prover. Высокие требования к оборудованию ограничивают число производителей доказательств.
- Trusted setup. Некоторые схемы зависят от корректного проведения церемонии параметров.
- Недоступность данных. Proof не заменяет данные, необходимые для восстановления состояния.
- Ложная приватность. Succinct proof может не скрывать ни транзакции, ни результат.
- Сложная обвязка. Мосты, sequencer, оракулы и admin-ключи находятся за пределами самой VM.
Итог
zkVM доказывает исполнение программы по правилам универсальной или специализированной виртуальной машины. zkEVM доказывает переход состояния по правилам EVM и поэтому ориентирована на совместимость с Ethereum-контрактами и инфраструктурой. Ни одна метка не сообщает автоматически о приватности, доступности данных или децентрализации prover. Чтобы понять реальную гарантию, нужно проверить спецификацию VM, публичные входы, версию программы, verifier и систему, которая подаёт исходные данные.
