IOSG：ZKVM生存之道，詳解zkVM與zkEVM的派系之爭

原文標題：《 IOSG Weekly Brief ｜ZKVM 生存之道，一文詳解派系之爭 》

原文作者：Bryan, IOSG Ventures

過去的2022 年關於rollup 主要的討論焦點似乎都集中在ZkEVM，但別忘記ZkVM 也是另一種擴容方式。雖然ZkEVM 並不是本文的重點，但值得回味一下ZkVM 與ZkEVM 之間幾個維度的不同之處:

相容性：雖然都是擴容，但重點並不同，ZkEVM 的重點在於直接實現與現有EVM 的兼容，而ZkVM 的定位在於實現完全的擴容，也就是將dapp 的邏輯以及性能提升到最優，兼容性並不是首要的。底層搭好了，EVM 相容也可以實現。

性能：兩者都有比較可預見的性能方面的瓶頸，ZkEVM 主要瓶頸在於兼容EVM 這樣一個並不適合封裝在ZK 證明系統時產生的多餘成本。 ZkVM 的瓶頸在於因為引入了指令集 ISA, 導致最終輸出的限制更為複雜。

開發者體驗：Type II ZkEVM ( 如Scroll, Taiko) 主打的是對於EVM Bytecode 的兼容，換句話說就是Bytecode 等級及其以上的EVM程式碼都可以透過ZkEVM 產生對應的零知識證明。對 ZkVM 來說，有兩個方向，一個方向是做自己的 DSL( 如 Cairo), 另一個則是目標兼容現有的比較成熟的語言如 C++/Rust（如 Risc 0)。未來我們預期原生的 solidity 以太坊開發者會可以無成本移轉到 ZkEVM，而更新更強大的應用程式則會跑在 ZkVM 上。

很多人應該還記得這張圖，CairoVM 事不關己遊離於ZkEVM 派系鬥爭的本質原因是設計思想的不同

在討論ZkVM 之前，我們首先思考的是如何在區塊鏈中實現ZK 證明系統。大致上，有兩種方法實現電路 - 基於電路的系統 (circuit based) 以及基於虛擬機器的系統 (vm-based)。

首先，基於電路的系統的功能是將程式(program) 直接轉換為約束條件(constraints) 並送入證明系統(proving system)；基於虛擬機器的系統透過指令集(ISA) 執行程序，在此過程中產生執行軌跡(execution trace)。這個執行軌跡之後會被映射成約束條件，然後被送入證明系統。

對於一個基於電路的系統，程式的計算由執行程式的每台機器 (machine) 進行約束。而對於基於虛擬機器的系統，ISA 被嵌入到電路產生器 (circuit generator) 中，並產生程式的限制 (constraints)，同時電路產生器有指令集、運行週期、記憶體等等限制。虛擬機器提供了通用性，即任何機器都可以運行一個程序，只要該程序的運作條件在上述限制範圍內。

在虛擬機器中一個zkp 程式大概經歷如下的流程：

圖片來源: Bryan, IOSG Ventures

優缺點:

從開發者(developer) 的角度來看，在基於電路的系統中開發通常需要對每個約束條件的成本有深入的了解。然而，對於編寫虛擬機器程式來說，電路是靜態的，開發者需要更關心的是指令 (instructions)。

從驗證者(verifier) 的角度來看，假設使用相同的純SNARK 作為後端，基於電路的系統和虛擬機器在電路的通用性方面有很大的不同。電路系統對每個程式產生不同的電路，而虛擬機器對不同程式產生相同的電路。這意味著，在一個 rollup 中，電路系統需要在 L1 上部署多個驗證合約 (verifier contract)。

從應用(application) 的角度來看，虛擬機器透過將記憶體模型(memory) 嵌入到設計中，使應用程式的邏輯更加複雜，而使用電路系統的目的是為了提高程式的效能。

從系統複雜性(complexity) 的角度來看，虛擬機器將更多的複雜性納入系統，如記憶體模型、主機(host) 和客戶(guest) 之間的通訊等，相較之下電路系統較簡潔。

以下是目前L1/L2 中基於電路和基於虛擬機器的不同的項目預覽:

圖片來源: Bryan, IOSG Ventures

虛擬機器的設計原則

在虛擬機器中，有兩個關鍵的設計原則。首先，確保程序被正確執行。換句話說，輸出 (output)（即約束條件 constraint）與輸入 (input)（即程式 program）應正確配對。一般這是透過 ISA 指令集完成的。其次，確保編譯器 (compiler) 在從高階語言轉換為適當的約束格式時能正確運作。

1. ISA 指令集

規定了電路產生器的工作方式。它的主要責任是將指令 (instructions) 正確地對應到約束條件 (constraint) 中，這些約束條件隨後被送入證明系統 (proving system)。 zk 系統使用的都是 RISC( 精簡指令集 )。有兩種 ISA 的選擇：

第一種是自建一個自訂的 ISA(custom ISA)，這在 Cairo 的設計中可以看到。一般來說，有以下四種類型的約束邏輯。

自訂ISA 的基本設計重點在於確保約束條件盡可能少，從而使程式的執行和驗證都能快速運作。

第二種是利用現有的 ISA(existing ISA)，這在 Risc 0 的設計中被採用。除了以簡潔的執行時間為目標外，現有的 ISA（如 Risc-V）還提供了額外的好處，例如對前端語言 (front-end language) 和後端硬體 (backend hardware) 友好。一個（有待解決的可能）問題是，現有的 ISA 會不會在驗證時間上有所落後（因為驗證時間並不是 Risc-V 的主要設計追求。

2. 編譯器(Compiler)

籠統地來說，編譯器會逐步將程式語言翻譯成機器代碼。在 ZK 的環境下，它指的是使用 C、C++、Rust 等高階語言編譯成約束系統（R 1 CS、QAP、AIR 等.）的低階程式碼表示。有兩種方法，

設計一個基於現有zk 電路表示(existing circuit representations) 的編譯器-- 比如說在ZK 中，電路表現形式從Bellman 這樣的可以直接呼叫的函式庫(library) 和Circom 這樣的低階語言開始。為了聚合不同的表現形式，Zokrates 這樣的編譯器（身也是 DSL）旨在提供一個抽象層，可以編譯成任意的較低表現形式。

基於（現有的）編譯器基礎架構 (compiler infrastructure) 來建置。基本邏輯是利用一個針對多個前端和後端的中間表現形式 (intermediate representation)。

Risc 0 的編譯器是基於 multi-level intermediate representation（MLIR），可以產生多個 IR（類似 LLVM）。不同的 IR 為開發者帶來了靈活性，因為不同的 IR 有各自的設計重點，例如其中有一些的最佳化是專門針對硬件，所以開發者可以根據自己的意願進行選擇。類似的想法在使用 GCC 的 vnTinyRAM 和 TinyRAM 中也可以看到。 ZkSync 也是另一個利用編譯器基礎架構的例子。

此外，你還可以看到一些針對 zk 的編譯器基礎設施，如 CirC，它也藉用了 LLVM 的一些設計概念。

除了上述兩個最關鍵的設計步驟外，還有一些其他的考慮因素：

1. 系統的安全性(security) 與驗證的成本(verifier cost) 之間的權衡

系統所使用的位元數越高（即安全性越高），代表驗證的成本越高。安全性反映在金鑰產生器（例如在 SNARK 中代表橢圓曲線）。

2. 與前端和後端的兼容性 (compatibility)

相容性取決於電路的中間表示 (intermediate representation) 的有效性。 IR 需要在正確性（程式的輸出是否與輸入相符 + 輸出是否符合證明系統）和靈活性（支援多種前端和後端）之間取得了平衡。如果 IR 最初是為解決像 R 1 CS 這樣的低度 (low-degree) 約束系統而設計的，那麼與其他更高級別 (high-degree) 的約束系統如 AIR 的兼容就很難。

3. 為提高效率需要手工製作(hand-crafted) 電路

使用通用模型(general purpose) 的缺點是，對於一些不需要複雜指令的簡單操作，其效率較低。

簡述先前的一些理論，

Pinocchio 協議之前: 實現了可驗證的計算，但驗證時間非常慢

Pinocchio 協議: 在可驗證性和驗證成功率方面提供了理論上的可行性（即驗證的時間比執行程序的時間短），是基於電路的系統

TinyRAM 協議: 相對於Pinocchio 協議，TinyRAM 更像一個虛擬機，引入了ISA，因此擺脫了一些限制，如記憶體存取(RAM)、控制流(conttrol flow) 等

vnTinyRAM 協定: 使得金鑰產生(key generation) 並不取決每個程序，提供了額外的通用性。擴展電路產生器，即能夠處理更大的程式。

上述模型都以SNARK 作為其後端證明系統，但特別是在處理虛擬機器時，STARK 和Plonk 似乎是一個更合適的後端，從根本上來說是由於其約束系統更適合實現cpu 一樣的邏輯。

接下來，本文會介紹三個基於 STARK 的虛擬機器 - Risc 0, MidenVM, CairoVM。簡而言之，除了都以STARK 作為證明系統外，它們各自有一些不同:

Risc 0 利用Risc-V 來實現指令集的簡潔性。 R 0 在 MLIR 進行編譯，這是 LLVM-IR 的變種，旨在支援多種現有的通用程式語言，如 Rust、C++。 Risc-V 還有一些額外的好處，例如硬體較為友善。

Miden 的目標是與以太坊虛擬機器（EVM）相容，本質上是 EVM 的 rollup。 Miden 現在有自己的程式語言，但也致力於在未來支援 Move。

Cairo VM 是由 Starkware 開發的。這三個系統所使用的 STARK 證明系統是由 Eli Ben-Sasson 發明的，目前 Starkware 的總裁。

讓我們更深入地了解它們的差異：

* 如何讀懂上面的表格？一些註解...

Word size（字長）- 由於這些虛擬機器所基於的約束系統是 AIR，其功能與 CPU 架構類似。所以選擇 CPU 字長（32/64 位元）比較適合。

Memory access（記憶體讀取）- Risc 0 使用暫存器 (register) 的原因主要是 Risc-V 指令集是基於暫存器的。 Miden 主要使用堆疊 (stack) 來儲存數據，因為 AIR 的功能與堆疊類似。 CairoVM 沒有使用通用暫存器 (general-purpose register)，因為 Cairo 模型中的記憶體存取 (main memory) 成本較低。

Program feed（程式執行）- 不同方法是有取捨的。例如，對於mast root 方法來說，它需要在處理指令時進行解碼，因此在執行步驟較多的程式中下證明者的成本較高

Bootloading 方法試圖在保持隱私的同時在證明者成本和驗證者的成本之間取得平衡。

Non-determinism（非確定性）- 非確定性是 NP-complete 問題的一個重要屬性。利用非確定性有助於快速驗證過去的執行。反過來說，它增加了更多的約束條件，因此在驗證方面會有一些妥協。

Acceleration on complex operations（複雜運算的加速）- 有些運算在 CPU 上運作很慢。例如，位元操作，如XOR 和AND，哈希程序(hash program)，如ECDSA，還有範圍檢查(range-check)...... 大多是區塊鏈/ 加密技術的原生但不是CPU 原生的運算（除了位元操作）。

直接透過 DSL 來實現這些運算會很容易導致證明的週期 (cycle) 耗盡。

Permutation/multiset ( 排列/ 多列組合) - 在大多數zkVM 中大量使用，有兩個目的--1. 透過減少儲存完整的執行軌跡(execution trace) 來降低驗證者的成本2. 證明驗證者知道完整的執行軌跡

文章最後筆者想談談Risc 0 目前的發展以及其讓我興奮的原因。

R 0 目前的發展：

a. 自研的「Zirgen」的編譯器基礎設施正在開發中。將 Zirgen 與一些現有的 zk 專用編譯器的效能進行比較會很有趣。

b. 一些很有趣的創新，如 field extension，可以實現更堅實的安全參數以及在更大的整數上進行操作。

c. 見證了在ZK 硬體和ZK 軟體公司之間的整合中看到的挑戰，Risc 0 使用了一個硬體抽象層，以便在硬體方面進行更好的開發。

d.Still a work-in-progress! 還在開發中！

支援手工製作的電路 (hand-crafted circuits)，支援多種雜湊演算法。目前，專用的 SHA 256 電路已實現，然而還不能滿足所有的需求。作者相信具體選擇優化哪一類電路取決於 Risc 0 所提供的用例 (use case)。 SHA 256 是一個非常好的起點。另一方面，ZKVM 的定位給人以靈活性，例如，只要他們不想，就不必去管Keccak :)

遞歸(recursion)：這是一個很大的話題，筆者傾向於不在該報告進行深入研究。需要知道的是，隨著 Risc 0 傾向於支援更複雜的用例 / 程序，更迫切地需要遞歸。為了進一步支援遞歸，他們目前正在研究一個硬體端的 GPU 加速方案。

處理非確定性 (non-determinism)：這是 ZKVM 必須處理的屬性，而傳統的虛擬機器是沒有這個問題的。非確定性可以幫助虛擬機器執行得更快。 MLIR 相對更擅長處理傳統虛擬機器方面的問題，而 Risc 0 如何將非確定性嵌入到 ZKVM 系統設計中值得期待。

WHAT EXCITES ME:

a. 簡單且可驗證！

在分散式系統中，PoW 需要高水準的冗餘，因為人們不信任他人，因此需要重複執行相同的計算來達成共識。而透過利用零知識證明，狀態的實現應該和同意 1+ 1 = 2 一樣容易。

b. 更多更實際的用例：

除了最直接的擴容外，更多有趣的用例將變得可行，例如零知識機器學習、資料分析等。相較於 Cairo 這樣的特定的 ZK 語言，Rust/C++ 的功能更普適且更強大，更多 web2 的用例跑在 Risc 0 VM 上。

c. 更具包容性/ 成熟的開發者社群:

對STARK 和區塊鏈有興趣的開發者不必再重新學習DSL，使用Rust/C++ 即可。

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia