Fraud proof («доказательство мошенничества») — это крипто- и протокольный механизм, с помощью которого участник сети может оспорить некорректное состояние rollup’а или блока, показав, что оператор (sequencer/пропозер) нарушил правила протокола.
Механизм fraud proof — ключевой элемент безопасности optimistic-rollup’ов в экосистеме Ethereum и других L2-решений.
Зачем нужны fraud proofs
В классическом L1-блокчейне:
- каждый валидатор сам пересчитывает транзакции и убеждается, что блок корректен;
- если блок нарушает правила протокола — он просто отклоняется большинством узлов.
В optimistic-rollup:
- вычисления происходят вне L1;
- на L1 публикуется только «результат» (батч данных и новое состояние);
- L1 по умолчанию «доверяет» этому результату — иначе нет выигрыша в масштабировании.
Чтобы не потерять безопасность L1, вводится fraud proof:
- любой наблюдатель (watcher/валидатор) может:
- проверить опубликованное состояние;
- и, если оно некорректно, предъявить доказательство мошенничества,
- заставив rollup откатить неверное состояние и наказать виновного.
Как работает fraud proof на уровне rollup’а
Схема на примере optimistic-rollup’а поверх Ethereum:
- Шаг 1: оператор публикует состояние.
Sequencer собирает транзакции, исполняет их на L2 и публикует:
- батч данных (или их хеш) на L1;
- новый корень состояния (state root);
- метаданные блока L2.
- Шаг 2: стартует challenge-период.
После публикации батча начинается challenge period — окно времени, в течение которого:
- anyone can challenge — любой участник может оспорить корректность;
- наблюдатели скачивают данные, пересчитывают состояние и сверяют его с опубликованным.
- Шаг 3: подача fraud proof.
Если наблюдатель находит ошибку, он формирует fraud proof:
- указывает спорный диапазон транзакций или конкретный шаг;
- включает необходимые данные (части состояния до/после, доказательства в Merkle/Patricia-дереве и т.п.);
- отправляет proof в контракт rollup’а на L1.
- Шаг 4: разрешение спора.
Контракт rollup’а выполняет «мини-суд»:
- либо полностью пересчитывает спорный участок;
- либо использует интерактивную игру: стороны пошагово сужают спор до одного вычисления, которое проверяется ончейн.
Если выясняется, что оператор действительно ошибся/сжульничал:
- спорный блок/батч признаётся недействительным;
- состояние откатывается к предыдущему корректному root’у;
- залог оператора (bond) частично или полностью конфискуется и передаётся честной стороне.
- Шаг 5: финализация.
Если challenge-период истёк и fraud proof никто не подал:
- батч считается финализированным;
- мостовые операции L2→L1 становятся «жёстко» безопасными;
- пользователи могут считать это состояние окончательным.
Кто подаёт fraud proofs и почему им можно доверять
Модель безопасности optimistic-rollup’а основана на предположении:
- достаточно, чтобы был хотя бы один честный наблюдатель, способный:
- получить данные батча;
- пересчитать состояние;
- и подать fraud proof при нарушении правил.
Чтобы мотивировать таких наблюдателей:
- протокол:
- удерживает залог (bond) с оператора, который теряется при доказанном мошенничестве;
- может выплачивать часть этого залога участнику, подавшему успешный fraud proof;
- тем самым создаётся экономический стимул следить за корректностью состояния.
Ограничение:
- если никто не подаст fraud proof в течение challenge-периода (по лени, отсутствию инфраструктуры или сговору), некорректное состояние будет принято как валидное.
Fraud proof vs validity proof
Fraud proof противопоставляют validity proof, используемому в ZK-rollup’ах.
| Характеристика | Fraud proof (optimistic-rollup) | Validity proof (ZK/validity-rollup) |
|---|---|---|
| Кто доказывает | Наблюдатель доказывает, что состояние неверное | Оператор доказывает, что состояние верное |
| Когда проверяется | Только при challenge (спорах) | Для каждого батча/обновления состояния |
| Модель по умолчанию | «Оптимистично верим, пока не доказано обратное» | «Считаем верным только то, для чего есть proof» |
| Время финализации | Задержка на challenge-период (дни) | После валидации proof (минуты/часы, зависит от частоты публикаций) |
| Нагрузка на L1 | Пересчёт/игра только в спорных кейсах | Проверка validity proof для каждого батча |
| Требования к криптографии | Относительно простые (Merkle-доказательства, пересчёт состояния) | Сложные ZK-схемы, prover/verifier, иногда trusted setup |
Кратко:
- fraud proof — «пассивная защита», включающаяся только при атаке;
- validity proof — «активная проверка» каждого обновления состояния.
Ограничения и риски fraud proof-модели
Несмотря на сильную теоретическую модель, на практике fraud proofs имеют ограничения:
- Зависимость от наблюдателей.
Без хотя бы одного активного участника, готового поднять инфраструктуру и подать proof, механизм не сработает.
- Сложность реализации.
Нужно аккуратно реализовать:
- доступность данных (см. data availability);
- игру по разрешению споров;
- схемы хранения состояния с возможностью доказуемого пересчёта.
- Challenge-период и UX.
Чтобы дать наблюдателям время на проверку, challenge-период часто измеряется днями. Это:
- замедляет финализацию выводов L2→L1;
- усложняет UX (пользователям нужны быстрые мосты и дополнительный риск-менеджмент).
- Риски griefing-атак.
Недобросовестные участники могут подавать «пустые» или заведомо некорректные proofs, чтобы:
- тратить газ оператора/сети;
- создавать задержки финализации.
Протокол должен предусматривать штрафы и фильтры.
Fraud proofs в контексте L2-рисков
Fraud proof — лишь один слой в общей модели рисков L2:
- если операторы могут останавливать публикацию данных, даже честный наблюдатель не сможет построить fraud proof;
- уязвимости в смарт-контрактах rollup’а или мостов могут обойти механизм доказательства мошенничества;
- централизация sequencer’а и governance тоже играет роль — если один актор контролирует и L2, и «наблюдателей», теория «достаточно одного честного» ломается.
Поэтому при оценке «насколько безопасен optimistic-rollup» важно смотреть:
- как реализованы fraud proofs;
- есть ли независимая инфраструктура наблюдателей;
- как устроена доступность данных;
- кто управляет апгрейдами и параметрами challenge-периода.
FAQ по fraud proofs
Может ли любой пользователь подать fraud proof? Да, модель «anyone can challenge» подразумевает, что любой участник, имеющий доступ к данным, может пересчитать состояние и подать доказательство мошенничества. На практике для этого нужны клиент, ресурсы и знания, поэтому обычно этим занимаются специализированные «watcher»-узлы.
Что происходит со средствами пользователей, если fraud proof выявил неверное состояние? Некорректный блок признаётся недействительным, состояние откатывается к последнему корректному root’у. Депозиты и выводы, завязанные на фальшивый блок, считаются не состоявшимися. При этом залог виновной стороны может быть конфискован.
Почему бы сразу не использовать validity proofs вместо fraud proofs? Validity proofs (ZK/validity-rollup) дают более строгие гарантии и быструю финализацию, но:
- требуют сложной криптографии и тяжёлых prover’ов;
- исторически были труднее в реализации и дороже.
Fraud proof-модель проще реализовать и интегрировать с существующим стэком, поэтому многие первые L2 выбрали optimistic-подход.
Сократится ли challenge-период у optimistic-rollup’ов в будущем? Часть проектов обсуждает сокращение периода по мере накопления опыта и улучшения инфраструктуры наблюдателей. Но полностью избавиться от challenge-периода нельзя, не жертвуя частью безопасности — это фундаментальное свойство fraud proof-модели.