解讀OP Stack將推出的防故障系統：受以太坊啟發，技術去中心化的一大步

作者：protolambda，OP Labs 研究員

編譯：Frank，Foresight News

為了創建最強大和安全的互通性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 導入Dop-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 以及開源社群的無限創造力的發展，透過測試實施和參與漏洞賞金計劃，將有許多額外的機會為堆疊做出貢獻。