Validity proof (дословно «доказательство корректности») — это криптографическое доказательство того, что переход состояния в блокчейне или протоколе выполнен по правилам, заложенным в его алгоритм.
В контексте ZK-rollup’ов validity proof подтверждает, что:
- из старого состояния (state root) и списка транзакций
- был получен новый state root
- строго в соответствии с логикой протокола (смарт-контрактов, правил исполнения и т.п.).
Базовая идея: L1 не пересчитывает все транзакции, а лишь проверяет короткое proof-сообщение, что «всё посчитано честно».
Как работает validity proof в rollup’ах
На примере L2-rollup’а поверх Ethereum:
- Оператор (sequencer / prover) собирает транзакции пользователей, исполняет их на L2 и получает новое состояние.
- Затем он строит криптографическое доказательство (validity proof), что:
- функция перехода состояния f(state, txs) применена корректно;
- все правила протокола соблюдены (балансы не уходят в минус, лимиты не нарушены, подписи валидны и т.п.).
- На L1 публикуются:
- сильно сжатые данные о транзакциях/изменениях (или ссылки на них);
- validity proof;
- новый корень состояния.
- Верификатор на L1 (смарт-контракт) проверяет proof:
- если он валиден — новый state root принимается как корректный;
- если нет — транзакция отклоняется.
Так rollup «доказывает» Ethereum, что его внутренние вычисления верны, не заставляя L1 повторять их.
Связь с ZK-доказательствами
На практике validity proof часто реализуется через ZK-доказательства (SNARK/STARK и другие схемы):
- Zero-knowledge означает, что proof:
- подтверждает корректность вычисления;
- но не раскрывает лишних деталей о входных данных (при необходимости).
- В контексте rollup’ов zero-knowledge полезен, но не всегда обязателен:
- главное — корректность перехода состояния (validity),
- приватность — опциональный бонус.
Поэтому:
- любой ZK-proof, который доказывает корректность перехода состояния, можно рассматривать как validity proof;
- но не каждый validity proof обязательно обладает свойством полной zero-knowledge-приватности.
Validity proof vs fraud proof
В масштабировании через L2-rollup’ы принято противопоставлять два подхода к проверке корректности:
| Характеристика | Validity proof (ZK / validity rollup) | Fraud proof (optimistic rollup) |
|---|---|---|
| Кто доказывает | Оператор rollup доказывает, что состояние *верно* | Наблюдатель доказывает, что опубликованное состояние *неверно* |
| Что проверяет L1 | Краткое криптодоказательство корректности | Потенциальные спорные участки при challenge |
| Когда появляется proof | Для каждого батча (или группы батчей) | Только при оспаривании состояния |
| Финализация на L1 | После валидации proof | После окончания challenge-периода |
| Требования к вычислениям | Высокая нагрузка на prover | Высокая нагрузка лишь при спорах |
Ключевая разница:
- при fraud proof модель «оптимистична»: состояние считается верным, пока его *кто-то* не оспорит;
- при validity proof состояние принимается только после активной криптографической проверки, что оно верно.
Где используются validity proofs
Помимо ZK-rollup’ов validity proof применяются в ряде сценариев:
- Другие виды rollup’ов.
Некоторые L2/L3-решения используют validity proofs для частичных задач (например, агрегированная проверка подписи или состояния).
- Лёгкие клиенты (light clients).
Вместо скачивания всех блоков клиент может проверять короткие доказательства корректности цепочки.
- Бриджи и кросс-чейн-коммуникация.
Мост может принять на одной цепочке proof того, что в другой цепочке:
- действительно произошло определённое событие;
- состояние действительно перешло в нужное значение.
- Off-chain-вычисления и oracle-схемы.
Дорогие вычисления выполняются вне цепи, а на L1 попадает только validity proof правильности результата.
Ограничения и риски validity proof
Несмотря на сильные гарантии, validity proofs не являются «серебряной пулей»:
- Сложность реализации.
Нужно:
- формализовать логику протокола в виде арифметических схем/контекстов для prover’а;
- реализовать prover и verifier для выбранной криптосхемы;
- обеспечить корректность всех преобразований.
- Зависимость от криптографии.
Безопасность опирается на:
- устойчивость используемой схемы (SNARK/STARK и др.);
- корректность trusted setup (если он есть);
- отсутствие уязвимостей в реализации.
- Стоимость генерации proof’ов.
Для больших батчей или сложных программ построение proof’а может быть ресурсоёмким: нужны мощные сервера или специализированное железо.
- Риски ошибок в схемах.
Если при описании правил протокола допущена логическая ошибка, prover будет честно доказывать *не те* правила, которые ожидали авторы.
Важно: validity proof решает задачу «правильно ли посчитано по заданным правилам», но не проверяет, хороши ли сами правила (экономика, токеномика, отсутствие бэкдоров и т.п.).
Как читать и интерпретировать validity proof пользователю
Обычный пользователь не взаимодействует напрямую с validity proof. Но полезно понимать:
- если rollup заявляет, что он validity/ZK-rollup, это значит:
- состояние L2 не принимается на L1 без криптодоказательства;
- вывод средств после публикации proof-батча не зависит от риска «никто не подал спора».
- наличие validity proof не отменяет:
- рисков доступности данных;
- рисков централизации sequencer’а;
- смарт-контрактных и экономических рисков поверх rollup’а.
Для практики важно не только наличие validity proofs, но и:
- насколько зрелы prover/verifier-реализации;
- есть ли независимые аудиты;
- какие DA-модели используются (rollup vs validium).