本文介绍了OP Stack的Fault Proof System (FPS) 中的 dispute games,阐述了其在去中心化故障检测中的作用,以及如何在dispute协议之上构建fault proof dispute game。
OP Stack 的故障证明系统 (FPS) 中最有趣的部分之一是其争端游戏,这并非巧合。之前关于 FPS 的文章已经概述了 OP Stack 的模块化如何使故障证明程序 (FPP) 与故障证明虚拟机 (FPVM) 解耦,从而实现下一级别的可组合性,并能对这两个组件进行高效的并行升级。对于争端游戏来说,情况也是如此,甚至几乎是指数级的。
本文探讨了争端游戏将在 Superchain 生态系统内的去中心化故障检测中发挥的作用,故障证明争端游戏是如何构建在争端协议之上的,以及争端协议的可扩展性所带来的可能性。
如果你想深入了解有关争端游戏的更细粒度的细节,我几周前在我的个人博客上分享了此文章的更长版本。
争端游戏是争端协议的核心原语。它模拟了一个简单的状态机,并使用 32 字节的承诺进行初始化,该承诺指向任何可以被质疑有效性的信息片段。它们包含一个函数,用于将此承诺解析为真或假,这留给原语的实现者来定义。OP Stack 的争端游戏的第一个实现 FaultDisputeGame
是无需许可的,因为它由在模拟 VM 之上执行的故障证明程序的结果决定。
争端游戏本身依赖于两个基本属性:
激励兼容性:该系统惩罚虚假主张并奖励真实主张,以确保公平参与。
解析:每场游戏都有一个机制来明确地验证或否定根主张。
在争端协议中,可以通过 DisputeGameFactory 创建、管理和升级不同类型的争端游戏。这为创新功能打开了大门,例如聚合证明系统以及扩展协议以允许争端 L2 状态以外的事物的能力,例如,面向链上二进制验证的 FaultDisputeGame
。
这是一种特定类型的争端游戏,也是在 OP Stack 的争端协议中构建的第一个游戏。在这个游戏中,参与者来回进行,划分执行轨迹直到达到单个步骤。在二分达到对单个跟踪指令状态的承诺后,FaultDisputeGame
使用通用 VM 在链上执行单个指令步骤。VM 的状态转换函数,我们称之为 T,可以是任何东西,只要它符合 T(s, i) -> s' 的形式,其中 s = 约定的前置状态,i = 状态转换输入,s' = 后置状态。
对于我们在二分游戏中 VM 通用性的第一个完整实现,我们在 EVM 之上实现了一个 MIPS 单线程上下文,以执行由 Cannon
和 op-program
生成的执行跟踪中的单个指令。
主张代表在给定指令处对后端 VM 状态的承诺。这些承诺可以是真也可以是假,真实性在解析阶段之后确定。如果未被反驳,则假定主张为真。
主张存在于二叉树中的位置。该位置表示该主张与哪个指令相关。位置是广义索引,可以定义为 2^{depth} + index_at_depth
。
玩家有时间限制来执行动作。该游戏是无需许可的,允许任何人加入。每一方开始时钟上有 3.5 天的时间,总共 7 天的游戏时间。如果创建了新路径或在已经收到声明的位置提出了声明,则继承祖父的时钟。
玩家进行二分,直到主张承诺到仅一个 VM 指令的状态。然后,他们在链上执行该指令以验证或伪造主张。步骤可以是攻击(挑战父主张)或防御(同意父主张)。每当玩家同意他们正在观察的主张哈希时(这意味着双方的状态在给定的指令处是相同的),就会进行防御,但不同意他们试图基于观察到的承诺与根承诺的相对协议来推动的最终结果。
在位置树的叶节点上,每个声明都承诺到仅一个 VM 指令的状态。剩下的唯一步骤是执行该 VM 指令以证明或反驳父主张。
如果指令步骤确认了预期的后置状态,则该主张将保持未被反驳。如果存在意外的后置状态或退出代码,则父主张将被反驳。
游戏可能会在所有主张的象棋时钟耗尽后解析,最低为 3.5 天。游戏中的每个主张都是其自身 子游戏 的根。子游戏是深度为 1 的 DAG。指向根的所有子项(它们本身就是子游戏根)都是对它的反驳,并且只有在其所有子项子游戏也已解析后,子游戏才能被解析。只有当_一个或多个_其子项被解析且未被反驳时,才能认为子游戏根被反驳,并且此属性向上渗透到游戏的根主张。
诚实玩家的存在,假设其所有步骤都已耗尽,将始终导致游戏以对其跟踪的看法有利的方式进行解析,无论根主张是诚实的还是不诚实的。不诚实的主张始终可以被任何一方反驳,但是始终只有一个正确的主张可以做出,因为不允许在同一子游戏中同一位置使用重复的主张哈希。
对于任何好奇的人,还有一个用于模拟执行跟踪的 FaultDisputeGame
的可视化工具,该跟踪仅包含 16 条指令。此模拟使用与 MIPS 线程上下文不同的 VM,即 AlphabetVM
,当给定一个字母作为输入时,它只是返回字母表的下一个字母。
如果你有兴趣使用更轻量级的后端来探索游戏规则,请按以下步骤操作:
克隆 Optimism monorepo,安装依赖项,并制作 devnet 分配/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
运行字母游戏:
cd op-challenger && make
FaultDisputeGame
代理的地址。在二分游戏中,上述所有机制协同工作,以创建一个奖励诚实行为并有效反驳不诚实主张的系统。
有许多方法可以构建争端游戏来实现相同的目标。我们希望当 OP Stack 的 FPS 部署在 OP Goerli 上时,我们生态系统中的构建者将玩得开心并在构建自己的争端游戏中发挥创造力。创建的每个争端游戏都可以在 OP Stack 的社会去中心化中发挥作用,并为生态系统参与者提供选择,以便在解决关于某条信息的任何给定主张时如何解决争端。
- 原文链接: optimism.io/blog/the-gam...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!