游戏进行时：为 OP Stack 的故障证明系统设计模块化争议游戏

深入探讨争议游戏及其在 OP Stack 第一个防错系统中的故障检测中所起的作用。

OP Stack 的故障证明系统 (Fault Proof System，FPS) 中最有趣的组件之一就是它的争议游戏，这并非巧合。之前有关 FPS 的文章概述了 OP 堆栈的模块化是如何使故障证明程序 (FPP) 从故障证明虚拟机 (FPVM) 解耦的，从而实现下一级可组合性并高效地对两个组件进行并行升级。毫不夸张地说，争议游戏的情况亦是如此。

本文探讨了争议游戏在超级链生态系统中的去中心化故障检测中所扮演的角色、如何在争议协议之上构建防错争议游戏，以及归因于争议协议的可扩展性而这种游戏出现的可能性。

如果您想了解有关争议游戏的更详细信息，请阅读几周前我在我的个人博客上分享的这篇内容更详细的文章。

什么是争议游戏？

争议游戏是争议协议的核心原语。它模拟一个简单的状态机，并对任何有效性有争议的信息片段，它以 32 字节承诺进行初始化。这些信息包含一个函数，用于解决此承诺的真假，该函数留给原语的实现者来定义。OP Stack 的第一个争议游戏实现FaultDisputeGame 是非许可的，因为它的解决函数是由在模拟虚拟机之上执行的防错程序的结果决定的。

Dispute games themselves rely on two fundamental properties:

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

1. 激励相容：系统对虚假声明进行惩罚，对真实声明进行奖励，以确保公平参与。
2. 解决方案：每个游戏都有一个机制来明确验证或无效根声明。

在争议协议中，可以通过DisputeGameFactory创建、管理和升级不同类型的争议游戏。这为聚合证明系统以及扩展协议等创新功能打开了大门，以容纳对第2层协议状态之外的争议事物，例如面向链上二进制验证的FaultDisputeGame 。

二分游戏

这是一种特定类型的争议游戏，也是第一个基于 OP Stack 争议协议构建的游戏。在这个游戏中，玩家来回划分执行轨迹，直到到达各个步骤。在二分法在各个跟踪指令上达到对状态的承诺后，FaultDisputeGame使用通用虚拟机在链上执行单个指令步骤。VM 的状态转换函数（我们称之为 T）可以是任何函数，只要它遵循 T(s, i) -> s’ 的形式，其中 s = 商定的预状态，i = 状态转换输入，s’ = 后状态。

对于我们在二分游戏中首次完整实现通用 VM，我们在 EVM 之上实现了单个 MIPS 线程上下文，以在 Cannon和op-program生成的执行跟踪中执行单个指令。

声明

声明表示对给定指令下后端虚拟机状态的承诺。这些可能是真的，也可能是假的，真实性在解决阶段后确定。如果没有反击，则认为声明是正确的。、

位置

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

棋钟

玩家的行动有时间限制。该游戏无需许可，任何人都可以加入。每一方开始时有 3.5 天的比赛时间，总计为 7 天的游戏时间。如果创建新路径或在已收到声明的位置提出声明，则继祖父级别的棋钟。

动作

玩家一分为二，直到声明仅针对一个 VM 指令的状态。然后他们在链上执行该指令来验证或伪造声明。行动可以是攻击（挑战父声明）或防御（与父声明达成协议）。每当玩家同意他们所观察到的声明哈希（意味着两方在给定指令下的状态相同），但不同意他们试图根据观察到的声明的相对协议推动的最终结果时，就会用根本声明进行防御。

指令步骤

在位置树的叶节点处，每个声明仅在一条 VM 指令处提交状态。剩下的唯一一步就是执行 VM 指令来证明或反击父声明。

如果指令步骤确认了预期的后状态，则该声明不成立。如果存在意外的发布状态或退出代码，则父声明将受到反击。

解决方案

这种游戏可能会在所有声明的棋钟耗尽后得到解决，最短时间为 3.5 天。游戏中的每个声明都是其自己的子游戏（Sub Game）的根。子游戏是深度为 1 的 DAG。指向根的所有子游戏（它们本身就是子游戏根）都是它的计数器，并且只有在其所有子子游戏也都已解决时，子游戏才可能得到解决。仅当子游戏根的一个或多个子游戏得到解决并且未被反击时，子游戏根才能被视为受到反击，并且此属性一直向上渗透到游戏的根声明。

诚实玩家的存在（即时其所有动作都已用尽）也总是会导致游戏以其轨迹视图的方式顺利解决，无论根本声明是诚实的还是不诚实的。不诚实的声明总是可以被任何一方反击，尽管总是只有一个正确的声明可以提出，因为不允许在同一子游戏中的同一位置出现重复的声明哈希。

0:00

1×

玩字母二分游戏

对于任何感兴趣的人，还有一个针对仅 16 条指令长的模拟执行跟踪的FaultDisputeGame的可视化工具。该模拟使用与 MIPS 线程上下文不同的单独 VM，即 AlphabetVM，当给定字母作为输入时，它仅返回字母表中的下一个字母。

如果您有兴趣使用更轻量级的后端探索游戏规则，请按以下方式玩：

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

所需的依赖项：

1. foundry
2. Golang toolchain
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

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

帮助保护 OP Stack 的争议协议

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

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

声明：

1. 本文转载自[oplabs]，著作权归属原作者[clabby]，如对转载有异议，请联系Gate Learn团队（gatelearn@gate.io），团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。