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

作者: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)。

NdzbsEhrBtFOe0ImfgS9jrwCG1XpbWsH8QCmSSXV.png

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)

Vi8bzvYrWKunpvVtyhUtewYlIXERhvzfhGwSblyX.png

source: Cypher Capital

  1. 用戶提交交易,可以透過L2 RPC在L2上提交,或在L1上直接提交(可以繞過op-batcher,有更強的抗審查能力,也可作為緊急逃生裝置)。

  2. op-node啟動的RPC server接收到交易後,進行排序並傳送至op-batcher與op-geth

  3. op-batcher對sequenced tx進行壓縮,產生batch,提交至DA層(L1)。

  4. op-geth執行sequenced tx,將執行後的新狀態傳遞給op-proposer

  5. op-proposer將L2的output root作為對於L2狀態的承諾發送到L1進行存儲,當挑戰期結束,狀態被視為finalized。

  6. 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流程

OAjFcSbDRuy9GNjskeHvpVnzbj10wwLLDs6xpnyr.png

source: optimism

  1. 使用者開啟interactive dispute game

  2. Cannon (VM)在MIPS虛擬機器上執行op-program(Written in Go),以便追蹤每個步驟執行的狀態變化

  3. op-program透過PreImageOracle提供的Rollup Inputs的承諾復現L2狀態的計算過程,記錄execution trace,無狀態地驗證dispute

  4. op-challenger使用二分法,將爭議定位到單一指令

  5. 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方案

LKDkCzbtd8wVcvHRJCoMkPUUDPaotpwtvdHPr5mu.png

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。

LNjC0EoVGqLSmyycYcQk2ffXuWhW5um7BFoqztaC.png

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則會比較安全。

Total
0
Shares
Related Posts