游戲進行時：爲 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 [email protected]: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團隊（[email protected]），團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。