作者：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 導入 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 以及开源社區的無限創造力的發展，通過測試實施和參與漏洞賞金計劃，將有許多額外的機會爲堆棧做出貢獻。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。