如何检查Rollup故障证明是否启用
要检查一个Rollup是否启用了故障证明（Fault Proof），最直接的方法是查看其官方文档或开发者公告，明确说明"Fault Proofs"已上线并激活。例如，Optimism于2024年6月10日正式在主网激活了无需许可的故障证明系统。这套系统允许任何人无需许可地提交和挑战关于L2状态的提案，是保障资金安全的关键防线。
为什么需要检查故障证明？
在Optimistic Rollup中，系统默认所有的状态转换都是有效的，但会提供一个 "争议期"（Challenge Period） 。在这段时间里，任何人都可以提交"故障证明"来证明某个状态转换是错误的。
开启的意义：如果系统开启了故障证明，意味着任何人都可以挑战无效的提现或状态提案，这是实现"无需信任"安全模型的关键步骤。
关闭的风险：如果故障证明系统未激活（例如处于开发过渡期），则意味着网络的安全性可能更依赖于项目方的中心化组件或信任假设，用户提现资产的安全性保障较弱。
具体怎么检查？
你可以通过以下途径进行排查：
情况A：查看官方技术文档与公告（最权威）
官方文档是判断是否上线的第一手资料。
查找"Fault Proofs"关键词：访问Optimism或Arbitrum等项目的官方文档或开发者文档，搜索"Fault Proof"或"争议游戏"（Dispute Game）。
确认激活公告：官方通常会发布公告说明激活时间。例如，Optimism明确宣布，2024年6月10日，故障证明已在OP主网上正式激活。如果查询时文档仍写着"开发中"或"测试网"，则可能未正式启用。
完成标准：在项目方官网或官方技术文档中，找到明确说明"Fault Proofs are enabled"或"Permissionless challenges are live"的字样。
情况B：关注挑战者（Challenger）程序的配置
对于开发者或链运营者，可以检查是否部署了挑战者组件。以OP Stack链为例，运行一个 op-challenger 服务是保障网络安全的关键一步。官方教程明确指出，在部署完排序器（Sequencer）和提交者（Proposer）之后，最后一步就是配置挑战者来监控和响应争议。
工作原理：
op-challenger会监控DisputeGameFactory合约生成的争议游戏，当它发现无效的状态提案时，会发起挑战，通过交互式争议游戏来解决纠纷。
完成标准：如果你在链的运营组件中看到了活跃的op-challenger服务，且其正在通过DisputeGameFactory合约参与争议游戏，说明该链的故障证明机制是激活且有效的。
核心运作机制与风险
一旦故障证明开启，任何人都可以成为"提案者"（Proposer）或"挑战者"（Challenger），这就是所谓的无需许可（Permissionless） 状态。在OP主网上，争议窗口约为7天。
关键角色：
op-proposer自动提交状态根（Output Root）提案；op-challenger监测并挑战这些提案。经济博弈：挑战者提交提案时需质押保证金（Bond），如果挑战成功，会获得奖励。这确保了挑战者有经济动力去维护网络安全。
安全提示：如果在查询时，官方文档或公告没有明确提及故障证明已激活，甚至明确表示为"开发中"或"已禁用"，则意味着你对该链的资金操作（尤其是提现）需要依赖项目方的信任假设，而非纯粹的代码博弈。
确认完成
完成上述检查后，你可以确认当前网络的安全模型。例如，对于OP主网，确认"无需许可的故障证明系统已于2024年6月10日激活"这一事实，即可认为该链具备这一层安全防护。如果你使用的是其他兼容OP Stack的链，请查阅其各自的官方文档来确认该功能是否启用。
