翻译文章来源

Coinbase 的 Fault Proof Deep-Dive 系列第一部分探讨了 FPVM 智能合约 MIPS.sol 以及它在 OP Stack 的 Fault Proof 系统中的运作方式。

Fault Proof Deep-Dive 系列是 Coinbase 区块链安全（BlockSec）团队与 OP Labs 之间的合作，旨在深入了解 Fault Proofs 的所有主要组成部分。通过分享这些信息，我们希望鼓励其他人更多地了解 Fault Proofs 的架构和技术方面。和我们一起朝着 OP Stack L2 区块链的去中心化未来迈进。

在这篇博客文章中，我们将介绍故障证明虚拟机（Fault Proof Virtual Machine，FPVM）智能合约 MIPS.sol。

什么是 MIPS.sol？

MIPS.sol 智能合约是一个虚拟机（VM）的链上实现，包含32位大端MIPS III指令集架构（ISA）。该智能合约与同一 ISA 的链下 MIPSEVM golang 实现相对应。链上和链下 VM 实现共同构成了 OP 的第一个 FPVM Cannon。

Cannon 是一个 FPVM 的实例，它被用于使用OP Stack技术的optimistic rollup L2 区块链的故障争议游戏（Fault Dispute Game）的一部分。

故障证明控制流程

先退一步，让我们简要地关注 MIPS.sol 合约在故障证明过程中的位置。

在上图中，我们重现了 Clabby 的故障证明演示视频

可以看到 MIPS.sol 合约与另外两个合约进行交互：FaultDisputeGame.sol 和 PreimageOracle.sol。FaultDisputeGame.sol 是一个活跃争议的故障争议游戏 (Fault Dispute Game) 的部署实例。PreimageOracle.sol 是一个预映像预言机的部署实例，它将存储所有使用相同 FPVM 的争议游戏的预映像。所以，在我们的例子中，所有使用 MIPS.sol 作为 FPVM 的游戏都有一个单独的 PreimageOracle.sol 合约。

MIPS.sol 合约由一个正在运行的争议游戏实例调用，并且只有当争议游戏在当前正在争议的状态转换树中到达叶子节点时才会被调用。叶子节点代表一个单独的 MIPS 指令（在我们使用 Cannon 作为 FPVM 的情况下），然后可以在链上运行。根据先前约定的 L2 状态和在MIPS.sol 合约中运行的指令状态，故障争议游戏可以确定真实的后状态。通过比较叶子节点处争议的后续状态和争议游戏实例中对手提出的后状态，这个真实的后状态将被用来解决故障争议游戏。

名词解释：Fault Dispute Game 是一个术语，通常用于描述在博弈论中的一种情况。在这种情况下，参与者争论彼此之间谁应该为某个失败或错误负责，并尝试通过博弈的方式来解决这个责任分配问题。在这个游戏中，参与者可能会根据不同的策略和利益来竞争或合作，以达成最终的解决方案。当被应用于区块链系统时，主要指用于处理和解决节点之间的冲突和错误的机制。这种机制允许系统中的参与者对其他参与者的行为进行质疑，并通过一种被称为"争议解决"的过程来确定哪个参与者是错误的。

智能合约控制流程

MIPS.sol 智能合约有一个独立的入口点：step() 函数。这是由正在运行的争议游戏调用的函数，它将在链上执行单个 MIPS 指令。从高层次上看，将执行以下操作：

1. VM 执行状态数据输入被解析并加载到内存中。该数据由 Cannon golang 对应项生成，游戏参与者通过 OP-Challenger 在链外运行。

2. 读取并验证内存证明输入。这个内存证明指向内存中的一个位置，下一个 MIPS 指令应该从这个位置加载并运行。

3. 执行下一条 MIPS 指令。 MIPS.sol 合约中的大部分逻辑根据 MIPS III 规范处理执行 MIPS 指令。在处理MIPS指令时，唯一不遵循严格规范的指令是SYSCALL（系统调用）指令。系统调用的行为对于操作系统来说是唯一的，对于MIPS.sol，可以执行的系统调用仅占系统调用总数的一小部分。系统调用的主要目的是处理对 PreimageOracle.sol 合约的读取并模拟对合约的写入。

4. 指令的结果可以写回寄存器或存储器。在写入内存的情况下，争议游戏将提供第二个内存证明作为输入。第二个内存证明应与内存中预期写入的位置一致，MIPS.sol 智能合约将使用新值和内存证明来计算新的内存默克尔根。

MIPS 指令完成后，状态散列将返回到争议游戏实例。状态哈希是 VM 执行状态的 keccak256 哈希，其中第一个字节不对应于哈希，而是用一个值覆盖以指示 VM 的状态。争议游戏将使用状态哈希和VM状态来解决争议。

MIPS.sol 合约状态

如前所述，MIPS.sol 合约与其他两个智能合约交互：FaultDisputeGame.sol 和PreimageOracle.sol。 FaultDisputeGame.sol 合约提供当前虚拟机执行状态以及最多两个内存证明。 PreimageOracle.sol 合约提供了 MIPS.sol 可以使用的预映像来帮助确定真实的 L2 状态。预映像中导出的内容可能包括来自 L1 和 L2 的数据，这些数据可以是区块头、交易、收据、合约状态等。

这两个合约共同提供了执行单个 MIPS 指令所需的所有相关信息。 MIPS.sol 合约不会在存储中存储有关指令执行的任何信息。这样，任何故障争议游戏都可以使用该合约，而无需重置任何值。因此，MIPS.sol 合约仅确保根据提供的内存证明计算出的 Merkle 根等于 VM 执行状态下的 Merkle 根。否则，将由FaultDisputeGame.sol合约来确保争议游戏参与者提供的信息和采取的行动的正确性。

MIPS.sol 合约的文档

我们对 MIPS.sol 智能合约的深入研究到此结束。除了这篇博文之外，Coinbase 还创建了更深入的文档，提供了智能合约中每个功能的详细信息，列出了 FPVM 支持的 MIPS 指令等等。

更多细节，请查看

找到我们

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

关注 Twitter: https://twitter.com/OptimismChina

加入 TG: https://t.me/optimism_cn

关注 Mirror: