OP Stack + 零知識證明 = L2的終局遊戲？

2023-10-10 16:10:05

作者：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），對基於Reth的Ethereum ZK 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則會更加安全。