ГЛАВНАЯ / ИНСТРУКЦИИ / VALIDITY PROOF И FRAUD PROOF: ДВА СПОСОБА ПРОВЕРЯТЬ СОСТОЯНИЕ ROLLUP
Validity proof и fraud proof: два способа проверять состояние rollup
Оба подхода обосновывают переход состояния, но устроены по-разному. Validity proof предъявляет доказательство, которое контракт проверяет по правилам схемы; fraud или fault proof участвует в разрешении спора о заявленном результате. Термины и детали зависят от сети, а доступность входных данных остаётся отдельной частью модели безопасности.
Verifier проверяет доказательство перехода
В validity-схеме оператор формирует криптографическое доказательство того, что заявленный переход соответствует программе или правилам. Settlement-контракт проверяет proof и обновляет commitment только при выполнении условий. Установите, какой statement доказывается, какая схема или ключ проверки применяется и какие контракты фиксируют результат.
Доказательство не означает, что транзакции доступны в читаемом виде или хранятся бессрочно. Для восстановления состояния могут требоваться данные состояния или отдельный поддерживаемый способ получения. Корректность вычисления и возможность узла продолжить работу – разные гарантии.
- зафиксировать сеть и конкретный блок, а не только имя проекта;
- сопоставить термин интерфейса с определением протокола;
- сохранить L1-запись и источник L2-данных.
Спор о заявленном результате проходит по правилам сети
В optimistic-модели состояние может считаться приемлемым, если в предусмотренный период никто не доказал ошибку. Участник с необходимыми данными может оспорить переход; протокол сужает спор до проверяемого шага или применяет другую схему разрешения. Проект может называть механизм fraud proof, fault proof, challenge или dispute game – важно читать конкретную спецификацию.
Проверьте допуск участников, таймеры, доступность входов и возможность своевременно начать спор. Не считайте любой объект с названием proof завершённой процедурой. Установите, кто вправе открыть игру, присоединиться к ней и какое состояние контракта считается окончательным.
- проверить адрес контракта и событие публикации;
- отличить commitment от payload или завершённого proof;
- учесть версию и конфигурацию сети на нужной высоте.
| Вопрос | Validity proof | Fraud/fault proof |
|---|---|---|
| Что предъявляется? | Proof, удовлетворяющий правилам verifier | Заявление и разрешение конкретного спора |
| Когда проверяют? | При верификации proof | При возникновении оспаривания |
| Роль участника | Проверить verifier и входы | Выявить и вовремя оспорить ошибку |
| Нужна ли DA? | Да, для восстановления или доступа к состоянию | Да, для воспроизведения перехода и спора |
Proof не является копией истории транзакций
Доказательство отвечает на формально ограниченный вопрос о вычислении. Данные, по которым сторонний узел восстановит balances и обработает следующие блоки, могут публиковаться отдельно – в calldata, blobs или через внешний DA. Optimistic-модели также требуют доступных входов для независимого воспроизведения заявленного исполнения.
Проверяйте, что именно гарантирует verifier и откуда узел получает входы. DA-комитет, blob-хранение и публикация в calldata создают разные предположения. Успешная проверка proof не превращает внешний источник в Ethereum и не подтверждает бессрочное архивирование.
Статус proof не всегда означает финальность выхода
Запишите номер L2-блока, roots до и после, L1-транзакцию публикации, контракт, статус proof/dispute и временные параметры. Слова pending, proven, challenged, resolved и finalized могут иметь особые значения в конкретном проекте. Сопоставьте показания обозревателя с состоянием L1-контракта.
Для вывода проверьте используемый bridge, proof включения сообщения, maturity или challenge interval и уровень финальности родительской цепи. Название доказательства не гарантирует мгновенного вывода, ликвидности или отсутствия административных полномочий.
Частые вопросы
Validity proof решает DA?
Нет. Оно доказывает свойство исполнения, а данные получают отдельным способом.
Fraud proof проверяется для каждого блока?
Обычно это механизм оспаривания утверждения, а не отдельный proof для каждого блока.
Отсутствие спора означает математическое доказательство?
Значение зависит от модели сети; само по себе оно не тождественно validity proof.
Fraud proof и fault proof всегда разные?
Термины могут быть близки, но определение нужно сверять со спецификацией.
Что проверить перед выводом?
Сеть, мост, статус proof/dispute и правила финализации конкретного сообщения.
Чек-лист: validity proof и fraud proof: два способа проверять состояние rollup
- модель rollup определена;
- адрес verifier или dispute-контракта установлен;
- участники и таймеры понятны;
- входные данные доступны;
- статус обозревателя сверен с L1;
- финальность не выведена только из названия proof.
Материал подготовлен редакцией сайта и проверен 29 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.