OP Labs｜游戏开始了：为 OP Stack 的故障证明系统设计模块化争议游戏

OP 中文力量
更新于 2024-08-23 16:12
阅读 220

译者的话这篇文章详细介绍了OPStack中的争议游戏和故障证明系统，这些技术对于加强区块链的安全和可靠性至关重要。通过争议游戏，我们不仅可以更深入地理解区块链技术如何通过各种算法和协议保护数据的完整性，还能看到开发者如何在这一领域实验新的解决方案。我希望这篇翻译不仅能帮助读者理解OPS

# **译者的话**

这篇文章详细介绍了 OP Stack 中的争议游戏和故障证明系统，这些技术对于加强区块链的安全和可靠性至关重要。通过争议游戏，我们不仅可以更深入地理解区块链技术如何通过各种算法和协议保护数据的完整性，还能看到开发者如何在这一领域实验新的解决方案。

我希望这篇翻译不仅能帮助读者理解 **OP Stack 的复杂机制**，也能激发更多开发者加入并贡献于这个充满活力的技术领域。无论你是区块链的新手还是经验丰富的专家，理解和参与到这样的技术进步中，都是一次非常宝贵的学习和成长机会。

此外，这篇文章还提供了实际参与争议游戏的具体方法，包括设置和运行环境的详细步骤，这对于那些希望亲手体验和测试这些技术的开发者来说，是一个非常实用的指南。希望我的翻译能为你探索这一激动人心的技术世界打开一扇门。

原文来自

[![The game’s afoot: designing modular dispute games  for the OP Stack’s Fault Proof System](https://blog.oplabs.co/content/images/size/w1200/2023/09/Concept-2.png)](https://blog.oplabs.co/dispute-games/)

[The game’s afoot: designing modular dispute games for the OP Stack’s Fault Proof System](https://blog.oplabs.co/dispute-games/)

# **目录**

本文一共有 3000 字，一共有个 3 部分，阅读完本文预计需要 20 分钟。

1. 什么是争议游戏
2. 体验字母二分法游戏
3. 帮助维护 OP Stack 争议协议

OP Stack 故障证明系统（FPS）中最有趣的部分之一就是其**争议游戏**，而这并非巧合。以往关于 FPS 的帖子已经阐述了 OP Stack 模块性的优势，使得故障证明程序（FPP）与故障证明虚拟机（FPVM）的分离成为可能，从而实现更高级别的组合性和对这两个组件的高效并行升级。争议游戏同样具有模块性的优势，几乎到了指数级的程度。

本文探讨了争议游戏在超级链生态系统的去中心化故障检测中发挥的作用，分析了争议游戏是如何在争议协议之上构建的，以及争议协议的可扩展性带来的可能性。

如果你想了解更多关于争议游戏的细节，请阅读这篇文章的 **[更长版本\[2\]](https://www.notion.so/8386677b52554a269cd95b8334f0ebfb?pvs=2)** 。

## **什么是争议游戏**

争议游戏是争议协议的一个核心原语，它模拟了一个简单的状态机，并且初始化时有一个 32 字节的承诺，该承诺针对的是任何有效性可能出现争议的信息。它们包含一个确定这一承诺为真或假的函数，具体由原语的实现者来定义。OP Stack 中争议游戏的第一个实现`FaultDisputeGame` 是一个无需许可的系统，因为其解决函数是由故障证明程序在模拟虚拟机上执行的结果所决定的。

争议游戏本身依赖于两个基本属性：

1. **激励兼容性（Incentive Comppatibility）**：系统惩罚虚假声明并奖励真实声明，以确保公平参与。
2. **解决机制（Resolution）**：每个游戏都有一种机制来最终确定或否定根声明的有效性。

在争议协议中，可以通过 DisputeGameFactory 创建、管理和升级不同类型的争议游戏。这为创新的功能打开大门，如聚合证明系统（aggregate proof systems），以及扩展协议以使 L2 状态之外的事物进行争议，例如专注于链上二进制验证的 `FaultDisputeGame`。

### **二分游戏（Bisection Game）**

这是一种特定类型的争议游戏，也是在 OP Stack 的争议协议中构建的第一个游戏。在这个游戏中，玩家反复进行二分，直到执行轨迹分解至单个步骤。在二分对单个轨迹指令的状态做出承诺后， `FaultDisputeGame` 会使用一个通用的虚拟机，在链上执行单个指令步骤。我们将虚拟机的状态转换函数称为 **T**，它可以是任何代码，只要遵循形式 **T(s, i) -> s'**，其中 **s** 是预先同意的前状态，**i** 是状态转换输入，**s'**  是转换后的状态。

在我们对二分游戏中的通用虚拟机进行的第一个完整实现中，我们在 EVM 之上实现了一个单 MIPS 线程上下文（single MIPS thread context），用于执行 `Cannon` 和 `op-program` 生成的执行轨迹中的单个指令。

### **声明（Claims）**

声明代表对给定指令处后端虚拟机状态的承诺，这些声明可能是真或假，其真实性在解决阶段后确定。如果没有反驳，声明被假定为真。

### **位置（Positions）**

声明存在于二叉树的位置中。位置代表与声明相关的指令。位置是泛化的索引，可以定义为 `2^{depth} + index_at_depth`。

### **计时器（Chess Clocks）**

玩家有限制的时间来进行移动。这个游戏是无需许可的，任何人都可以加入。每方开始时有 3.5 天的时间，总计 7 天的游戏时间。如果创建了新的路径或在已有声明的位置提出新声明，那么将继承祖父母级的计时器。

### **移动（Moves）**

玩家进行二分直到声明承诺只涉及一个虚拟机指令的状态。然后他们在链上执行该指令以验证或否定声明。移动可以是攻击（挑战父母级声明）或防御（与父母级声明达成一致）。当玩家同意他们正在观察的声明哈希（意味着双方在给定指令处的状态相同）但不同意他们基于观察到的声明与根声明的相对一致性所推断出的最终结果时，就会进行防御。

### **指令步骤（Instruction Step）**

在位置树的叶节点处，每个声明都只涉及对一个虚拟机指令状态的承诺。唯一剩下的移动是执行该虚拟机指令以证明或反驳父母级声明。

如果指令步骤确认了预期的转换后状态，则声明成立，不予反驳。如果出现意料之外的转换后状态或退出码（exit code），则对父母级声明进行反驳。

### **解决机制（Resolution）**

游戏可能在所有声明的计时器耗尽后得到解决，最低为 3.5 天。游戏中的每个声明都是其自己的**子游戏（Sub Game）的根。子游戏是深度为 1 的有向无环图（DAGs）。所有指向根的子级（它们本身也是子游戏的根）都是对它的反驳，只有在其自身所有的子代都已解决时，子游戏才可能得到解决。只有当一个或多个子级**得到解决且未被反驳时，子游戏的根才能被认为是可反驳的，这一属性向上延伸到游戏的根声明。

如果诚实的玩家已经使用完所有可能的移动，那么游戏的解决总会倾向于支持其对轨迹的视图，不论根声明本身是真是假。不诚实的声明可以被任何一方反驳，但总是应当只有一个正确的声明被提出，因为在同一个子游戏的相同位置，不允许有重复的声明哈希存在。

## **体验字母二分游戏**

对于那些感兴趣的人，我们提供了一个可视化工具，可以模拟一个仅包含 16 条指令的 `FaultDisputeGame` 的执行轨迹。这个模拟采用的是一个不同于 MIPS 线程上下文的虚拟机，称为 AlphabetVM，它会在接收到一个字母的输入后简单地返回字母表中的下一个字母。

如果你有兴趣了解这个游戏的规则，并且想要一个更简洁的后端，请看以下步骤：

克隆 Optimism 的 `monorepo`，安装依赖，并制作 devnet `allocations/cannon/op-program` 的二进制文件。

需要的依赖：

1. `foundry`
2. Golang 工具链
3. Docker

```
git clone git@github.com:ethereum-optimism/optimism.git && \\\\
	cd optimism && \\\\
  pnpm i && \\\\
  (cd packages/contracts-bedrock && forge install) && \\\\
  make cannon-prestate && \\\\
  make devnet-allocs
```

启动字母游戏：

```
cd op-challenger && make alphabet
```

导航至  [https://disputify.optimism.io  或通过克隆  **https://github.com/clabby/dispute-viz** 在本地运行可视化前端，并输入部署在您本地](https://disputify.optimism.xn--io%2A%2A%20%20%2A%2Ahttps-9p58ab37u2f5ljyblv4f//github.com/clabby/dispute-viz\*\*%C2%A0%E5%9C%A8%E6%9C%AC%E5%9C%B0%E8%BF%90%E8%A1%8C%E5%8F%AF%E8%A7%86%E5%8C%96%E5%89%8D%E7%AB%AF%EF%BC%8C%E5%B9%B6%E8%BE%93%E5%85%A5%E9%83%A8%E7%BD%B2%E5%9C%A8%E6%82%A8%E6%9C%AC%E5%9C%B0) devnet 上 `FaultDisputeGame` 代理的地址。

## **帮助维护 OP Stack 争议协议**

在一个二分游戏中，上述所有机制共同作用，以创建一个奖励诚实行为并有效地抵制不诚实声明的系统。

有许多方法可以构建实现相同目标的争议游戏。我们希望当 **OP Stack** 的 FPS 在 **OP Goerli** 上部署时，我们生态系统中的构建者能够在构建他们自己的争议游戏时玩得开心并发挥创造力。每一个创造的争议游戏都可以在 OP Stack 的社会去中心化中发挥作用，并为生态系统参与者在解决任何关于信息的声明的争议时提供选择。

### **找到我们**

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

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

**Twitter** ：https://x.com/Optimismzh

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

**Telegram**：<https://t.me/optimism_cn>

**Mirror**: <https://mirror.xyz/optimismcn.eth>

### **支持社区**

![](https://mirror.xyz/\_next/image?url=https%3A%2F%2Fimages.mirror-media.xyz%2Fpublication-images%2FRrT-wAlOw0957JiyybgyP.jpg\&w=3840\&q=75)

译者的话

我希望这篇翻译不仅能帮助读者理解 OP Stack 的复杂机制，也能激发更多开发者加入并贡献于这个充满活力的技术领域。无论你是区块链的新手还是经验丰富的专家，理解和参与到这样的技术进步中，都是一次非常宝贵的学习和成长机会。

原文来自

The game’s afoot: designing modular dispute games for the OP Stack’s Fault Proof System

OP Stack 故障证明系统（FPS）中最有趣的部分之一就是其争议游戏，而这并非巧合。以往关于 FPS 的帖子已经阐述了 OP Stack 模块性的优势，使得故障证明程序（FPP）与故障证明虚拟机（FPVM）的分离成为可能，从而实现更高级别的组合性和对这两个组件的高效并行升级。争议游戏同样具有模块性的优势，几乎到了指数级的程度。

如果你想了解更多关于争议游戏的细节，请阅读这篇文章的 更长版本[2] 。

什么是争议游戏

争议游戏是争议协议的一个核心原语，它模拟了一个简单的状态机，并且初始化时有一个 32 字节的承诺，该承诺针对的是任何有效性可能出现争议的信息。它们包含一个确定这一承诺为真或假的函数，具体由原语的实现者来定义。OP Stack 中争议游戏的第一个实现FaultDisputeGame 是一个无需许可的系统，因为其解决函数是由故障证明程序在模拟虚拟机上执行的结果所决定的。

争议游戏本身依赖于两个基本属性：

激励兼容性（Incentive Comppatibility）：系统惩罚虚假声明并奖励真实声明，以确保公平参与。
解决机制（Resolution）：每个游戏都有一种机制来最终确定或否定根声明的有效性。

在争议协议中，可以通过 DisputeGameFactory 创建、管理和升级不同类型的争议游戏。这为创新的功能打开大门，如聚合证明系统（aggregate proof systems），以及扩展协议以使 L2 状态之外的事物进行争议，例如专注于链上二进制验证的 FaultDisputeGame。

二分游戏（Bisection Game）

这是一种特定类型的争议游戏，也是在 OP Stack 的争议协议中构建的第一个游戏。在这个游戏中，玩家反复进行二分，直到执行轨迹分解至单个步骤。在二分对单个轨迹指令的状态做出承诺后， FaultDisputeGame 会使用一个通用的虚拟机，在链上执行单个指令步骤。我们将虚拟机的状态转换函数称为 T，它可以是任何代码，只要遵循形式 T(s, i) -> s'，其中 s 是预先同意的前状态，i 是状态转换输入，s' 是转换后的状态。

在我们对二分游戏中的通用虚拟机进行的第一个完整实现中，我们在 EVM 之上实现了一个单 MIPS 线程上下文（single MIPS thread context），用于执行 Cannon 和 op-program 生成的执行轨迹中的单个指令。

声明（Claims）

声明代表对给定指令处后端虚拟机状态的承诺，这些声明可能是真或假，其真实性在解决阶段后确定。如果没有反驳，声明被假定为真。

位置（Positions）

声明存在于二叉树的位置中。位置代表与声明相关的指令。位置是泛化的索引，可以定义为 2^{depth} + index_at_depth。

计时器（Chess Clocks）

移动（Moves）

指令步骤（Instruction Step）

在位置树的叶节点处，每个声明都只涉及对一个虚拟机指令状态的承诺。唯一剩下的移动是执行该虚拟机指令以证明或反驳父母级声明。

如果指令步骤确认了预期的转换后状态，则声明成立，不予反驳。如果出现意料之外的转换后状态或退出码（exit code），则对父母级声明进行反驳。

解决机制（Resolution）

游戏可能在所有声明的计时器耗尽后得到解决，最低为 3.5 天。游戏中的每个声明都是其自己的子游戏（Sub Game）的根。子游戏是深度为 1 的有向无环图（DAGs）。所有指向根的子级（它们本身也是子游戏的根）都是对它的反驳，只有在其自身所有的子代都已解决时，子游戏才可能得到解决。只有当一个或多个子级得到解决且未被反驳时，子游戏的根才能被认为是可反驳的，这一属性向上延伸到游戏的根声明。

体验字母二分游戏

对于那些感兴趣的人，我们提供了一个可视化工具，可以模拟一个仅包含 16 条指令的 FaultDisputeGame 的执行轨迹。这个模拟采用的是一个不同于 MIPS 线程上下文的虚拟机，称为 AlphabetVM，它会在接收到一个字母的输入后简单地返回字母表中的下一个字母。

如果你有兴趣了解这个游戏的规则，并且想要一个更简洁的后端，请看以下步骤：

克隆 Optimism 的 monorepo，安装依赖，并制作 devnet allocations/cannon/op-program 的二进制文件。

需要的依赖：

foundry
Golang 工具链
Docker

git clone git@github.com:ethereum-optimism/optimism.git && \\\\
    cd optimism && \\\\
  pnpm i && \\\\
  (cd packages/contracts-bedrock && forge install) && \\\\
  make cannon-prestate && \\\\
  make devnet-allocs

启动字母游戏：

cd op-challenger && make alphabet

导航至 https://disputify.optimism.io 或通过克隆 https://github.com/clabby/dispute-viz 在本地运行可视化前端，并输入部署在您本地 devnet 上 FaultDisputeGame 代理的地址。

帮助维护 OP Stack 争议协议

在一个二分游戏中，上述所有机制共同作用，以创建一个奖励诚实行为并有效地抵制不诚实声明的系统。

有许多方法可以构建实现相同目标的争议游戏。我们希望当 OP Stack 的 FPS 在 OP Goerli 上部署时，我们生态系统中的构建者能够在构建他们自己的争议游戏时玩得开心并发挥创造力。每一个创造的争议游戏都可以在 OP Stack 的社会去中心化中发挥作用，并为生态系统参与者在解决任何关于信息的声明的争议时提供选择。