﻿---
title: "Доказательство ошибки (Fraud Proof)"
description: "Руководство с учетом конкретного развертывания: оптимистические доказательства ошибки, оспариваемые утверждения, бисекция трассы, проверка одного шага, часы, залоги, доступность данных, финальность вывода и операционная проверка."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Доказательство ошибки (Fraud Proof)

> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

<a id="answer"></a>

## Краткий ответ

Доказательство ошибки, также часто называемое доказательством мошенничества, представляет собой предусмотренную протоколом процедуру оспаривания оптимистического утверждения о вычислении или состоянии. Заявитель не доказывает каждый переход до принятия утверждения. Вместо этого сторона, имеющая право на оспаривание, может в пределах заданных часов предъявить противоречащую трассу, а расчетный контракт разрешает спор с помощью определенного верификатора. Во многих интерактивных схемах длинную трассу последовательно сужают до одной спорной инструкции, после чего этот базовый случай исполняется в сети.

Само название не доказывает, что развернутая система общедоступна, работоспособна или безопасна. Для безопасности необходимы точные данные деривации, как минимум одна корректно работающая сторона, способная восстановить утверждение и вовремя действовать, достаточный доступ к расчетной сети и газу, правильные программы доказательства и контракты, а также управление, не способное обойти результат. Выстоявшее в игре утверждение может разрешить вывод по правилам конкретного развертывания; оно не доказывает задним числом каждую транзакцию L2, заявление интерфейса или экономический результат.

<a id="mechanism"></a>

## Как это работает

1. Зафиксируйте развертывание: идентификаторы L1 и L2, версии роллапа и системы доказательств ошибки, хеши блоков, фабрику, портал или мост, программу доказательства, виртуальную машину, тип игры, реализацию и административные адреса, модель разрешений, залоги, максимальную глубину, часы, задержки созревания, состояние паузы и политику финальности. Обозначение `fraud proof` не является общей спецификацией для всех роллапов.
2. Восстановите утверждение по аутентифицированным входным данным. Зафиксируйте якорное состояние, вершину L1, спорный блок L2 или корень выхода, данные пакетов и blob, конфигурацию сети и роллапа, предыдущее состояние, корень выводов и точные правила деривации. Одного корня состояния недостаточно для воспроизведения перехода, а недоступность данных способна сделать бесполезным формально открытый путь оспаривания.
3. Проверьте, что игра создана и может влиять на нужный объект. Проверьте корневое утверждение, заявителя, блок и время создания, тип игры, статус признания или внесения в черный список, залог, право на оспаривание и фактическое правило принятия порталом. Различайте ожидающее утверждение, результат игры и выход, готовый для вывода средств.
4. Повторно выполните вычисление независимым узлом и независимой реализацией доказательства ошибки. Сопоставьте честную трассу с каждым спорным утверждением и сохраните прообразы, свидетелей состояния и версии клиентов. В интерактивной игре атакуйте или защищайте правильный интервал, пока максимальная глубина не укажет одну инструкцию; затем передайте свидетельство базового случая сетевому верификатору виртуальной машины.
5. Отслеживайте часы каждой команды и каждую транзакцию. Записывайте оставшееся время, продления, включение в L1 и риск реорганизации, calldata, газ, замену транзакций, сумму под риском в залогах, параллельные утверждения и обязанную ответить сторону. Общая длительность оспаривания не обязательно равна одному фиксированному обратному отсчету, а корректный результат можно проиграть из-за пропущенного хода или цензуры транзакции.
6. Сопоставьте разрешение спора с последствиями по протоколу. Определите, какие утверждения опровергнуты, какая команда победила, как распределяются залоги и расходы, исключен ли неверный выход и нужно ли заново построить зависимые выходы, доказательства или выводы средств. Конфискация залога является стимулом, а не компенсацией всех возможных потерь моста.
7. Отдельно сверяйте финальность и выводы средств. Проверьте разрешение игры, необходимые задержки созревания доказательства и после разрешения, признанный тип игры, черный список и паузу, доказательство включения вывода, квитанцию финализации и финальность L1. Архивируйте данные и доказательства, отслеживайте обновления и отрабатывайте процедуры оспаривания, принудительного включения, повторного доказательства и аварийного выхода.

<a id="example"></a>

## Разобранные примеры

- **Бисекция трассы.** Учебная трасса содержит `1,048,576 = 2^20 instructions`. Если каждый неоспариваемый раунд делит спорный интервал пополам, то `20 bisections` выделяют одну инструкцию, поскольку `2^20 / 2^20 = 1`. Реальная игра может раздельно дробить трассы выходов и исполнения, ветвиться в ориентированный ациклический граф или требовать дополнительных ходов, поэтому это пример сложности, а не число раундов конкретного развертывания.
- **Независимые игровые часы.** Гипотетическая игра дает каждой команде `84 hours`. Защищающая сторона расходует `30 hours`, а оспаривающая сторона `22 hours`; у них остается соответственно `54 hours` и `62 hours`. Прошедшее календарное время не равно просто `84 hours`: идет только время соответствующей команды, а предусмотренные протоколом продления, задержки включения и параллельные утверждения могут менять срок.
- **Учет залога и газа.** По явно гипотетическому правилу неверный корень обеспечен залогом `2 ETH`. Победившая оспаривающая сторона внесла `0.5 ETH`, получает обратно этот депозит и вознаграждение `1.4 ETH`, а на газ L1 потратила `0.08 ETH`; `0.6 ETH` из проигранного залога идет в казначейство. Ее чистая прибыль равна `1.4 - 0.08 = 1.32 ETH`; возвращенные `0.5 ETH` являются основной суммой, а не прибылью, причем `1.4 + 0.6 = 2 ETH`. Получатели залогов и учет участников, не несущих затрат, зависят от контракта.
- **Сроки вывода.** Допустим, вывод доказан в `2026-08-01 12:00 UTC`, установленная задержка созревания доказательства составляет `7 days`, соответствующая игра разрешена в `2026-08-06 18:00 UTC`, а интервал после разрешения равен `1 day`. Два условия наступают в `2026-08-08 12:00 UTC` и `2026-08-07 18:00 UTC`; самое раннее время выполнения обоих условий — `2026-08-08 12:00 UTC`. При дополнительной политике финальности L1 длительностью `20 minutes` экономическое завершение наступает в `2026-08-08 12:20 UTC`, если нет паузы, черного списка, повторного доказательства или реорганизации.

<a id="risks"></a>

## Риски

- Проверка неверной L1, L2, развертывания, типа игры или версии контракта.
- Восстановление по устаревшему, неканоническому или неверному якорю и заголовку L1.
- Отсутствие данных пакета, blob, прообраза, свидетеля состояния или конфигурации.
- Предположение, что обязательство или доступный вход доказательства означает доступность всех данных деривации.
- Получение иной честной трассы программой оспаривания из-за ошибки клиента.
- Ошибки в программе доказательства, виртуальной машине, оракуле прообразов или сетевом верификаторе шага.
- Недоступность или захват разрешенной роли заявителя, оспаривающей стороны либо пути создания игры.
- Отсутствие честного наблюдателя, который обнаружит и откроет спор до нужного срока.
- Цензура, перегрузка L1, реорганизация или скачок газа, препятствующие своевременному ходу.
- Ошибка в трактовке шахматных часов, продлений, максимальной глубины или времени включения транзакции.
- Атака или защита неверного утверждения, интервала трассы, позиции или инструкции.
- Требования к залогу или оборотному капиталу, делающие открытую возможность участия непрактичной.
- Несоответствие распределения залогов, поведения участников без затрат или стимулов предпосылкам безопасности.
- Неожиданное разрешение нескольких игр, дублирующихся утверждений или конфликтующих реализаций.
- Изменение управлением признанного типа игры, верификатора, порога или задержки.
- Блокировка иначе действительных выводов полномочиями хранителя на паузу или черный список.
- Принятие разрешения игры за немедленную финальность вывода или расчета.
- Доказательство вывода через аннулированную игру и отсутствие повторного доказательства.
- Предположение, что отклонение неверного выхода исправляет все последствия для приложений или мостов.
- Перенос модели доказательства и финальности одного оптимистического роллапа на другую систему.

<a id="misconceptions"></a>

## Распространенные заблуждения

- Неоспоренное оптимистическое утверждение криптографически доказано как верное.
- Любой человек может оспорить каждую развернутую систему без разрешения, капитала или инфраструктуры.
- Доказательство ошибки работает, даже если данные деривации недоступны.
- Победа в споре мгновенно финализирует каждый зависимый вывод и возмещает все потери.
- Семидневный период оспаривания, бинарная игра и один честный наблюдатель являются универсальными константами роллапов.

<a id="related"></a>

## Связанные темы

- [Доступность данных](/ru/crypto/data-availability/)
- [Оптимистический роллап](/ru/crypto/optimistic-rollup/)
- [Доказательство корректности](/ru/crypto/validity-proof/)

<a id="sources"></a>

## Источники

- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (дата обращения: 2026-08-12)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Fault Dispute Game](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Honest Challenger (Fault Dispute Game)](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Bridge Integration](https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (дата обращения: 2026-08-12)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (дата обращения: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (дата обращения: 2026-08-12)

Source: https://wiki.fcontext.com/ru/crypto/fraud-proof/index.mdx
