欺诈证明

什么是欺诈证明？

欺诈证明是一种区块链机制，用于证明拟议的状态转换、交易结果、提现或其他链下计算存在错误。

欺诈证明最常见于乐观 Rollup。这类系统在基础区块链之外处理加密货币交易，并将压缩后的数据和状态承诺发布回基础链。

乐观系统会暂时接受提交的结果，而不是为每个交易批次都要求提供加密有效性证明。

在规定的挑战期内，独立参与者可以通过提交证据，证明系统规则未得到遵守，从而对错误结果提出质疑。

如果挑战成功，无效声明会被驳回，正确状态继续有效，而不诚实或出错的参与者可能会损失一笔财务保证金。

Ethereum 关于乐观 Rollup 的文档解释说，这类系统会默认链下交易有效，除非有人通过欺诈证明流程提出挑战。

欺诈证明不一定能证明某人有欺诈意图，因为错误结果也可能源于软件漏洞、配置错误、硬件问题或无意的计算失误。

因此，许多现代区块链开发者改用范围更广的术语“故障证明”（fault proof），而不是“欺诈证明”。

欺诈证明为何对加密领域很重要？

欺诈证明让区块链系统能够将成本高昂的计算移出基础层，同时避免用户完全信任某个中心化运营方。

基础区块链无需在 Rollup 交易发生时逐笔执行所有交易。

它只需存储足够的信息，以便重建 Rollup 状态，并在有人声称提交了无效结果时解决争议。

这种乐观设计可以降低交易成本，因为只有参与者存在分歧时才主要需要进行成本高昂的链上验证。

欺诈证明还支持用户自我托管，使用户能够质疑无效提现或状态声明，而不必只依赖运营 Rollup 的组织。

这种机制让基础区块链成为中立裁判，按照智能合约规则检查证据。

只要至少有一名诚实且有能力的参与者持续监控区块链，并能及时提交挑战，设计得当的系统就可以保持安全。

这种安全模型通常被称为“一诚实方假设”。

欺诈证明如何运作？

Rollup 排序器会收集用户交易、确定交易顺序、执行交易，并生成新版 Rollup 状态。

随后，Rollup 会向其结算区块链发布交易数据或数据承诺，以及对结果状态的声明。

根据协议不同，这项声明可能称为 assertion、输出根、状态根、状态承诺或检查点。

结算合约不会立即认定该声明已经永久最终确定。

相反，合约会启动挑战期，验证者或挑战者可以在此期间独立重现计算过程。

诚实的挑战者会根据 Rollup 的官方规则执行已发布交易，并将计算结果与拟议结果进行比较。

如果两种结果相同，则无需提供欺诈证明；挑战期结束后，该声明可以最终确定。

如果结果不同，挑战者会通过结算合约发起争议。

争议流程会逐步缩小分歧范围，直到结算区块链能够验证导致结果冲突的具体计算步骤。

随后，合约会判定哪项声明符合协议规则，并驳回另一项声明。

欺诈证明示例

假设某个 Rollup 初始状态为 Alice 持有 10 个代币，Bob 持有 2 个代币。

一笔有效交易将 3 个代币从 Alice 转给 Bob。

正确的结果状态应为 Alice 持有 7 个代币，Bob 持有 5 个代币。

假设 Rollup 运营方错误地提交了一项状态承诺，显示 Alice 持有 6 个代币，Bob 持有 6 个代币。

独立验证者重新执行该交易，并计算出正确余额。

由于提交的结果无法从先前状态和有效交易中推导得出，验证者对运营方的状态承诺提出挑战。

欺诈证明会指出存在争议的执行步骤，并提供结算合约验证转账规则所需的信息。

合约确认实际只应转移 3 个代币，并驳回错误的状态承诺。

这个示例经过简化，但真实的欺诈证明系统也会将同一原理用于复杂的智能合约执行、Gas 计算、存储更新和加密承诺。

什么是乐观 Rollup？

乐观 Rollup 是一种 Layer 2 扩容系统，在基础区块链之外执行加密货币交易，同时使用基础链提供数据可用性、结算和争议解决。

“乐观”是指默认将交易批次视为有效，而不是立即为每项计算都附上正确性证明。

由于排序器会在处理交易后立即报告结果，用户通常可以在 Rollup 内快速获得确认。

不过，从 Rollup 提现回结算层可能需要等待更长时间，因为相关状态声明必须通过挑战期。

乐观 Rollup 与普通侧链不同，其安全设计在很大程度上依赖结算区块链，而不是只依赖独立的验证者群体。

Ethereum 扩容文档区分了乐观 Rollup 和零知识 Rollup：前者通过欺诈证明执行有争议的计算，后者则提交有效性证明。

什么是状态根？

状态根是一个简洁的加密承诺，代表区块链或 Rollup 在特定时点的完整状态。

状态可能包括账户余额、智能合约代码、存储值、nonce，以及处理未来交易所需的其他信息。

状态根远小于底层完整数据库。

即使只更改一个相关值，通常也会改变最终的承诺值。

Rollup 提议者可以发布状态根，而无需将完整状态直接写入结算合约。

其他参与者可以根据可用交易数据重建状态，并检查自己是否得到相同的状态根。

欺诈证明争议通常始于双方根据本应相同的初始状态和交易序列计算出不同的状态根。

什么是状态转换？

状态转换是通过执行一笔或多笔有效交易，将旧区块链状态转换为新状态的过程。

简化公式为：

。

状态转换函数包含协议规则，用于处理签名、余额、Gas、合约执行、存储和交易排序。

所有使用相同输入和协议版本的诚实参与者都应计算出相同结果。

欺诈证明用于证明，拟议的新状态并非由旧状态和已发布输入按照规则正确得出。

确定性执行至关重要，因为如果诚实计算机使用相同输入却可以得出不同答案，争议就无法可靠解决。

什么是挑战期？

挑战期是乐观结果在结算层面最终确定之前，可以被质疑的一段时间。

许多乐观 Rollup 设计采用接近 1 周的挑战期，但具体时长取决于协议，也可能通过治理或升级进行更改。

等待期为独立验证者提供时间，以下载数据、重现执行、发现无效声明、准备交易手续费或保证金，并提交挑战。

挑战期过短会使安全性严重依赖持续监控、快速基础设施以及对结算区块链的不间断访问。

挑战期过长则可能降低资金效率，使常规提现变得不便。

Ethereum 数据可用性指南解释说，乐观 Rollup 通常会提供争议窗口，让独立验证者检查已发布数据并挑战错误的状态转换。

用户应查看具体网络的挑战和最终确定规则，而不能假设每个乐观 Rollup 都恰好采用 7 天挑战期。

为什么提现需要时间？

乐观 Rollup 的标准提现可能需要等待，因为结算合约必须避免依据无效状态声明释放资产。

如果错误声明可以立即最终确定，攻击者可能会捏造余额，并在任何人能够回应之前提走锁定在结算层的资产。

挑战期让验证者有时间证明，提现依赖于无效的 Rollup 状态。

相关状态承诺最终确定后，用户便可按照协议的跨链桥规则完成提现。

用户可以通过第三方流动性安排更快获取资金，但这类安排会带来单独的费用、流动性要求、智能合约风险和交易对手假设。

Ethereum 零知识 Rollup 指南解释说，乐观 Rollup 的提现会延迟，以便进行欺诈证明挑战；有效性证明系统则可在验证证明后完成退出。

什么是交互式欺诈证明？

交互式欺诈证明是在对漫长计算存在分歧的参与方之间进行的多步骤争议博弈。

直接在结算区块链上发布并重新执行完整 Rollup 区块，成本可能过高，也可能超过交易限制。

因此，提议者和挑战者会分别承诺不同的执行轨迹，并不断缩小存在分歧的范围。

一种常见方法是通过称为“二分查找”的流程，将执行轨迹划分成更小的部分。

每轮都会找出包含首个分歧点的一半。

这一过程持续进行，直到争议缩小至一条机器指令或其他结算合约可直接验证的小型操作。

结算区块链无需重现每一步，只需检查承诺、争议过程中的操作以及最终存在争议的指令。

当前交互式争议设计的官方文档介绍了如何将争议缩小为由父区块链验证的单步证明。

什么是单步证明？

单步证明提供足够的信息，让结算合约验证 Rollup 执行轨迹中的一条争议指令。

证明会指出执行该指令前的机器状态、指令本身、所需输入数据，以及所声称的执行后状态。

结算合约会应用该指令的规则，并计算正确的下一状态。

如果结果与挑战者的声明相符，而非提议者的声明，挑战者就会赢得争议。

单步验证可以让大规模链下计算受到约束，而不必要求结算区块链在正常情况下运行完整的 Rollup 程序。

用于证明执行的虚拟机必须具有确定性，并准确代表 Rollup 的共识规则。

什么是非交互式欺诈证明？

非交互式欺诈证明试图通过一次提交或有限的验证流程，提供证明状态转换无效所需的全部证据。

这种设计可以减少提议者和挑战者之间反复回应的需要。

它可能需要证明包含更多数据，或使用专门方法来隔离错误计算。

交互式系统可以通过多轮缩小争议范围，从而减少链上工作；非交互式系统则可能加快解决速度，并降低争议期间对持续响应能力的依赖。

哪种设计更合适，取决于执行复杂度、结算层成本、证明大小、实现安全性和协议必须处理的故障类型。

欺诈证明与故障证明

“欺诈证明”和“故障证明”通常用于描述同一种乐观争议机制。

历史上，“欺诈证明”较为常见，因为它描述了用于挑战不诚实行为的证据。

“故障证明”更加准确，因为该机制检查的是结果是否错误，而不是判定运营方的意图。

错误输出可能由恶意操纵、软件过时、配置错误、数据库损坏或普通编程错误导致。

当前协议文档在介绍生产环境争议系统时，越来越多地使用“故障证明”一词。

官方故障证明系统文档介绍了一种模块化架构，其中包含故障证明程序、故障证明虚拟机和争议博弈协议。

欺诈证明与有效性证明

欺诈证明是在有人提出挑战后证明已提交的结果错误。

有效性证明则是在结算合约接受状态转换之前，证明该转换正确。

乐观 Rollup 通常不附带有效性证明就发布状态声明，并依赖挑战窗口。

有效性 Rollup 会使用零知识证明等技术，为链下计算批次生成加密证明。

有效性证明验证器可以立即驳回错误批次，因为攻击者不应能为无效状态转换生成有效证明。

如果所有声明都正确，欺诈证明系统在正常运行期间可能需要更少的计算，因为此时无需执行争议计算。

有效性证明系统在生成证明后可能更快完成结算，但可能需要复杂的证明基础设施和专门的密码学技术。

两种设计都不一定更优，因为安全性还取决于数据可用性、实现质量、治理权限、升级控制和结算层。

欺诈证明与零知识证明

零知识证明允许一方在不公开用于证明的所有私密输入的情况下，证明某项陈述为真。

许多区块链有效性系统会使用零知识简洁证明，即使交易数据仍公开可供状态重建。

欺诈证明通常是响应式的，因为它是在提出错误结果后生成的。

零知识有效性证明通常是主动式的，因为它会在接受新状态时一并提交，或在接受前提交。

欺诈证明依赖诚实参与者有机会发现并挑战故障。

有效性证明依赖加密可靠性和验证器实现正确。

未来的 Rollup 架构可能会结合故障证明、有效性证明、证明者声明和多个独立实现，从而降低对任何单一系统的依赖。

欺诈证明与 Merkle 证明

Merkle 证明用于证明某项数据属于由 Merkle 根代表的数据集。

例如，它可以证明某个账户余额、交易或提现消息包含在已承诺的树结构中。

欺诈证明则用于证明某项计算或状态转换声明无效。

欺诈证明通常会包含 Merkle 证明，使结算合约能够只获取验证争议步骤所需的少量状态数据。

Merkle 证明可以证明某项数据包含在数据集中，却不能证明该交易得到了正确执行。

因此，这两种证明用途不同，但经常会配合使用。

数据可用性的作用

如果挑战者无法获取重建状态和识别错误执行所需的数据，欺诈证明就无法保护 Rollup。

否则，恶意运营方可能在发布状态承诺的同时，扣留承诺所依据的交易数据。

独立验证者会知道自己无法重现结果，却可能无法生成指出具体故障所需的证明。

乐观 Rollup 通过在结算层发布压缩交易数据或协议认可的数据承诺来解决这一问题。

Ethereum Rollup 可以通过普通交易 calldata 或专为 Rollup 数据设计的 Blob 交易发布数据。

EIP-4844 规范引入了携带 Blob 的交易，使 Rollup 能够以低于永久执行 calldata 的成本发布临时数据。

由于协议只会在有限时间内保留 Blob 数据，监控系统必须在挑战期内获取并保存所需信息。

因此，数据可用性是欺诈证明安全性的核心组成部分，而不是可有可无的独立功能。

结算区块链的作用

结算区块链存储 Rollup 承诺、接收争议交易、管理参与者保证金，并执行最终验证逻辑。

它根据自身共识规则判定哪些争议操作和证明有效，因此充当中立裁判。

Rollup 会继承结算层最终性、抗审查性、智能合约执行和数据可用性方面的部分安全性。

如果结算区块链停止最终确定区块，Rollup 声明和提现也可能停止推进。

如果攻击者能在整个争议窗口内审查所有诚实挑战，无效声明就可能很难被阻止。

因此，欺诈证明的安全性既取决于 Rollup 代码，也取决于结算区块链能否保持可用并抵御长期审查。

排序器的作用

排序器接收用户交易、选择交易顺序、执行 Rollup 区块，并发布交易批次或承诺。

中心化排序器可以提供快速确认，但可能延迟、重排或审查交易。

欺诈证明能够防范无效执行，但不能自动阻止所有形式的交易审查或有害排序。

排序器可以发布符合协议规则的有效状态，同时仍暂时排除用户交易。

如果排序器拒绝处理交易，Rollup 系统可能会提供强制纳入路径，让用户通过结算层提交交易。

用户应区分欺诈证明所针对的执行正确性，以及需要其他机制保障的排序公平性和活性。

挑战者的作用

挑战者是监控拟议 Rollup 状态并对无效声明提出争议的参与者或自动化服务。

挑战者会运行兼容的节点软件，并根据结算层数据重现 Rollup 的执行过程。

挑战者必须保持在线、跟进协议升级、保存所需历史信息，并在相关截止时间前提交交易。

挑战者可能需要准备加密货币，用于支付结算层 Gas 和财务保证金。

当前的挑战者软件可以监控争议、维护有效提议、挑战无效提议，并在胜诉后领取保证金。

官方挑战者文档介绍了一种生产级服务，该服务依赖已同步的 Rollup 节点和确定性轨迹提供程序。

如果技术独立的参与者无需获得中心化组织批准就能运行挑战者，那么无许可参与才更有实际意义。

为什么要使用保证金？

保证金是参与者在提出声明或进行争议中的某些操作时锁定的加密货币。

保证金可以阻止攻击者无限提交虚假声明，或在不承担财务后果的情况下迫使诚实验证者投入资源。

支持错误声明的参与者可能会损失部分或全部相关保证金。

成功的挑战者可以收回其保证金，并根据协议获得经济奖励。

保证金金额应足以阻止滥用，但不能高到只有资金雄厚的组织才能参与。

保证金过高，可能会使理论上无需许可的欺诈证明系统在实践中难以参与。

保证金过低，则可能鼓励垃圾信息、恶意骚扰和延迟攻击。

设计保证金时，必须考虑结算层手续费、资产波动性、争议持续时间、资金机会成本和风险价值。

无许可与许可型欺诈证明

无许可欺诈证明系统允许任何符合公开技术和经济要求的参与者提交或挑战状态声明。

许可型系统则将提议、挑战其中一项或两项操作限制在获批地址或组织中。

在早期开发阶段，许可型验证可以减少垃圾信息和运营不确定性。

但这也会产生信任假设，因为用户依赖获批验证者保持诚实、可用和独立。

无许可系统更加开放，但需要强大的防护措施，以应对恶意骚扰、延迟攻击、保证金操纵和软件漏洞利用。

某个网络可以运行无许可争议游戏，同时保留有权暂停或替换系统部分组件的紧急委员会或升级管理方。

用户应检查完整的安全模型，而不能认为无许可挑战路径消除了所有管理权限。

欺诈证明的当前发展

截至 2026 年 7 月，生产环境中的故障证明系统仍在不断演进，包括推出新客户端、升级虚拟机、改进争议协议和扩大无许可参与范围。

OP Stack 官方文档介绍了无许可挑战，以及 2026 年向新版故障证明客户端过渡的计划，说明挑战者运营方必须使用当前软件，并与绝对初始状态保持一致。

官方 2026 年故障证明客户端迁移公告解释说，旧版证明软件已停止支持，链运营方必须迁移到替代实现。

Arbitrum 官方文档将 BoLD 描述为一种有时间限制的争议设计，支持无许可验证，并限制恶意参与者无限期延长争议的能力。

2026 年 BoLD 概述介绍了交互式欺诈证明如何支持开放挑战，同时限制争议持续时间。

这些发展表明，欺诈证明是正在生产环境中使用的安全系统，而不仅仅是理论上的区块链概念。

这些发展也说明，证明系统需要持续审计、客户端维护、升级协调、监控和事件响应。

欺诈证明与软件升级

故障证明程序必须执行与正在争议的 Rollup 版本相同的共识规则。

协议升级可能会改变交易执行、Gas 成本、预编译合约、区块规则、系统合约或数据解释方式。

使用过时规则集的挑战者软件，可能会错误地将有效声明判定为无效，也可能无法挑战真正无效的声明。

证明系统通常会使用一个绝对初始状态，来确定证明虚拟机的起始条件。

更改证明程序或共识规则，可能需要设置新的初始状态并更新链上合约。

运营方必须谨慎协调升级，以便按照正确规则解决旧版和新版争议。

这也是多个独立证明实现被视为有利于长期安全的原因之一。

什么是延迟攻击？

延迟攻击旨在拖延争议解决，或阻止有效状态最终确定，但攻击者本身并不能成功证明状态无效。

攻击者可能提交相互冲突的声明、迫使争议轮次不断重复、利用时间规则，或锁定诚实参与者的资金。

较早的交互式设计可能允许攻击者接连发起争议，反复延长提现等待时间。

有时间限制的争议设计旨在确保即使存在大量恶意声明，也能在可预测的最长时间内解决。

财务保证金会让延迟攻击付出成本，但仍不能取代可靠的时间规则和争议流程设计。

系统必须保障安全性，即无效声明不会最终确定；同时也要保障活性，即有效声明最终能够完成最终确定。

安全性与活性

安全性意味着欺诈证明系统不会接受无效状态，也不会允许未经授权的提现。

活性意味着诚实交易、状态声明和提现最终都能推进并完成。

系统可以在不确定期间暂停所有提现来维护安全性，但这会损害活性。

系统可以通过快速最终确定声明来提高活性，但挑战窗口过短可能削弱安全性。

紧急控制、争议超时、保证金、挑战期和许可规则共同平衡这两个目标。

评估 Rollup 时，用户应同时考虑资金是否可能被盗，以及资金是否可能长期无法使用。

欺诈证明的主要安全假设

欺诈证明 Rollup 通常假设至少有一名诚实参与者能够重建 Rollup 状态，并挑战无效声明。

所需交易数据必须在足够长的时间内保持可用，以便该参与者进行验证。

结算区块链必须持续处理交易，并且不得在整个争议窗口内审查所有诚实挑战。

Rollup 状态转换函数和证明虚拟机必须正确实现预期规则。

链上争议合约必须正确判断操作、截止时间、保证金、承诺和最终证明。

诚实挑战者必须使用当前软件、具备充足计算资源和可靠数据来源，并拥有足够资金支付 Gas 和保证金。

升级密钥、守护者、安全委员会和治理合约不得滥用任何可覆盖或替换证明系统的权限。

一名诚实挑战者能保护所有人吗？

原则上，只要协议是无许可的且所有必要假设均成立，一名诚实挑战者就能阻止无效状态声明最终确定。

挑战者不需要大多数 Rollup 用户支持，因为结算合约会根据客观执行规则裁决争议。

不过，这名诚实参与者必须发现故障、掌握所需数据、保持在线、承担参与成本，并避免受到审查。

理论上只需一名挑战者的系统，如果有多个独立挑战者使用不同的基础设施和软件实现，运营韧性会更强。

实现多样性可以降低单个漏洞、服务中断、法律限制或云服务故障同时使所有监控者失效的风险。

欺诈证明能阻止 Rollup 的所有攻击吗？

欺诈证明可以驳回无效状态转换，但无法解决 Rollup 面临的所有安全问题。

它们不会自动阻止排序器审查、用户密钥被盗、恶意应用合约、网络钓鱼、预言机操纵或治理攻击。

如果数据存储在结算层之外，且数据可用性假设较弱，欺诈证明可能无法保护用户。

如果证明系统本身存在严重的共用漏洞，导致诚实和不诚实参与者都算出相同的错误结果，欺诈证明也无能为力。

安全的 Rollup 除了欺诈证明，还需要强大的数据可用性、经过审计的跨链桥合约、安全的升级流程、可靠节点和透明治理。

Plasma 中的欺诈证明

Plasma 系统使用父区块链，解决独立子链上的活动争议。

如果运营方试图最终确定无效交易或状态，用户可以提交欺诈证明。

传统 Plasma 设计通常会将大部分交易数据存储在父区块链之外。

这种架构会产生数据扣留问题：如果运营方拒绝提供所需信息，用户可能无法构造欺诈证明。

Ethereum Plasma 文档解释说，Rollup 通过在结算层发布交易数据改进了这一安全模型。

因此，Plasma 和乐观 Rollup 都会使用欺诈证明，但两者周围的数据可用性保障有所不同。

状态通道中的欺诈证明

状态通道允许一组明确的参与者在区块链之外交换签名状态更新。

参与者通常只在开启通道、结算最终状态或解决争议时使用区块链。

不诚实的参与者可能尝试使用旧状态关闭通道，以获得对自己更有利的余额。

诚实参与者可以在争议窗口内提交更新且签名有效的状态进行回应。

这种证据能够证明拟议结算状态过时或无效，因此发挥了欺诈证明的作用。

Ethereum 状态通道指南介绍了争议仲裁如何在提交无效或过时状态时保护用户。

欺诈证明如何影响加密用户？

大多数 Rollup 用户不会亲自提交欺诈证明，因为专门的验证者和监控服务会持续进行验证。

用户持有资产、使用应用，或通过乐观 Rollup 的标准跨链桥提现时，仍然依赖这一机制。

用户可能会在 Rollup 上快速看到交易确认，但结算层的最终性仍处于等待状态。

成功的挑战可能会撤销基于无效状态声明构建、但尚未最终确定的结果。

钱包和应用应说明排序器确认、结算确认和提现最终完成之间的区别。

用户还应了解网络上的欺诈证明是否已启用、是否无许可、是否可升级，以及是否存在紧急管理控制。

开发者应如何针对欺诈证明进行设计

Rollup 开发者必须确保所有与共识相关的操作都能在证明环境中确定性地重现。

应避免依赖本地时间、操作系统的不确定随机行为、未记录的外部服务或特定硬件的计算结果。

证明代码、节点代码和链上验证合约必须对指令语义和数据格式达成一致。

开发者应测试无效输出、延迟响应、冲突声明、数据缺失、保证金耗尽和协议升级等情况。

开发者应提供清晰的流程，说明如何运行挑战者、验证所需初始状态和合约地址。

安全审计既要检查 Rollup 的常规执行路径，也要检查少见的争议路径。

如果争议系统从未在真实对抗环境中测试，那么真正需要它时可能会失效。

如何评估故障证明系统

首先确认网络是否已经启用实际运行的欺诈证明系统，而不是仅有路线图或计划设计。

检查是否任何人都可以提交挑战，还是只有允许名单中的参与者可以操作。

了解挑战期、提现延迟、保证金要求、争议截止时间和预计最长解决时间。

确认交易数据发布在何处，以及用户能否独立重建 Rollup 状态。

检查紧急守护者、安全委员会、管理员或治理合约是否能覆盖最终结果。

关注是否存在多个挑战者运营方、公开节点软件、可复现构建、审计、漏洞披露和漏洞赏金计划。

确认证明系统如何处理协议升级，以及如何解决在旧软件版本下发起的争议。

可靠的安全说明应解释系统的局限和信任假设，而不是简单宣称 Rollup 继承了基础层的全部安全性。

关于欺诈证明的常见误解

一种常见误解是，每笔 Rollup 交易都会附带欺诈证明。

通常只有在参与者对争议结果提出挑战时，才会生成欺诈证明。

另一种误解是，欺诈证明可以证明存在犯罪或不诚实意图。

该机制证明的是计算或声明错误，而法律上的主观意图是另一个问题。

有些用户认为，提现等待一周意味着 Rollup 交易本身需要一周才能执行。

Rollup 交易可能在几秒钟内执行，而较长的等待期是用于结算和标准提现的安全保障。

还有一种误解是，无许可欺诈证明能够消除所有中心化控制。

Rollup 可以开放挑战，同时仍保留中心化排序、升级密钥、守护者或紧急暂停权限。

欺诈证明的风险

如果证明程序、虚拟机或智能合约存在漏洞，就会产生实现风险。

如果挑战者无法获取重建争议状态所需的信息，就会产生数据可用性风险。

如果诚实的欺诈证明交易无法在截止时间前进入结算区块链，就会产生审查风险。

如果恶意声明或软件故障延迟有效提现，就会产生活性风险。

如果 Gas 价格或保证金要求导致挑战成本过高，就会产生经济风险。

如果节点、证明程序、合约和初始状态未使用同一协议版本，就会产生升级风险。

如果特权方可以暂停、替换或覆盖争议系统，就会产生治理风险。

如果所有挑战者都依赖相同的云服务商、代码库、数据库或监控服务，就会产生运营风险。

常见问题

简单来说，什么是欺诈证明？

欺诈证明是用于证明拟议的区块链或 Rollup 结果计算错误的证据。

为什么加密系统要使用欺诈证明？

欺诈证明可以让链下计算帮助区块链扩容，同时为独立参与者提供驳回无效结果的途径。

欺诈证明与故障证明有什么区别？

这两个术语通常指相同机制，但“故障证明”不会暗示每个错误结果都是故意欺诈造成的。

哪些加密系统会使用欺诈证明？

欺诈证明主要用于乐观 Rollup，Plasma 系统和状态通道中也存在类似的争议机制。

每笔乐观 Rollup 交易都会生成欺诈证明吗？

不会。通常只有当参与者对错误的状态声明提出争议时，才会生成欺诈证明。

谁可以提交欺诈证明？

在完全无许可的系统中，任何人都可以提交；许可型系统则会将挑战权限限制在获批参与者范围内。

什么是挑战者？

挑战者是检查 Rollup 状态声明，并对不符合协议规则的声明提出争议的参与者或自动化服务。

什么是挑战期？

挑战期是拟议的乐观状态最终确定之前可以提出争议的一段时间。

欺诈证明的挑战期有多长？

时长取决于具体协议，但生产环境中的乐观 Rollup 常采用接近 1 周的挑战期。

乐观 Rollup 的提现为什么需要几天？

这段延迟为挑战者提供时间，以阻止基于无效或伪造 Rollup 状态进行的提现。

欺诈证明可以撤销交易吗？

根据 Rollup 的争议和恢复规则，欺诈证明可以使尚未最终确定的状态声明及其后续结果失效。

什么是交互式欺诈证明？

交互式欺诈证明通过多轮争议，将一项漫长计算逐步缩小到一个可在链上检查的小步骤。

欺诈证明中的二分查找是什么？

二分查找会反复划分执行轨迹，使争议双方能够定位结果首次出现分歧的位置。

什么是单步证明？

单步证明让结算合约验证一条存在争议的机器指令，并判定哪一方的计算正确。

什么是输出根？

输出根是对特定区块中 Rollup 状态及相关信息作出的加密承诺。

什么是一诚实方假设？

这是指至少有一名有能力的参与者会在截止时间前发现并挑战无效状态的假设。

欺诈证明系统需要许多验证者吗？

理论上一名诚实挑战者可能就足够，但多个独立挑战者能够增强运营韧性。

为什么需要数据可用性？

挑战者需要交易数据来重建 Rollup 状态，并准确证明错误状态转换发生的位置。

交易数据被隐藏时，欺诈证明还能运行吗？

如果重现执行需要这些隐藏数据，而协议又没有提供单独的数据可用性证明，欺诈证明可能会失效。

欺诈证明与有效性证明有什么区别？

欺诈证明是在受到挑战后证明结果错误；有效性证明则是在结果被接受前证明其正确。

欺诈证明是零知识证明吗？

不是。欺诈证明通常是一种乐观争议机制，但先进系统可以将故障证明与零知识技术结合使用。

Merkle 证明与欺诈证明相同吗？

不同。Merkle 证明用于证明数据包含在已承诺的数据集中，而欺诈证明用于证明计算或状态转换存在错误。

欺诈证明挑战成功后会发生什么？

无效声明会被驳回，正确状态得以保留，失败方可能会损失保证金。

挑战失败后会发生什么？

受到挑战的声明可以继续走向最终确定，未成功的挑战者可能会损失部分锁定资金。

为什么需要保证金？

保证金会让不诚实或轻率参与的行为付出财务代价，从而遏制虚假声明、垃圾信息和不必要的争议。

欺诈证明可以阻止排序器审查吗？

不能。欺诈证明验证执行是否正确，而抵御审查通常需要强制纳入路径和其他协议功能。

欺诈证明能防止智能合约被攻击吗？

不能。按照 Rollup 状态转换规则正确执行的恶意或有漏洞应用交易，仍可能被视为有效。

欺诈证明合约可能存在漏洞吗？

可能。证明程序、虚拟机、争议合约和挑战者软件都可能存在实现漏洞。

什么是延迟攻击？

延迟攻击试图延长争议解决时间或阻止有效结果最终确定，却无法成功证明状态错误。

什么是有时间限制的争议？

有时间限制的争议旨在即使提交了许多恶意声明，也能在可预测的最长时间内解决。

所有欺诈证明系统都是无许可的吗？

不是。有些网络会限制验证者或挑战者，而另一些网络则允许公众在满足技术和保证金要求后参与。

无许可欺诈证明系统仍可能设有管理员吗？

可能。紧急守护者、升级管理方、治理组织或安全委员会仍可能保留重要权限。

用户需要运行挑战者软件吗？

普通用户通常依赖独立验证者，但运行验证软件可以降低对其他参与者的依赖。

使用乐观 Rollup 前，用户应检查什么？

用户应检查欺诈证明是否已启用、谁可以提出挑战、数据存储在哪里、提现需要多久，以及哪些参与方拥有紧急权限。

结论

欺诈证明是一种争议机制，用于证明加密货币交易批次、状态转换、输出根或提现声明的计算存在错误。

它是乐观 Rollup 的核心安全组件，因为这类系统会暂时接受链下结果，而不要求立即提供有效性证明。

独立挑战者会重现执行过程，并在规定的挑战期内对错误声明提出争议。

交互式争议博弈可以将数百万个计算步骤缩小至一条由结算区块链直接验证的指令。

数据可用性至关重要，因为如果挑战者无法访问状态承诺背后的交易，就无法证明存在故障。

财务保证金可以遏制虚假声明，并补偿系统防御工作的一部分成本。

无许可欺诈证明能够降低对获批验证者的依赖，但不会消除所有治理、升级、排序或运营方面的信任假设。

欺诈证明与有效性证明不同：前者在受到挑战后驳回错误结果，后者则在结果被接受前证明其正确。

2026 年，生产环境中的故障证明系统仍在发展，包括更新证明客户端、采用有时间限制的争议协议，以及扩大无许可参与范围。

了解欺诈证明有助于加密用户评估 Rollup 安全性、提现延迟、数据可用性、挑战者假设，以及乐观区块链扩容的实际局限。