跳到正文
Financial Context Wiki

故障证明（欺诈证明）

一份面向具体部署的乐观式故障证明指南，涵盖争议声明、执行轨迹二分、单步验证、时钟、保证金、数据可用性、提款最终性和操作核验。

更新于

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

直接答案

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

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

1
排序

排序器排列 L2 交易并发布交易数据或承诺。

工作原理

  1. 锁定部署：L1 与 L2 链 ID、汇总协议和故障证明版本、区块哈希、工厂、门户或桥、证明程序、虚拟机、游戏类型、实现与管理员地址、许可模型、保证金、最大深度、时钟、成熟延迟、暂停状态和最终性政策。fraud proof 这个标签并不是跨汇总协议的统一规范。
  2. 从经过认证的输入重建声明。记录锚定状态、L1 链头、有争议的 L2 区块或输出根、批次和 blob 数据、链与汇总协议配置、前状态、提款根及准确的派生规则。仅有状态根不足以复现状态转换；数据不可用也可能让原本开放的挑战路径失效。
  3. 验证游戏已经创建，并且能够影响目标对象。检查根声明、声明方、创建区块与时间、游戏类型、受认可或黑名单状态、保证金、挑战者资格，以及门户实际采用的接受规则。区分待定声明、游戏结果和可用于提款的输出。
  4. 使用独立节点和故障证明实现重新执行。把诚实轨迹与每项争议声明比较，并保留原像、状态见证和客户端版本。在交互式游戏中，对正确区间发起攻击或防守，直至最大深度锁定单条指令；再把基本情形见证提交给链上虚拟机验证器。
  5. 跟踪每支队伍的时钟和每笔交易。记录剩余时间、延长时间、L1 纳入与重组风险、调用数据、Gas、替换交易、保证金敞口、并行声明和必须响应的一方。墙上时钟所示的挑战持续时间不一定只是一个固定倒计时；诚实一方也可能因漏掉行动或交易受审查而输掉游戏。
  6. 把裁决映射到协议后果。确定哪些声明被反驳、哪支队伍获胜、保证金与成本如何分配、无效输出是否被排除，以及依赖该输出的其他输出、证明或提款是否必须重建。被罚没的保证金是一种激励，并非对所有潜在跨链桥损失的赔偿。
  7. 分开核对最终性和提款。验证游戏裁决、规定的证明成熟期和裁决后延迟、受认可游戏类型、黑名单与暂停检查、提款纳入证明、最终化收据及 L1 最终性。归档数据和证据、监控升级，并演练挑战者、强制纳入、重新证明和紧急退出程序。

算例

  • 轨迹二分。 一条教学轨迹包含 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，前提是没有暂停、列入黑名单、重新证明或链重组。

风险

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

常见误区

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

相关主题

来源

导航

搜索知识库...