从零到英雄：OP Stack容错证明系列 1 [ENG]

从零到英雄：OP Stack 欺诈证明系列 1 [ENG]

Optimism 多重证明架构中的欺诈证明机制

Tokamak Network 旨在为当前对 Optimism 和 Ethereum 生态系统的发展感兴趣的开发者提供有价值的信息。

来源：Oplabs 链接

本文是 Tokamak Network 计划发布的 3 篇文章“OP Stack 欺诈证明完整版本系列”的第一篇。本文介绍了 Optimism 的欺诈证明程序，详细介绍了其多重证明架构如何通过集成强大的欺诈证明机制来提高 Layer 2 的安全性和可靠性，以实现准确的状态转换和高效的争议解决。

💡 鉴于该系列的互连性，我们建议按顺序阅读这些文章，以便获得连贯的理解。

系列 2. Cannon 的欺诈证明系统： 在本文中，我们概述了 Cannon (Optimism 的 FPVM)，它通过链下执行和链上验证来确保 Layer 2 状态转换的完整性。MIPS.sol、MIPSEVM 和 PreimageOracle 等关键组件协同工作，以实现高效的争议解决。[LINK](https://learnblockchain.cn/article/17376) ]

系列 3. 欺诈争议游戏 (FDG) / 二分游戏： 在本文中，我们探讨了 Optimism 的欺诈证明系统如何使用链上 (MIPS.sol) 和链下 (MIPSEVM) 组件来解决 Layer 2 状态争议。我们介绍了提议者和挑战者的角色、PreimageOracle 的数据管理以及确保完整性和安全性的激励结构。此外，我们解释了二分游戏，它将争议分解为单个指令以进行精确验证。[LINK](https://learnblockchain.cn/article/17377) ]

升级提案：欺诈证明

图. “升级提案：欺诈证明”提案的截图（来源：gov.optimism.io 链接）

Optimism (OP) Stack 通过引入欺诈证明进行了重大升级，旨在提高 Optimism 网络的安全性与可靠性。此升级名为“升级提案：欺诈证明”，于 2024 年 6 月 10 日 在 OP Mainnet 上启动，此前已获得治理部门的批准。

核心变更

挑战期变更：

• 欺诈证明升级必须等待 7 天的挑战期才能最终确定。
• 对有效性提出质疑的提款将额外延迟 3.5 天。如果有效提案上的质疑被认为是恶意的，延迟可能会延长最多 9 天，这对挑战者来说代价高昂。（这种情况预计很少发生。）
• 标准提款完成时间：7 天（不变）
• 如果收到有效性质疑：额外 3.5 天
• 如果有效提案受到恶意质疑：最多额外 9 天

💡 可能的最大提款延迟：7 + 3.5 + 9 = 19.5 天

提款流程变更

• L2OutputOracle 已被删除，并由 OptimismPortal 和 DisputeGameFactory 取代。
• 开发者使用这些输出证明他们的提款发生在 L2 上。
• 随着欺诈证明的引入，开发者需要修改他们的客户端软件，以在两步提款流程的第一步中证明提款。

L2OutputOracle

• 随着欺诈证明 Mainnet 升级，OptimismPortal 将指向 DisputeGameFactory 合约，而不是 L2OutputOracle 合约。
• 对于开发者来说，最重要的变化是，需要针对争议游戏的 rootClaim 证明提款，而不是引用 L2OutputOracle 合约中的输出。

OptimismPortal

• 在 L1 上用于执行存款和提款的 OptimismPortal 智能合约正在改变其方法。
• 以前，开发者引用 L2OutputOracle 来查找包含其提款的确切输出。
• 现在，开发者必须使用 OptimismPortal 合约来确定 respectedGameType，并使用此信息从 DisputeGameFactory 查询具有正确 GameType 的最新 DisputeGame 合约列表。

DisputeGameFactory

• 建议开发者搜索合理数量的最新游戏（例如 100 个最新游戏），并选择具有足够区块编号的第一个提案。
• 然后，他们应该在本地验证此提案。
• 默认 GameType 将允许无需许可的提案（任何人都可以提交提案），因此不再强烈保证提案是有效的。

什么是欺诈证明？

欺诈证明，也称为错误证明或交互式游戏，是在区块链系统中使用的一种机制，尤其是在 Layer 2 Rollup 中，用于验证状态转换的正确性。它们通过结构化流程检测和解决争议，从而确保 Layer 2 网络上数据和计算的有效性和安全性。欺诈证明通过提供一种挑战和验证状态转换的方法来增强 Rollup 的安全性和完整性。

欺诈证明系统的关键组成部分

欺诈证明程序 (FPP) 负责生成欺诈证明。它识别声明的后状态与从前状态和见证数据导出的实际状态之间的差异。本质上，它验证输出提议者提出的状态转换的正确性。

欺诈证明虚拟机 (FPVM, Cannon) 是一种专门的虚拟机，用于执行欺诈证明程序。它提供了一个安全且确定性的环境来运行 FPP，确保网络中的所有参与者都可以一致且可验证地进行欺诈证明。

• FPP 专注于执行和验证状态转换，而 FPVM 提供环境以确保正确且可验证地执行这些执行。

争议游戏协议 是一种解决对状态转换存在分歧的机制。当挑战者发现差异并提交欺诈证明时，将触发争议游戏协议。该协议涉及一系列交互和验证，以评估欺诈证明的有效性。如果证明有效，则会拒绝不正确的状态转换，从而确保区块链的完整性。

💡 这三个组件中的每一个都可以以不同的方式实现，这些不同的实现可以组合成各种证明栈，从而有助于解决争议时的证明多样性。

分层区块链系统中的欺诈证明机制

图. Op-stack 中的角色和数据流

网络

Layer 1(以太坊)：基础层，包含存储交易数据和状态更改的区块序列。

Layer 2(Optimism)： Layer 2 从 L1 读取标头、交易和收据。这些 L1 元素将转换为 Layer 2 可以处理的有效负载属性。

• L2 共识层处理从 L1 派生的有效负载属性。
• L2 执行层使用这些属性来执行交易和更新状态。

核心组件

Rollup：排序器负责对交易进行排序（收据）。

Batcher：一个收集交易并将其批量提交到 Layer 1 的实体。此过程有助于确保 Rollup 系统中的效率和成本效益。

Verifier：一个通过验证 Layer 2 是否完全从 Layer 1 派生来确保排序数据的准确性和一致性的实体。验证者检查批量交易和计算，提交证明或验证以确认 L2 上的状态转换正确地反映了 L1 上的状态转换。如果在验证过程中发现任何问题，验证者还会提醒挑战者解决这些差异。

输出提议者：一个专门的验证者，负责处理来自 Layer 1 的数据并推导出 Layer 2 的相应结果。然后，输出提议者将这些结果发回 L1，断言“这是在处理后从 Layer 1 推导出的结果。”

挑战者：如果验证者不同意输出提议者所做的状态或声明，它将承担挑战者的角色。挑战者会监控 L1 上输出提议者所做的不正确声明。如果检测到不正确的声明，挑战者会提交反提案以更正它，从而确保排序数据的完整性和正确性。

单个节点可以同时执行验证者和挑战者的角色。这意味着一个节点可以验证交易，同时挑战其他验证者的验证结果。此系统旨在增强网络的安全性和公平性。验证者和挑战者角色的分离或并发执行为网络参与者提供了各种激励，有助于减少不正确的验证，并维护网络的完整性。因此，虽然同一节点可以同时履行这两个角色，但重要的是要理解每个角色根据具体情况发挥不同的作用。

💡 欺诈证明对于维护 Rollup 流程的完整性至关重要，它确保输出提议者所做的任何不正确声明都由挑战者识别和更正。单个节点可以同时执行验证者和挑战者的角色，这意味着一个节点可以验证交易，同时挑战其他验证者的验证结果。

状态转换过程

图. 状态转换和争议过程

约定的前状态：这是网络中每个人都同意的初始状态。它是状态转换的起点。

见证数据：从 Layer 1 派生的新数据，包括标头、交易和收据，这些数据被输入到 Layer 2 系统进行处理。

有争议的后状态：已由挑战者声明并需要验证的输出状态。此状态是将见证数据应用于约定的前状态的结果，并且需要进行质疑和验证。

状态转换程序 (FPP)： 此程序采用约定的前状态并应用见证数据以在本地环境中生成下一个状态。该过程包括以下几个步骤：

1. 从约定的前状态中提取和处理 L1 标头、交易和收据。
2. 从 L1 数据中派生 L2 有效负载属性。
3. 在 L2 共识层中应用 these 属性，以排列交易序列，就像交易在 L1 上处理的一样。
4. 使用执行层来处理此排序的序列并生成新状态。

验证过程：

1. 将本地状态转换程序生成的状态与目标后状态进行比较。
2. 如果它们匹配，则无需进一步操作。
3. 如果它们不匹配，则开始争议游戏以解决差异。

多重证明架构

图. 多重证明架构的自我定制模型

多重证明架构是由 Optimism 开发的一个框架，旨在增强 Layer 2 解决方案的安全性和可靠性。此架构集成了多种欺诈证明机制，允许根据特定需求自由混合搭配和自定义各种组件。通过利用这些适应性强的组件，多重证明架构可确保 L2 状态转换的准确性和可验证性，从而为 Layer 2 操作提供一个强大且值得信赖的环境。这种灵活性使用户可以定制架构以满足不同的需求，从而提高系统的安全性和效率。

关键组件及其角色：

Op-node：

角色： 充当 Layer 2 环境中的协调器。

• 区块创建：管理新区块的创建。
• 区块验证：验证新创建的区块。
• 区块传播：确保区块在网络中传播。
• L2-L1 交互： 管理 Layer 2 和 Layer 1 之间的交互，确保无缝通信和数据传输。

其他版本： Magi 是 Optimism OP Stack 的一个新rollup客户端，用 Rust 编写，旨在通过提供现有 Op-node 客户端的替代方案来增强网络安全性和弹性。它充当共识客户端，向执行客户端提供新区块以推进链，并旨在提高 rollup 网络中的客户端多样性和去中心化。Magi 目前正处于早期开发阶段，正在寻求贡献以改进同步速度和数据可用性等功能，最终目标是成为一个强大、可用于生产环境的客户端。

Op-geth：

角色： 基于以太坊的 Go 客户端 (Geth)，Op-geth 主要处理交易的执行和验证。

• EVM 执行： 执行以太坊虚拟机 (EVM) 操作。
• 智能合约处理： 处理智能合约。
• 交易验证： 验证 Layer 2 环境中的交易。
• 状态转换： 管理状态转换以确保正确执行和反映它们。

💡 总而言之， Op-node 和 Op-geth 协同工作以确保 Layer 2 中的状态转换被正确排序和执行。 Op-node 协调整个过程，而 Op-geth 执行执行 EVM 操作和验证交易的关键任务。

Cannon：

角色： 在 Optimism 的欺诈证明系统中充当欺诈证明虚拟机 (FPVM)。

• 执行跟踪生成： 在 MIPS32 架构上模拟一个最小的基于 Linux 的系统，以生成状态转换的执行跟踪。
• 数据收集： 从外部服务器收集数据，以确保执行跟踪可以由其他人重现和验证。
• 链上欺诈证明创建： 允许创建具有可验证指令的链上欺诈证明。
• 完整性保证： 通过提供一种可靠的机制来验证执行跟踪，从而确保 Layer 2 状态转换的完整性。

其他版本： Asterisc (RISC-V) 是 OP Stack 的一个实验性欺诈证明 VM，它使用 RISC-V 程序来创建交互式欺诈证明，与 Cannon 兼容，但专为更广泛的未来应用而设计。它包括一个基于 Go 的 RISC-V 模拟器 (rvgo) 和一个用于链上执行的 Solidity/Yul 镜像 (rvsol)，支持 32 位和 64 位指令集，但为了简单和确定性而避免了复杂的操作。Asterisc 专注于极简性、安全性和一流的 Golang 支持，使其成为 Cannon 的一个更简单、面向未来的替代方案，目前已完成约 80%。

“设置”和“最终确定”

图. Op-program 服务器/客户端和 FPVM 的交互流程

Op-geth (op-program 服务器)：

角色： 通过 RPC 与 Layer 1 和 Layer 2 交互的服务器组件。

功能： 充当 PreimageOracle 服务器，为欺诈证明计算提供必要的预映像数据。

FPVM — 欺诈证明虚拟机 (Cannon)：

角色： 生成执行跟踪。

功能： 从外部服务器收集数据以允许跟踪重现。这些跟踪用于创建可验证的链上欺诈证明，从而确保虚拟机的执行完整性。

Solidity 实现：

• Cannon 包括 MIPS 的 Solidity 实现。
• 此实现使用几百行代码验证单个指令。

Go 实现：

• Cannon 还包括 MIPS 的 Go 实现。
• 此实现用于有效地生成见证数据并有效地处理数十亿条指令。

使用 Cannon：

1. 托管 OP 程序以从 Layer 1 和 Layer 2 节点收集数据。
2. 收集的数据用于创建预映像。
3. 这些预映像提供给 Cannon。
4. Cannon 将预映像传递到模拟程序中。
5. 该程序处理以太坊数据并生成证明结果。

Op-node (op-program 客户端)：

• 角色： 处理设置、数据派生和最终确定的客户端。
• 功能： 与预映像 oracle 客户端配合使用，以确保准确的数据转换和欺诈证明验证。

FPP 的详细步骤

①. 从 L1 开始初始化：

• 从第一个预映像开始： 此步骤使用 Layer 1 中的初始状态开始该过程。“第一个预映像”是初始数据或状态，用作所有进一步计算的起点。

②. 同步输入：

• 耦合 L1 和 L2 输入： 在这一步中，来自 Layer 1 和 Layer 2 的输入被同步。这种耦合确保 L1 上记录的数据和交易准确地反映在 L2 中。此步骤对于维护两个层之间的一致性和正确性至关重要，确保 L2 状态转换基于最新的 L1 数据。

③. 导出 L2 区块输入：

图. 推导管道中与数据流相反的执行优先级。

• 利用 Op-Node 推导管道： 此步骤涉及通过 Op-node 推导管道处理同步的输入。该管道处理耦合的 L1 和 L2 输入，以生成创建新 L2 区块所需的数据。此派生数据包括构建有效 L2 区块所需的所有信息，确保状态转换的准确性和完整性。

💡 推导管道：排序器生成 L2 区块，批量提交者压缩并将生成的 L2 区块信息发送到 L1。基于发送到 L1 的信息重建 L2 链的过程称为“区块推导”。这使验证者能够对排序器生成的区块执行健全性检查。 更多详细信息

④. 处理 L2 区块输入：

• 通过执行引擎执行： 派生的输入通过执行引擎处理，该引擎执行必要的计算以生成有效 L2 区块（在本地环境中）。执行引擎确保计算遵守协议中定义的规则和逻辑，从而实现准确的状态转换和区块创建。此步骤对于维护 L2 区块链的完整性至关重要。

⑤. 计算 L2 区块输出：

• 确定输出根： 最后一步是计算输出根，它表示处理 Layer 2 区块后的最终状态。此输出根对于未来的计算和状态转换至关重要，确保它们被正确记录和可验证。该过程涉及将排序器提交的输出根与本地环境中欺诈证明程序 (FPP) 生成的输出根进行比较，以验证准确性。

💡 FPP 基于交互式二分游戏，促进了从前状态到后状态的状态转换。它涉及：

• 引用最新的 Layer 1 数据： 确保所有数据都是最新的并已发布。
• 利用约定的状态： 以无争议的状态为基础，以实现清晰性和一致性。
• 这种设置提高了透明度和准确的状态转换。FPP 认真地处理每个步骤，确保从 Layer 1 到 Layer 2 的可靠和可验证的转换。

结论

“升级提案：欺诈证明”是 Optimism (OP) Stack 的一项重大进步，它通过确保正确的状态转换和高效的争议解决来提高网络安全性和可靠性。主要变更包括调整了挑战期限、彻底修改了提款流程，以及用 OptimismPortal 和 DisputeGameFactory 替换了 L2OutputOracle。欺诈证明程序 (FPP)、欺诈证明虚拟机 (FPVM, Cannon) 和争议游戏协议以及多重证明架构的集成，巩固了系统的稳健性。此升级增强了开发者和用户之间的信任，从而加强了 Optimism 作为领先 Layer 2 解决方案的地位。

参考

升级提案：欺诈证明

• https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/12
• https://blog.oplabs.co/the-fault-proof-system-is-available-for-the-op-stack/

Youtube

https://www.youtube.com/watch?v=RGts3PSg4F8

文档

• https://docs.optimism.io/builders/notices/fp-changes
• https://docs.optimism.io/stack/protocol/fault-proofs/overview
• https://docs.optimism.io/stack/protocol/fault-proofs/mips
• https://learnblockchain.cn/article/17386
• https://medium.com/tokamak-network/optimism-bedrock-wrap-up-series-4-eng-c08e1c0dd069

• 原文链接： medium.com/tokamak-netwo...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～