本文探討了社會去中心化原則及 L2 架構如何使 Layer2 能夠擴容這一原則，並介紹了 Optimism Collective 正在如何利用該架構構建其防故障系統。本文源自 OP Labs 研究員 protolambda 所著文章 《Social Decentralization & the OP Stack’s Fault Proof Virtual Machine》，由 Foresight News 編譯、整理。
（前情提要：Layer2模組化戰爭：OP Stack vs. ZK Stack，誰能贏？ ）
（背景補充：瘋狂多鏈宇宙｜OP Stack如何靠「一鍵建立Layer2」顛覆市場 ）
為了建立最強大和安全的互操作性 Layer2 網路，Optimism Collective 正在通過許多不同的途徑追求去中心化。
而 OP Stack 即將推出的防故障系統將是技術去中心化的一大一步，OP Stack 的開源和模組化設計正在為 L2 生態系統的社會去中心化創造了前所未有的舞臺。
在本文中，我們將探討社會去中心化原則，以及 L2 架構如何使 Layer 2 能夠擴容這一原則以包括證明多樣性和客戶端多樣性，並介紹 Optimism Collective 如何利用該架構構建其防故障系統。
受以太坊啟發的「社會去中心化」
以太坊協議受益於社會去中心化，尤其是通過在解決方案中提供可選擇性，使廣泛的貢獻者能夠參與構建一個強大的去中心化網路。
對於節點軟體而言，這意味著客戶端多樣性：擁有更多的客戶端，那單點故障對驗證者網路的影響就越小。
Layer1 的核心開發者將這種貢獻模式描述為「集市」（bazaar），它喧鬧且看似混亂，但卻非常高效且充滿活力。通過採用徹底開放式的協議開發方法，可以使最廣泛的貢獻者參與並改進協議。
而 Optimism Collective 具有獨特的優勢，可以實施和迭代以太坊實現社會去中心化的方式：OP Stack 通過提供開放規範和 MIT 許可證下的開源軟體來實現社會去中心化，並且 Optimism Collective 可通過建立超級鏈對其進行迭代。
對 L2 架構的更詳細瞭解
以太坊在 L1 具有開放的規範，以及將共識層和執行層分開的模組化客戶端架構。
OP-Stack 在 L2 上實現了相同的架構：
- 共識層由 op-node 和 Magi 提供支援，這兩個客戶端遵循 L1 並匯出執行輸入；
- 執行層由 op-geth、op-erigon 和 op-reth 提供支援；
然而，L2 架構在此堆疊中添加了一個新層：驗證層（proving layer）。
這是將 L2 輸出安全地橋接回 L1 的層級，正如擁有多個客戶端是確保在 L1 和 L2 上達成共識和執行的最佳實踐一樣，對於 L2 的驗證層來說，採用多種證明方法可以確保最佳安全性。
類似於具有不同客戶端的驗證者們達成共識，鏈上證明的法定數量可以表明 L2 狀態宣告已經以不同方式得到驗證，從而大大降低了錯誤導致完全失敗的可能性。
目前共有三種常見的證明型別：證明（attestations）、錯誤證明（也稱為欺詐證明）和零知識有效性證明。後兩者共享一個常見模式，它們以同步形式表達 L2 狀態轉換，並在給定 L1 資料和 L2 前狀態作為輸入時，證明其執行。
隔離證明系統元件以實現證明多樣性
證明系統可以進一步分解為獨立的元件：
- 一個「程式」，定義了同步的 L2 狀態轉換；
- 一個「虛擬機器」（VM），執行並驗證該程式；
- 一個「預映像預言機」（pre-image oracle），將 L1 資料和 L2 預狀態作為輸入；
今天的許多零知識證明仍然在緊密地耦合這些元件，建立了一個在單一 L1 交易資料上執行的 ZK-EVM。然而，OP 堆疊將它們解耦以隔離複雜性，並實現客戶端的多樣性，從而使整體更加強大。
互動式故障證明將二分遊戲（bisection-game）新增到虛擬機器追蹤中，以驗證鏈上的證明，而基於虛擬機器的零知識證明則對執行進行算術化和摺疊，並提供有效性證明。（請參閱 Risc0 和 O (1)-Labs 正在設計以響應 Optimism ZK RFPs 的基於虛擬機器的零知識證明）。
該程式將實際的狀態轉換定義為「客戶端」，將輸入獲取（L1 資料和 L2 預狀態）定義為「伺服器」。該程式在沒有虛擬機器的情況下，與伺服器 / 客戶端獨立執行，這與常規區塊鏈節點非常相似，並且共享了大量程式碼。
例如，Go op-program 客戶端是通過從 op-geth 匯入 op-node 的派生和 EVM 來構建的，而伺服器則從 L1 和 L2 以太坊 RPC 獲取其資料。
FPVM 的功能概述
故障證明虛擬機器（FPVM）是 OP Stack 中故障證明堆疊的模組之一。
除了提供正確的介面（尤其是與預映像預言機相關的介面），該虛擬機器沒有實現任何特定於以太坊或 L2 的內容，在 FPVM 內執行的故障證明程式（FPP）客戶端是表達 L2 狀態轉換的部分。
通過這種分離，虛擬機器保持極簡：以太坊協議的更改（如 EVM 操作碼的新增）不會影響虛擬機器。
相反，當協議發生變化時，FPP 可以簡單地更新以匯入節點軟體中的新狀態轉換元件，類似於在同一遊戲主機上玩新版本的遊戲，L1 證明系統可以更新以證明不同的程式。
虛擬機器負責執行低階指令，需要模擬 FPP。虛擬機器要求較低：程式是同步進行的，並且所有輸入都通過相同的預映像預言機載入，但所有這些仍然必須在 L1 EVM 鏈上得到證明。
為了做到這一點，每次只能證明一個指令。二分遊戲（bisection-game）將把證明完整執行追蹤的任務縮小到只有一個指令。
對於每個 FPVM 來說，指令證明可能看起來不同，但通常看起來與 Cannon 類似，它證明指令如下：
- 為了執行該指令，虛擬機器模擬類似於執行緒上下文（thread-context）的指令週期的東西：從記憶體中讀取指令、進行解釋，並且暫存器檔案和記憶體可能會發生一些變化；
- 為了支援預映像預言機以及記憶體分配等基本程式執行時的需求，執行還支援 Linux 系統呼叫的子集。讀 / 寫系統呼叫允許與預映像預言機進行互動：程式將hash作為請求寫入，以獲取預映像，然後按一小塊一小塊地每次進行讀取；
Cannon，第一個 FPVM，就是以這種方式實現了 MIPS 虛擬機器。有關虛擬機器的更多資訊，請參閱 相關文件 和 cannon-specs 。FPVM 與 FP 程式之間的介面是標準化的，並在 規範 中有所記錄。
從 FPVM 到 ZKVM
故障證明不是唯一型別的狀態轉換證明，ZK 有效性證明是一個有吸引力的選擇，因為它具有快速跨鏈橋接的潛力（由於 ZK 有效性證明沒有鏈上挑戰遊戲，所以沒有爭議視窗）。為了支援先進的以太坊堆疊並託管不同的客戶端實現，我們仍然需要將虛擬機器和程式解耦。
延伸閱讀：從Type1到Type4，各類型ZK-EVM的差異在哪？
這是 ZK RFP 專案採取的方法，以證明一個最小的 RISC-V（由 Risc0）或 MIPS（由 O (1) Labs）虛擬機器可以託管與故障證明中使用的相同程式。
支援 ZK-VM 確實需要進行一些小的調整，使得預映像預言機能夠以非互動方式載入資料，但通過將虛擬機器通用化，ZK 證明在面對 OP Stack 變化時更具未來性。
外部貢獻者的機會
OP Stack 歡迎額外的虛擬機器和程式選項，以及額外的獨立證明系統，從證明到零知識證明。就像客戶端多樣性一樣，證明多樣性是一個集體努力的結果。
目前正在進行中的對 OP Stack 證明層的補充包括：
- 由 protolambda 開發的基於 Go 語言編寫的 RISC-V FPVM「Asterisc」；
- 由 Base 和 OP Labs 貢獻者共同構建的基於 Magi 和 op-reth 的 rust FP 程式；
- 由 Risc0 構建的基於 zeth（ZK-reth 分支）的 rust ZK 程式；
隨著 Cannon、op-program、bisection-game 以及開源社群的無限創造力的發展，通過測試實施和參與漏洞賞金計劃，將有許多額外的機會為堆疊做出貢獻。
📍相關報導📍
技術》BNB Chain 新推出的L2「opBNB」是什麼？
