本文探討了社會去中心化原則及 L2 架構如何使 Layer2 能夠擴展這一原則，並介紹了 Optimism Collective 正在如何利用該架構構建其防故障系統。
原文：Social Decentralization & the OP Stack's Fault Proof Virtual Machine（OP Labs）
作者：protolambda，OP Labs 研究員
編譯：Frank，Foresight News
封面：Optimism
為了創建最強大和安全的互操作性 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 系統調用的子集。 讀 / 寫系統調用允許與預映像預言機進行交互：程式將哈希作為請求寫入，以獲取預映射，然後按一小塊一小塊地每次進行讀取;
Cannon，第一個 FPVM，就是以這種方式實現了 MIPS 虛擬機。 有關虛擬機的更多資訊，請參閱相關文檔和 cannon-specs。 FPVM 與 FP 程式之間的介面是標準化的，並在規範中有所記錄。
從 FPVM 到 ZKVM
故障證明不是唯一類型的狀態轉換證明，ZK 有效性證明是一個有吸引力的選擇，因為它具有快速跨鏈橋接的潛力（由於 ZK 有效性證明沒有鏈上挑戰遊戲，所以沒有爭議視窗）。 為了支援先進的乙太坊堆疊並託管不同的客戶端實現，我們仍然需要將虛擬機和程式解耦。
這是 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 以及開源社區的無限創造力的發展，通過測試實施和參與漏洞賞金計劃，將有許多額外的機會為堆疊做出貢獻。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 本文內容僅用於資訊分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
