Короткий ответ: zkVM доказывает корректное выполнение программы на виртуальной машине, а специализированная схема строится вокруг конкретного вычисления или узкого семейства операций. Первый подход удобен, когда важны привычные языки и гибкость; второй может дать более компактное или быстрое доказательство для фиксированной задачи. Ни один вариант не становится лучше без учёта стоимости разработки, доказательства и проверки.
Слово «доказательство» иногда создаёт впечатление, что все приватные входы скрыты. На практике схема может лишь подтверждать правильность вычисления и публиковать часть входных данных или результата. Нулевая разглашаемость зависит от конструкции и выбранных публичных входов. Поэтому сравнивать нужно не названия технологий, а точное утверждение, которое проверяет контракт или приложение.
Что именно делает zkVM
В zkVM разработчик описывает вычисление как программу для гостевой виртуальной машины. Система исполняет её и строит доказательство того, что программа прошла от заданного входа к опубликованному результату без нарушения правил исполнения. Проверяющий может проверить короткое криптографическое свидетельство, не повторяя всю исходную работу. Например, RISC Zero документирует модель, где гостевой код компилируется в ELF, затем исполняется, а receipt связывается с идентификатором ожидаемой программы и публичным journal.
Термин «универсальная» здесь относительный: машина поддерживает широкий набор инструкций и модель программы, но остаётся ограниченной своей архитектурой, доступными системными вызовами, библиотеками и ресурсами доказателя. Программа, которая хорошо работает на обычном сервере, может быть дорогой в доказательстве из-за большого числа шагов, неподдерживаемой операции или неудачного паттерна памяти.
Преимущество такой модели – возможность переиспользовать привычный язык, тесты и части экосистемы. Разработчик может выразить сложную проверку как последовательность общих вычислительных шагов. Это упрощает изменение бизнес-логики: правило можно уточнить в коде, не проектируя новую арифметическую схему с нуля. Но компиляция сама по себе не гарантирует безопасность: важно зафиксировать версию бинарного образа, публичные входы, ограничения среды исполнения и то, кому доверено собирать проверяемую программу.
Что означает специализированная схема
Специализированная proof-схема заранее описывает математические ограничения для конкретного отношения. Она не обязана моделировать полную виртуальную машину. Если приложению нужно доказать, что подпись верна, сумма входов равна сумме выходов или путь входит в дерево, схема может кодировать именно эти свойства. Это часто позволяет убрать общее исполнение и оптимизировать набор операций под задачу.
Узкая схема требует аккуратной спецификации. Нужно установить, какие значения являются входами, что остаётся скрытым, как кодируются числа и строки, какие диапазоны допустимы и как предотвращается неоднозначность. Если приложение изменит правило или добавит новое поле, схему и связанные тесты, возможно, придётся менять. Ошибка в ограничении может привести к тому, что доказательство будет подтверждать более слабое утверждение, чем ожидает пользователь.
Некоторые специализированные системы используют схемы SNARK с настройкой параметров, некоторые – прозрачные STARK или иные конструкции. Нельзя обобщать доверительную модель только по слову SNARK или STARK: смотрите конкретную криптографию, setup, soundness-предположения, реализацию и аудит. Аналогично наличие «ZK» не говорит, скрыты ли суммы, адреса или сама программа.
Сравнение по жизненному циклу
При выборе полезно пройти путь от разработки до проверки. Для zkVM главный вопрос – укладывается ли нужная программа в стоимость доказательства и насколько удобно сопровождать её обновления. Для специализированной схемы – точно ли сформулировано отношение, кто проверял ограничения и как выглядит новый цикл компиляции или trusted setup, если он есть. На стороне верификатора оцените размер доказательства, вычислительную стоимость, формат публичных входов и цену интеграции в конкретную сеть.
Обновляемость тоже устроена по-разному. У виртуальной машины смена приложения может выражаться в новом program ID или hash бинарника. У специализированной схемы обновление может менять арифметические ограничения, ключи проверки и интерфейс контракта. Пользователь должен понимать, какая именно версия кода относится к конкретному доказательству. Система управления релизами и проверяемая сборка могут быть не менее важны, чем теоретическая пропускная способность схемы.
- Гибкость: общая VM обычно проще переносит новые ветви логики, тогда как узкая схема сильна при стабильном наборе операций.
- Стоимость доказательства: зависит от программы, реализации, аппаратного обеспечения, рекурсивной агрегации и используемых ускорителей, а не только от категории решения.
- Аудит: в VM проверяют виртуальную машину, компилятор, guest-код и ограничения; в специализированной системе дополнительно анализируют каждое ограничение и процедуру подготовки ключей.
- Проверка: контракт должен правильно связать доказательство с ожидаемой программой, публичными входами и состоянием приложения.
Как не перепутать zkVM и zkEVM
zkVM и zkEVM пересекаются, но термин zkEVM обычно указывает на совместимость с EVM или доказательство исполнения EVM-инструкций. zkVM может быть построена вокруг RISC-V или другой архитектуры и исполнять произвольную поддерживаемую программу, которая вовсе не является Ethereum-контрактом. Разницу по объекту доказательства полезно уточнить в материале о zkVM и zkEVM.
Также zkVM не равна одному протоколу доказательства. Внутри системы могут сочетаться трасса исполнения, арифметические ограничения, криптографические примитивы и рекурсивная агрегация. Инженерный выбор касается всей конструкции и её реализаций. Отдельно изучайте, какие операции ускоряются специализированными precompile: ускорение конкретного хеша не превращает всю программу в специализированную схему и не переносится автоматически на любой алгоритм.
Если задача – пакетировать вычисления для rollup, zkVM может дать удобный общий слой, но задержка генерации и цена доказательства становятся важны для частоты публикаций. Подходы к объединению результатов разобраны в статье об агрегации и рекурсии ZK-доказательств. Это отдельный уровень системы, и его нельзя путать с тем, была ли исходная программа универсальной.
Практический порядок выбора
- Сформулируйте утверждение обычными словами и перечислите данные, которые проверяющий вправе увидеть.
- Определите, меняется ли логика часто и сколько существующего кода можно переиспользовать.
- Соберите контрольные входы, включая крайние случаи, некорректные значения и попытки обойти ограничения.
- Сравните не только скорость верификации, но и стоимость генерации доказательства, требуемое оборудование, время сборки и эксплуатационные расходы.
- Проверьте код verifier, идентификатор программы или ключ проверки и процедуру обновления до запуска с реальными активами.
Публикуемые бенчмарки требуют осторожности: результаты зависят от версии системы, типа программы, аппаратного ускорения, размера входов и настройки доказателя. Сравнивайте одинаковые задачи на одинаковых условиях. Метрика «доказательство за секунды» может скрывать дорогую предварительную обработку, ограниченный набор входов или централизованный сервис генерации.
Для финансового приложения дополнительно анализируйте, что происходит при отказе prover, несовпадении версий и перегрузке сети. Если доказательство формируется внешним оператором, выясните, можно ли проверить его самостоятельно и что станет с заявкой при длительной задержке. Принцип fault proof показывает, что система оспаривания тоже имеет собственные предположения, поэтому полезен разбор оспаривания состояния в optimistic rollup.
Итог
zkVM даёт общую программную модель для проверяемого исполнения, а специализированная схема напрямую кодирует узкое вычислительное утверждение. Первая облегчает гибкую разработку; вторая может быть эффективной при стабильной задаче и аккуратной спецификации. Сравнивайте полный жизненный цикл: корректность утверждения, производительность доказателя, цену проверки, приватность входов, аудит и обновление параметров. Для любой конструкции критично проверить именно тот бинарный образ или набор ограничений, к которому относится доказательство.
