模块化争议游戏设计：优化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生成的执行跟踪中执行单个指令。

声明