---
title: "故障证明（欺诈证明）"
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.

# 故障证明（欺诈证明）

> 仅供教育参考，不构成投资或安全建议。故障证明的安全性取决于具体部署、数据可用性、挑战者权限与活跃性、时钟、保证金、验证器软件、治理、结算最终性和提款合约。

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

## 直接答案

故障证明通常也称欺诈证明，是质疑有关计算或状态的乐观声明的一套协议流程。声明方不会在声明获接受前证明每次转换；符合资格的挑战者可在规定时钟内提出冲突轨迹，结算合约再依据指定验证器裁决分歧。许多交互式设计会反复缩小一条长轨迹，直至只剩一个有争议的指令，并在链上执行这个基本情形。

名称本身不能证明已部署系统无需许可、持续可用或安全。安全性要求准确的派生数据可用，至少一名正确的挑战者能够重建声明并及时行动，结算链访问和 Gas 充足，证明程序与合约正确，且治理不能绕过结果。通过争议游戏的声明可以依据该部署规则授权提款；但这并不会追溯证明每笔 L2 交易、前端陈述或经济结果都正确。

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

## 工作原理

1. 锁定部署：L1 与 L2 链 ID、汇总协议和故障证明版本、区块哈希、工厂、门户或桥、证明程序、虚拟机、游戏类型、实现与管理员地址、许可模型、保证金、最大深度、时钟、成熟延迟、暂停状态和最终性政策。`fraud proof` 这个标签并不是跨汇总协议的统一规范。
2. 从经过认证的输入重建声明。记录锚定状态、L1 链头、有争议的 L2 区块或输出根、批次和 blob 数据、链与汇总协议配置、前状态、提款根及准确的派生规则。仅有状态根不足以复现状态转换；数据不可用也可能让原本开放的挑战路径失效。
3. 验证游戏已经创建，并且能够影响目标对象。检查根声明、声明方、创建区块与时间、游戏类型、受认可或黑名单状态、保证金、挑战者资格，以及门户实际采用的接受规则。区分待定声明、游戏结果和可用于提款的输出。
4. 使用独立节点和故障证明实现重新执行。把诚实轨迹与每项争议声明比较，并保留原像、状态见证和客户端版本。在交互式游戏中，对正确区间发起攻击或防守，直至最大深度锁定单条指令；再把基本情形见证提交给链上虚拟机验证器。
5. 跟踪每支队伍的时钟和每笔交易。记录剩余时间、延长时间、L1 纳入与重组风险、调用数据、Gas、替换交易、保证金敞口、并行声明和必须响应的一方。墙上时钟所示的挑战持续时间不一定只是一个固定倒计时；诚实一方也可能因漏掉行动或交易受审查而输掉游戏。
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`：只有规则指定一方的时钟会走动，而且协议规定的延长、纳入延迟和并行声明都可能改变截止时间。
- **保证金和 Gas 账本。** 根据一项明确的假设规则，无效根附带 `2 ETH` 保证金。获胜挑战者缴纳了 `0.5 ETH`，收回这笔保证金并获得 `1.4 ETH` 奖励，同时花费 `0.08 ETH` L1 Gas；败方保证金中的 `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`。若最终性政策还要求 `20 minutes`，则经济上完成的时间是 `2026-08-08 12:20 UTC`，前提是没有暂停、列入黑名单、重新证明或链重组。

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

## 风险

- 审计错误的 L1、L2、部署、游戏类型或合约版本。
- 从陈旧、非规范或错误的锚点与 L1 链头重建。
- 缺失批次、blob、原像、状态见证或配置数据。
- 误以为承诺或可用的证明输入意味着所有派生数据均可用。
- 挑战者软件因客户端缺陷而派生出不同的诚实轨迹。
- 故障证明程序、虚拟机、原像预言机或链上单步验证器存在缺陷。
- 获许可的提议方、挑战者或游戏创建路径不可用或被控制。
- 没有诚实监控者在相关截止时间前发现并开启争议。
- 审查、L1 拥堵、链重组或 Gas 飙升阻止及时行动。
- 误读棋钟、延长时间、最大深度或交易纳入时间。
- 攻击或防守错误的声明、轨迹区间、位置或指令。
- 保证金要求或营运资金使无需许可的参与在实践中不可行。
- 保证金分配、搭便车者或激励行为偏离安全假设。
- 多个游戏、重复声明或冲突实现产生意外裁决。
- 治理更改受认可游戏类型、验证器、门槛或延迟。
- 守护者的暂停或黑名单权限阻止原本有效的提款。
- 把游戏裁决当成即时提款或结算最终性。
- 根据已失效的游戏证明提款，却未能重新证明。
- 假设排除无效输出会修复每个下游应用或跨链桥影响。
- 把一个乐观汇总协议的证明与最终性模型外推至另一系统。

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

## 常见误区

- 无人挑战的乐观声明已经得到密码学证明。
- 任何人都能在无需许可、资金或基础设施的情况下挑战每个已部署系统。
- 即使派生数据不可用，故障证明也能运作。
- 赢得争议会立即最终化所有依赖提款并赔偿全部损失。
- 七天挑战期、二元游戏和一名诚实观察者是所有汇总协议的固定常量。

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

## 相关主题

- [数据可用性](/zh-cn/crypto/data-availability/)
- [乐观汇总](/zh-cn/crypto/optimistic-rollup/)
- [有效性证明](/zh-cn/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/zh-cn/crypto/fraud-proof/index.mdx