OP Labs 与 Coinbase 的故障证明（Fault Proof）深入研究系列的第二部分，是对 Cannon 的概述。Cannon 作为争议游戏（Dispute Game）的一部分，是 OP Stack 的第一个故障证明虚拟机(FPVM)。

原文链接:

故障证明深入研究系列是 Coinbase 的区块链安全团队( BlockSec )与 OP Labs 之间的合作项目，旨在提供有关故障证明所有主要组件的详细信息。我们希望鼓励其他人，通过这些信息去学习更多关于故障证明的架构和技术细节。一起迈向由 Op Stack 构建的 Layer 2 区块链网络的去中心化未来。

在这篇博文中，我们将介绍 Cannon 的链下故障证明虚拟机 （FPVM）部署情况。需要注意的是， Cannon 是由链上与链下的故障证明虚拟机（FPVM）共同组成的。但是，文中我们仅通过链下部署（的虚拟机）来描述二者。

什么是 Cannon？

在上篇博文[2]中，我们已经介绍了 MIPS.sol，即链上的故障证明虚拟机（ FPVM ）。Cannon 是链下版本的 MIPS.sol，由 Golang（一种静态型，编译型高级编程语言）编写。然而，与 MIPS.sol 不同的是，链下部署的 Cannon 在争议游戏中负责了更多步骤。此外，Cannon 是 OP Stack 里唯一用于争议游戏（争议游戏属于故障证明的组件）的故障证明虚拟机（FPVM）。

故障证明的控制流程

让我们再次回顾一下故障证明的流程，以了解 Canoon 的所在位置。

上图截取自 Clabby 讲解的视频《故障证明演示》[3]，我们可以看到 Cannon 与 OP-Challenger 和 OP-Program 之间的交互情况。OP-Challenger 是负责发起挑战并与争议游戏进行交互的组件，OP-Program 则负责将 Layer 1（即 Layer 1 网络，是底层区块链的别称。币安智能链、以太坊、比特币和 Solana 都属于 Layer-1 协议，也称之为 Layer 1）的内容进行计算然后在 Layer 2（即 Layer 2 网络，指基于 Layer 1 的链下网络、系统或技术，目的是为了扩展 Layer 1）输出。然而，上图对 OP-Challenger，Cannon 和 OP-Program 之间的交互进行了简化。

在一个活跃的争议游戏（Dispute Game）过程中，二分游戏（the bisection game）将从 Layer 2 输出根的状态转换至状态见证哈希（state witness hashes）。Cannon 的职责是生成对故障证明虚拟机（FPVM）中 MIPS 指令计算结果负责的状态见证哈希。只有当争议游戏进行到该点时，Cannon 才会运行。二分游戏的这一部分被称为执行轨迹。到目前为止，OP-Challenger 一直在向 OP-Node （OP Stack 中最重要的模块）请求状态输出根，并尚未使用 OP-Program 或 Cannon。然而，一旦到了运行 Cannon 进行争议游戏的时候，已经编译好的 OP-Program 将被加载到 Cannon 的虚拟机（virtual machine，VM）中，然后开始执行 MIPS 指令。

在二分游戏的执行追踪阶段，Cannon 将要运行多个 MIPS 指令，并且在最开始就要向 OP-Challenger 发送状态见证哈希。最终，一个统一的 MIPS 指令将成为当前争议中各方分歧的根源。目前，Cannon 将生成一个见证证明，其中包含执行 MIPS.sol 合约中所有 MIPS 指令所需的信息。接下来，将使用最终的 MIPS 指令状态来解决故障争议游戏。

Cannon 组件概述

Cannon 具备比链上故障证明虚拟机（MIPS.sol）更多的功能，这都归功于它由多个 Golang 编写的文件组成。然而这是必要的，因为 Cannon 在争议游戏中要比 MIPS.sol 肩负更多职能。这些 Golang 文件按照它们实现的 Cannon 核心组件进行分组，其中包括：可执行和可链接文件格式（the Executable and Linkable Format ，ELF）加载器、内存和状态管理、MIPS EVM（后面会做详尽说明）以及见证证明（witness proof ）生成。

可执行和可链接格式（ELF）加载器

OP-Program 是被编译成 ELF 文件的代码，该文件包含可在 Cannon 内运行的 MIPS 指令。为了将 ELF 文件中的内容加载到 Cannon 中运行，需要将其加载到 MIPS EVM 中。这个过程包含遍历（指在编程中通过循环逐个访问集合中的元素或执行一系列操作）ELF 文件头以确定需要加载到 32 位内存空间的所有程序，为程序计数器( PC )和下一条要执行指令的地址( NextPC )的确定初始值，在内存中实例化栈、堆和数据段指针，以及移除任何不兼容的函数。修补不兼容的函数时，只需将函数内的前几条指令覆盖为返回到原始指针的指令，然后加上若干个空操作（ NOP，no-operation ）即可。对加载到 MIPS EVM 中的二进制文件进行打补丁很重要，因为 FPVM 无法执行多系统调用，也不支持并发等功能。

内存和状态管理

Cannon 储存并维持了 MIPS EVM 所需的整个 32 位内存地址空间。存储在链下内存的数据大小不受限制，但对于 MIPS.sol 来说，存储整个 32 位内存地址空间是不可行的。因此，Cannon 将内存存储在一个二进制 Merkle Tree数 据结构中。对于 MIPS EVM 来说，该数据结构是通过使用  GetMemory()、ReadMemoryRange() 和 SetMemory() 函数抽象出来的。当需要生成见证证明时， Cannon 将为 MIPS.sol 生成多达两个内存默克尔（Merkle）证明，以便在执行 MIPS 指令时使用。

MIPS EVM

在 Cannon 内部，存在一个名为 MIPS EVM 的组件，它实现了 32 位、大端模式的 MIPS III 指令集架构( Instruction Set Architecture，ISA )。与 MIPS.sol 不同，MIPS EVM 能够执行多种 MIPS 指令，并负责跟踪内存访问，这将用于编码第二份内存证明。然而，无论是链下还是在链上虚拟机实现都必须在给定指令、内存和寄存器状态下产生完全相同的结果。这对于确保预期的 MIPS EVM 后状态与由 MIPS.sol 实际生成的后状态相同至关重要，后者将用于解决争议游戏。

见证证明生成

一旦确定了 MIPS 指令在故障争议游戏中引起争议，Cannon 将生成见证证明，以便在链上的 MIPS.sol 上执行相同的指令。见证证明中包含编码信息，包括虚拟机执行状态、运行该指令地址的内存证明，以及用于加载、存储或某些系统调用指令的额外内存证明。此外，如果 MIPS 指令需要预映射，则 Cannon 还会与 OP-Challenger 进行通信，并传递预映射密钥和偏移量，以便将其发布到链上并存储在 PreimageOracle.sol 上。

Cannon 的文档

这是我们对 Cannon 的深入讨论。除了这篇博文外，Coinbase 还创建了详细的文档，提供了有关 Cannon 各个组件的更多细节。请访问**故障证明虚拟机 - Cannon | Optimism Docs[4]** 查看相关内容，如果您对 Optimism 的 Cannon 官方技术规范感兴趣，请访问 Cannon技术规范[5]查看。

找到我们

OP 中文力量是由 GCC、LXDAO、PlanckerDAO，登链社区和 TraDAO 共同发起的 Optimism 中文开发者社区，是一个传播 Optimism 技术和公共物品理念的组织，旨在成为链接华语社区和 Optimism 生态的桥梁，促进 Optimism 生态和华语社区内的双向交流，促进公共物品的繁荣。

OP 中文力量是 GCC 中文力量计划旗下专注 OP 生态的中文社区，由 GCC 捐助孵化成立。

Notion：https://www.notion.so/lxdao/Optimism-99a78f831195451a9f16724342c0c4ed

Telegram：https://t.me/optimism_cn

Mirror: https://mirror.xyz/optimismcn.eth

支持社区