作者：Bill Qian、Yongxin Song、Bonan Yuan，Cypher Capital
Layer2的終局遊戲
如今的Layer2賽道廝殺異常激烈，前有Arbitrum, Optimism, Base 等基於optimistic的rollup，後有Scroll, zkSync, Starkenet, Scroll，Polygon zkEVM, Taiko, Linea等基於ZeroKnowledge Proof的ZKP rollup。看似Layer2的競爭百花齊放，其實都在工程原理上都是使用了，鏈下計算，鏈上證明的想法。無論是optimistic的fraud Proof或ZKP的電路證明，在工程實務上的核心區別，也就是在鏈上證明方式的不同，別的原理其實大同小異。於是乎，Optimism選擇了一條特殊的路徑，即模組化Layer2，在邏輯上將Layer2多各個元件解藕。當OPstack實現Layer2各個模組的結偶後，一個非常看似腦洞大開時則合乎邏輯的思路打開了，即ZKP on OP Stack，把OP Stack的challenger由Optimistic Proof改成Zero Knowledge Proof，OpStack將成為支援多種證明的通用Layer2架構！
ZKP on OP Stack
一切討論的開始來自一篇Optimism的RFP, https://github.com/ethereum-optimism/ecosystem-contributions/issues/61。
以下我來介紹下這篇RFP所提出的問題和發展方向。
意圖：實現零知識證明以證明Optimism’s 錯誤證明程式(透過Golang編譯器支援的指令集)
如何實現：給OP鏈實現零知識證明(ZKP)是實現L2與L1之間安全與低延遲通訊的前提。一種支持指令集的零知識證明，可以證明Optimism的錯誤證明程序，且包含任意OP Stack的區塊鏈。在證明ISA的標準執行追蹤的基礎上，支援故障證明程序還引入了額外的要求。
具體來說，故障證明程序引入了「預圖預言機」的概念，它使用特殊的系統呼叫將外部資料載入到程式中。每個故障證明虛擬機負責實作一些機制，透過該機制，某些資料的雜湊被放置在記憶體的特定位置，執行系統調用，然後將該雜湊的原像載入到記憶體中供程式使用。預圖預言機也用於使用初始輸入引導程式。有關詳細信息，請參閱故障證明程序文件中的“預圖預言機”部分。
簡言之，該提案就是想利用OP Stack的高度模組化特性，將原本基於樂觀證明(Opstimisic Proof)的錯誤證明方式，切換為利用零知識證明完成。進一步的特化，因為目前OP是將GETH透過MIPS編譯為Mini Geth, 那麼OP Stack的零知識證明可以理解為ZKMips，即基於Mips虛擬機的零知識證明。
Why ZKP?
目前基於OP Stack不是跑的好好的嘛，基於樂觀證明的Optimism和Arbitrum都取得極其良好的社區支持和開發者支持。 OP Stack為什麼還要探索零知識證明呢？筆者認為這裡有幾點原因
-
OP Stack將layer2的模組高度抽象化，引入ZKP只是引入不同的錯誤證明方式，並不代表OP會放棄樂觀證明。使用OP Stack的開發者可以自由選擇不同的證明方式
-
基於樂觀證明(Optimistic Proof)的Optimism和Arbitrum目前仍不支持錯誤證明，本質上OP和ARB是兩條無法證偽的單機鏈。
-
樂觀證明7天的最終確認速度，實在是太慢了。當ZKP的Layer2佔據市場後，ZKP快至30分鐘的證明速度會形成顯著的優勢，最終用戶會選擇安全性更高的ZKP Layer2
因此，Optimism支持ZKP是遲早的時間。大膽的猜想，未來OP Stack會支持樂觀證明和零知識證明2套錯誤證明系統。 OP Stack是一套通用的Layer2架構，並不斷迭代。為了幫助大家理解OP Stack為什麼可以實現不同證明系統的切換，下文將詳細的拆解OP Stack。
OP Stack的核心模組
(該圖截自optimism的github)
對於OP Stack，重要的幾個模組如下:
-
op-node
-
op-geth
-
op-batcher
-
op-proposer
-
op-program
-
Cannon
-
op-challenger
這些模組都是獨立的程序，並透過http的標準介面溝通，這意味著開發者如果要修改OP Stack中的一些特性，只需要修改其中的特定模組，便可以自訂自己的Layer2。下面的章節，將具體的介紹每一個OP Stack的模組，和OP Stack的整體架構。
op-node
op-node是OP Stack中最重要的模組。一方面，作為Sequencer，op-node包含了區塊鏈的共識客戶端實現，可以類比以太坊中的Lighthouse, Prysm，為用戶提交的交易進行排序；另一方面，作為rollup driver，op-node負責從L1區塊的數據中衍生出Layer2的鏈。
Sequencer在收集使用者交易並排序後，會由op-batcher產生一個batch，在batcher將batch提交到L1之前，為了降低Rollup網路中的延遲，Sequencer可以提前產生Layer2的block，透過P2P在Rollup網路中傳播。在L2直接產生的block被認為是unsafe的，需要等待batch提交到L1後進行推導才能夠視為safe，不過在正常情況下（無區塊重組、欺詐等），L2直接產生的block與從L1推導出的block是相同的。 Binance等交易所只等待一定的Layer2 blocks後便認為交易是確定的，而無需等待batch被提交到L1，一定程度上說明出錯的機率極低。
推導L2區塊的過程由driver負責，driver持續追蹤L1 head block和L2鏈同步過程，從L1中取得存款交易、L2交易資料和對應收據並產生payload attributes，將payload attributes傳遞給執行引擎，計算L2 block。 L2 blocks完全依賴L1鏈的區塊，每當包含L2 batch的L1 block產生，L2鏈進行延伸。此外，當L1 block發生重組，L2 block也會發生重組。
op-geth
op-geth是OP Stack的執行客戶端實現，對go-ethereum進行了微小的修改以適應OP Stack的需求。共識客戶端op-node透過Engine API來驅動執行客戶端op-geth，利用payload attribute，op-geth可以計算出output訊息，產生L2 block。
op-batcher
batcher即為batch submitter，主要包含兩個任務。一個是對L2 sequencer資料壓縮為batches；另一個是將batches提交至L1，讓verifier能夠利用資料進行驗證。
batcher向DA層提交batcher交易，交易包含一個或多個channel frame。 channel由一系列sequencer batches組成，以獲得更高的壓縮率，具體而言，batcher目前使用zlib進行資料壓縮。由於channel的大小可能超過batcher交易所能容納的上限，channel被分成一個或多個channel frame，一個batcher交易可以包括一個或多個channel frame（可以來自不同的channel）。
source: Optimism
該設計為batcher提供了很高的靈活性，未來OP Stack會支援batcher利用多個signer並行提交多個channel。
op-proposer
op-proposer負責將op-geth執行L2 block後產生的新狀態承諾（目前以Output Merkle Root形式）提交到L1。 Output Root不會立即生效，而需要等待爭議期過後才能視為Finalized。
以上為OP Stack已實現的部分，下列的Fault Proof相關模組內容尚未完成，僅依文件規範進行論述。
OP Fraud Proof由三個組件組成：
-
Program: 給定Rollup Inputs(L1 Batch tx Data)的承諾和dispute，無狀態地驗證dispute（透過PreImageOracle提供的Inputs復現相同的計算過程）
-
VM: 給定無狀態的Program和Inputs，追蹤任何指令（因此是stateful），在L1上證明
-
Interactive Dispute Game: 二分Dispute到單一指令，用VM解決這個base case
op-program
op-program是Program的參考實現，在op-node與op-geth的基礎上開發，作為無狀態的中間件，驗證關於L2狀態轉移的Claim。
為了驗證L2狀態的聲明，program首先將L1 data應用到finalized L2狀態，重建最新的L2狀態，這個過程與op-node的工作類似。差別在於，op-node從RPC取數據，把狀態變化應用到磁碟；而Program從Pre Image Oracle取數據，將狀態變化應用到記憶體。 Program串流地從Oracle讀取數據，並進行串流的狀態變更，直到讀到EOF或提前終止條件。重建L2狀態後，根據狀態與claim是否相同回傳驗證結果。
Cannon
Cannon是VM的實現，包含兩個主要元件：
-
Onchain MIPS.sol: EVM implementation to verify execution of a single MIPS instruction.
-
Offchain mipsevm: Go implementation to produce a proof for any MIPS instruction to verify onchain.
鏈上部分，MIPS.sol實現了big-endian 32-bit MIPS指令集，模擬Linux內核的最小子集，為Go程式提供支持，但是不包含並發相關的系統調用。
鏈下部分，mipsevm用Go語言模擬MIPS.sol的執行過程，
-
It’s Go code
-
…that runs an EVM
-
…emulating a MIPS machine
-
…running compiled Go code
-
…that runs an EVM
簡而言之，Cannon在鏈上就是在EVM用MIPS去跑MINI Geth(GETH的MIPS編譯)，也就是ETH的Golang版本。
op-challenger
op-challenger負責處理與dispute game相關的流程。
挑戰是先選取一個tx執行後的state root發出質疑，之後tx會分解為多個instruction，每個instruction執行後產生新狀態，形成S1, S2, … Sn的狀態序列。
為了提高效率，挑戰雙方需要輪流執行steps，分為Attack與Defend兩類。
-
Attack: 爭議的前一個狀態作為輸入，期待爭議狀態作為輸出。 在DAG中需要有對前一個狀態的承諾。
-
Defend: 爭議狀態作為輸入，爭議後一個狀態作為輸出。 DAG中需要有對後一個狀態的承諾。
舉例而言，假設有1-9999個instruction，產生S1-S10000狀態序列，先檢驗第5000個狀態，如果相同，attack step，向左二分；如果不同，defend step，向右二分。
最終透過二分法將爭議鎖定在單一指令的前後狀態上，再交由VM處理單一指令的狀態驗證。
模組的工作流程
正常流程（不包含Challenge）
source: Cypher Capital
-
用戶提交交易，可以透過L2 RPC在L2上提交，或在L1上直接提交（可以繞過op-batcher，有更強的抗審查能力，也可作為緊急逃生裝置）。
-
op-node啟動的RPC server接收到交易後，進行排序並傳送至op-batcher與op-geth
-
op-batcher對sequenced tx進行壓縮，產生batch，提交至DA層（L1）。
-
op-geth執行sequenced tx，將執行後的新狀態傳遞給op-proposer
-
op-proposer將L2的output root作為對於L2狀態的承諾發送到L1進行存儲，當挑戰期結束，狀態被視為finalized。
-
op-node中的driver會從L1中獲取交易數據以及其他信息，derive出canonical L2 block。在L1上finalized的block中batch tx derive出的L2 block被視為finalized，在L1上被confirmed但未finalized的batch tx derive出的L2 block被視為safe，為降低延遲直接由L2生成的L2 block可以透過P2P提前傳播，被視為unsafe。
Challenge流程
source: optimism
-
使用者開啟interactive dispute game
-
Cannon (VM)在MIPS虛擬機器上執行op-program（Written in Go），以便追蹤每個步驟執行的狀態變化
-
op-program透過PreImageOracle提供的Rollup Inputs的承諾復現L2狀態的計算過程，記錄execution trace，無狀態地驗證dispute
-
op-challenger使用二分法，將爭議定位到單一指令
-
Cannon為執行此指令前後的狀態變化產生證明，在L1上的智能合約MIPS.sol上進行驗證。
OP Stack+ZKP
根據上述的流程介紹，我們容易發現，Challenge模組與其他模組的耦合度很低，對基本交易流程的影響很低，只有在出現詐欺行為的情況下（自2021年12月OP Mainnet上線至今尚未出現）才需要Challenge模組的介入。
為了縮短目前Optimism七天的退出確認時間，也為OP Stack提供更多模組化的選擇，Optimism積極擁抱ZKP技術，希望為OP Stack帶來能夠證明Optimism fault proof program並且支援知名ISA的ZKP，O(1 ) Labs與Risc-0團隊的方案通過了Foundation Mission (RFP) Application。
O(1) Labs方案
source: O(1) Labs
O(1) Labs作為Mina Protocol的開發團隊，計劃沿用Mina Protocol採用的Kimchi作為MIPS VM的proof system，僅作了一些小的改動。
Kimchi是Halo2-like PLONKish system currently configured with an inner-product-argument style polynomial commitment scheme. It supports verifiable computation using traditional turing-machine-based instruction sets.
Kimchi的後端可交換，目前的實作定義在Pasta curves using an inner-product-argument-based polynomial commitment scheme (Pasta-IPA)上，與EVM所用的密碼學體係不相容，在EVM上驗證成本較高。於是O(1) Labs計畫將Pasta-IPA改為KZG commitment scheme using the bn128 curves (bn128-KZG)，可以使用EVM現成的precompile，效率更高。
原來輸入fault proof MIPS系統的輸入現在會輸到bn128-kzg Kimchi系統，ZK-Prove執行路徑。 pre-image系統呼叫沿用OP Stack的Cannon，最終proof傳送到L1上的智能合約，驗證通過後在L1更新狀態。
RISC Zero方案
RISC Zero團隊計劃沿用目前實現的Groth16後端的基於RISC-V ISA的zkVM（augmented with accelerated co-processors for common cryptographic tasks including hashing and ECDSA signature verification）， 對基於Zeth Clienteum hashing and ECDSA signature verification），對基於Reth Clienteum ZKyeth Client Optimism，在zkVM中實作L1-L2的derivation logic以證明交易序列是由Optimism sequencer產生的。
ZK Client由zkVM guest program和host library兩個部分組成，類比OP labs方案中的op-program和cannon，zkVM guest program負責計算狀態轉移，host library負責獲取計算數據轉移所需的數據，協調zkVM guest program的執行，並產生交易執行狀態轉移的zkp。
OP Stack的ZKP可能性探究
目前一家叫做ZKM的團隊實現了ZKMIPs的EVM，即將EVM轉譯為MIPs指令集並進行零知識證明。目前回饋為，很慢，但可用。
考慮到Mina和Risc0都擁有相對成熟的開發，經驗，我們有理由相信，OP Stack支援ZKP只是時間問題。但同時，考慮到OP Stack的ZKP開發啟動較晚，且不是原生支持，未來的效能如何依然無法預測。
OP Stack, Layer2的通用架構
OP Stack以其優秀的程式碼實現、寬容的開源協定以及模組化的架構設計獲得了許多知名團隊的採用，唯一為人所詬病的在於所採用的Optimistic Rollup技術確定性時間過長，技術先進性不如ZK Rollup。如今，借助第三方專業團隊的力量，OP Stack開始了邁向ZKP未來的嘗試。考慮到目前OP Stack尚未支援Fault Proof，OP Stack有可能跳過Fault Proof階段，直接使用ZK Proof來取得更快的確定性與更高的安全性。
對於未來的Layer2開發者而言，OP Stack將成為通用的Layer2架構，開發者可以啟動自己的Layer2時，依據應用所需的安全性和實效性，靈活的選擇樂觀證明，或者零知識證明。可以預見的是，樂觀證明的Layer2會比較廉價，零知識證明的Layer2則會比較安全。
