本文主要討論了輔助運算器的實現方式、各類應用以及未來的發展方向。

作者：Kernel Ventures Turbo Guo

審稿：Kernel Ventures Mandy, Kernel Ventures Joshua

TL；DR

ZK 輔助運算器是一種讓 dApp 利用鏈下計算資源的方案，本文主要討論了輔助運算器的實現方式、各類應用以及未來的發展方向，主要內容有：

1. RISC Zero 的 zkVM 是一種 ZK 輔助運算器解決方案，它讓鏈上合約能調用鏈下 zkVM 跑特定的 Rust 代碼，並將結果返回給鏈上，同時提供 zkp 供合約驗證計算是否正確。

2. ZK 輔助運算器有不同的實現方式，除了 zkVM，用戶還可以自行為程式寫定製化 ZK 電路，或者使用預製的框架寫電路，進而讓合約能利用鏈下計算資源。

3. ZK 輔助運算器可以在 DeFi 上發揮作用，例如把 AMM 的計算放在鏈下進行，進而讓協定捕獲類似 MEV 的價值，或者讓 AMM 實現複雜且需要大量計算的運行邏輯。ZK 輔助運算器還可以讓借貸協定即時計算利率，使保證金計算透明化等。zkAMM 有兩種實現方式，一種是用 zkVM，另一種是用 zkOracle。

4. ZK 輔助運算器還有其他潛在用法，比如錢包可以用 ZK 輔助運算器把身分驗證放在鏈下執行，輔助運算器還可以讓鏈上游戲能執行更復雜的計算，降低 DAO 治理所需的 gas 等。

5. ZK 輔助運算器的格局未定，但相比用戶自己寫電路，用一個專案做接口調用鏈下資源是更加友好的，但那“接口”專案背後接入了什麼計算服務提供商（傳統雲廠商、去中心化資源共享）就是另一個值得討論的問題了。

1. ZK 輔助運算器的含義與應用

ZK 輔助運算器的核心是把鏈上計算挪到鏈下，用 ZK 證明鏈下計算過程的可靠性，使得智慧合約能夠輕鬆處理大量的計算，同時讓合約能核實計算的可靠性。這和 zkRollup 的思路是類似的，但 Rollup 是鏈協定層利用鏈下計算資源，而 ZK 輔助運算器是 dApp 利用鏈下資源。

這裡用 RISC Zero 來解釋一種 ZK 輔助運算器實現方式，但 ZK 輔助運算器有很多種實現方式，後文會繼續介紹。RISC Zero 開發了 Bonsai ZK 輔助運算器架構，其中的核心是 RISC Zero 的 zkVM， 開發者可以在 zkVM 上為“某段 Rust 代碼被正確執行”這件事生成 zkp。有了 zkVM 後，實現 ZK 輔助運算器的具體流程為：

1. 開發者向 Bonsai 的中繼合約發起請求，即在 zkVM 中跑開發者要求的程式

2. 中繼合約把請求發給鏈下請求池

3. Bonsai 在鏈下 zkVM 中執行請求，進行鏈下的大規模運算，然後為其生成一個憑證（receipt）。

4. 這些證明，也叫做“收據”，由 Bonsai 通過中繼合約發佈回鏈上。

在 Bonsai 中證明的程式被稱作 Guest Program ，憑證（receipt）用來證明 guest program 被正確執行。憑證包括一個 journal 和一個印章（seal）。具體而言，Journal 承載了 zkVM 應用的公共輸出，而印章用於證明憑證的有效性，即證明 guest program 被正確執行 ，印章本身也是一個由證明者生成的 zkSTARK。驗證憑證可以保證 journal 是用了正確的電路等構建所得 。

Bonsai 為開發者建恩化了從 Rust 代碼到 zkVM 位元組碼的編譯、程式上傳、在 VM 中的執行和證明反饋等流程，讓開發者能夠更聚焦於程式的邏輯設計。而且不僅是部分的合約邏輯，而且整個合約邏輯都可以放到鏈下跑。RISC Zero 還使用了 continuations，它把一個大的 proof 生成拆分成很多份，然後每份單獨進行證明。這樣既可以為大型程式生成證明，也不會佔用太多內存。除了 RISC Zero， 還有 IronMill , =nil; Foundation 和 Marlin 幾個專案也提供了類似的通用解決方案。

2. ZK 輔助運算器在 DeFi 上的應用

2.1 AMM – Bonsai 為輔助運算器

zkUniswap 就是一種利用了鏈下計算資源的 AMM，它的核心是把 swap 的部分計算放在鏈下，而且它使用了 Bonsai。用戶在鏈上發起一個 swap 請求。Bonsai 的中繼合約獲得請求，發起鏈下計算，Bonsai 完成計算後向 EVM 中的 callback 函數返回計算結果和 proof。如果 proof 被驗證為成功，swap 就會被執行。

但 swap 不是一次完成的，請求和執行過程分別在不同的 transactions 中，這帶來了一定風險，即在提交請求後和 swap 完成前，池子的狀態可能發生變化。因為驗證是基於提交請求時池子的狀態。如果一個請求還在等待時，池子狀態變了，那麼驗證就會失效。

為了解決這個問題，開發者設計了一個池子鎖。當用戶發起請求時，除了結算 swap 以外的所有操作都被鎖了起來，直到鏈下成功觸發鏈上 swap 或者 swap 超時了（會預設這個時間）。有時間限制的話，即使中繼或 zkp 出問題，池子也不會被一直鎖著。而具體的時間限制可能是幾分鐘。

zkUniswap 對 MEV 有個特殊的設計，即開發者希望讓協定捕獲 MEV 價值。理論上 zkAMMs 同樣有 MEV，因為第一個提交易的人就能上鎖，所以大家還是會爭 gas， builders 同樣可以為請求交易排序。但 zkUniswap 會把 MEV 收益自己吃掉，用到的方法是可變利率漸變式荷蘭拍賣（VRGDA）。

zkUniswap 把 lock 拿出來自己降價拍賣，如果 lock 很快賣掉，那協定就知道目前需求量大，然後自動升價，如果售出 lock 的速度變慢，協定就會降低價格。這會成為新的收入來源。相當於，協定提供了一個新東西決定交易順序，而競爭價格的錢直接通過新東西給到專案方，這個很有想像力。

2.2 AMM – zkOracle 為輔助運算器

除了用 zkVM，還有人提出用 zkOracle 來實現對鏈下計算資源的利用， 而 zkOracle 是兼顧輸入和輸出的預言機。一般預言機有兩種，一種是輸入預言機，一種是輸出預言機，輸入預言機是把鏈下數據整理（計算）後放到鏈上，輸出預言機是把鏈上數據整理（計算）後提供給鏈下。I/O（輸入兼輸出）預言機（zkOracle ），是先做輸出，再做輸入，讓鏈上能利用鏈下計算資源。

zkOracle 一方面使用鏈上數據作為數據源，另一方面用 ZK 保證預言機節點的計算沒有作假，可以實現輔助運算器的功能。因此，可以把 AMM 的核心計算放在 zkOracle 中，實現傳統 AMM 功能的同時，還可以用 zkOracle 實現更復雜更消耗計算資源的操作。

2.3借貸利率計算、保證金計算等其他應用

拋開實現方式，有了 ZK 輔助運算器後可以實現很多功能。比如，借貸協定可以不再預設參數，而是根據即時的借貸情況調整利率。比如在借錢需求旺盛時提高利率吸引供給，然後在需求降低時降低利率。這要求借貸協定能即時獲得鏈上數據，同時進行大量的計算，得出合適的參數，這就需要鏈下計算了（除非鏈上成本極低）。

計算保證金餘額、未實現的盈虧、清算金額等的複雜運算也可以將其轉移到輔助運算器來執行。用輔助運算器的優勢在於它讓這些應用更透明、更可驗證，保證金引擎的邏輯不再是一個祕密的黑盒子。雖然計算是在鏈下完成的，但用戶可以完全信任其執行的正確性。此外，這種做法也適用於期權的計算。

3. ZK 輔助運算器的其他應用

3.1 錢包 – 用 Bonsai 為輔助運算器

Bonfire Wallet 用 zkVM 把驗證身分的計算放到了鏈下。這個錢包的目標讓用戶能用生物資訊（指紋），或加密硬體 yubikey 創建 burner 錢包。

具體而言，Bonfire Wallet 使用了 WebAuthn 這個通用的網頁驗證標準，讓用戶不用密碼，直接用設備來完成網頁上的身分驗證。所以在 Bonfire 錢包中，用戶通過 WebAuthn 生成一個公鑰（不是鏈上的，給 WebAuthn 用的），然後用它來創建錢包。

每個 Burner 錢包在鏈上都有合約，其中包含了 WebAuthn 的公鑰，合約需要驗證用戶的 WebAuthn 簽名。但這個計算量是很大的，所以用到了 Bonsai 把計算放在鏈下，通過一個 zkVM guest 程式在鏈下驗證簽名，並生產 zkp 供鏈上驗證。

3.2 鏈上數據索取 – 用戶自行寫 ZK 電路

Axiom 是一個沒有用 zkVM 但使用另一種輔助運算器解決方案的應用。先介紹一下 Axiom 想做什麼，它希望利用 ZK 輔助運算器讓合約能查閱歷史鏈上資訊。其實讓合約讀歷史數據是很難的，因為智慧合約一般是獲得即時的鏈上數據，而且很貴，合約很難獲得賬戶過往餘額或者交易記錄等有價值的鏈上數據。

Axiom 節點訪問所需鏈上數據並在鏈下執行指定的計算，然後為計算生成一個零知識證明，證明結果是根據有效的鏈上數據正確計算出來的。這個證明在鏈上被驗證，確保合約可以信任這個結果。

為鏈下計算生成 zkp 就需要把程式編譯進 ZK 電路裡，前文也提到了用 zkVM 來做這件事，而 Axiom 官方指出在這件事情上有很多方案，需要權衡性能，靈活度和開發體驗：

1. 定製電路：開發者為程式定製電路，那性能肯定最好，但要花時間開發；

2. eDSL/DSL：開發者還是自己寫電路，但有一些可選框架幫開發者把 ZK 相關的問題解決掉，這樣可以平衡性能和開發體驗。

3. zkVM：開發者直接用現成的虛擬機裡跑 ZK，這非常方便但 Axiom 官方認為效率很低

因此，Axiom 選了第二種，專案方還為用戶提供了一套優化過的 ZK 模塊，使其可以自行設計電路。

與 Axiom 類似的專案還有 Herodotus ，但它想做的是跨鏈資訊傳輸的中間件。由於資訊處理是在鏈下，所以讓不同鏈獲得處理後的數據是很合理的思路。而另一個專案 Space and Time 則是用類似架構實現了數據索引。

3.3 鏈上游戲、DAO 治理等其他應用

除此以外，鏈上游戲，DAO 治理都可以用 ZK 輔助運算器。RISC Zero 認為，任何需要 250k gas 以上的計算使用 ZK 輔助運算器的話成本都會更低，但具體如何得出的還有待考究。DAO 治理也可以用到 ZK 輔助運算器，因為涉及多人和多個合約，這很耗計算資源。RISC Zero 稱使用 Bonsai 後 gas 費可以降 50%。ZKML 本質上也是 ZK 輔助運算器的思路，因此 Modulus Labs ，Giza 也是這個領域的專案，只不過 ZK 輔助運算器的概念更大。

此外，ZK 輔助運算器這個領域還有一些輔助性專案，比如 ezkl，它提供製作 ZK 電路的編譯器， ZK 部署的工具套件，把鏈上計算移到鏈下的工具等。

4.未來展望

輔助運算器使得鏈上應用擁有了如“雲”一樣的外部計算資源，它提供了相對廉價的大量計算，而鏈上只處理必要的計算。在實際情況下，zkVM 也可以在雲上面跑，ZK 輔助運算器本質上是一個架構，是把鏈上計算放到鏈下的方式，而鏈下計算資源由誰提供是不限制的。

本質上說，鏈下計算資源由傳統的大廠商，甚至去中心化的計算資源共享，和本地設備都有可能。這三個方向各有差異，傳統大廠可以做到相對成熟的鏈下計算解決方案，在未來去中心化計算資源的“魯棒性”可能更強，而用戶本地計算也很有想像空間。但目前很多 ZK 輔助運算器專案都選擇閉源提供服務的階段，因為這個賽道的上下遊尚未形成，無法把服務細化並交給不同專案，未來有兩種可能：

1. ZK 輔助運算器的每一個環節都有大量的專案相互競爭

2. 一個服務體驗良好的專案佔據大部分市場

從開發者的角度，其使用 ZK 輔助運算器時可能只會用一個“接口”專案，這也是亞馬遜雲佔據市場大量的原因，開發者會習慣於一種部署方式。但作為那一個鏈下計算資源的“接口”專案，背後接入了什麼計算服務提供商（傳統雲廠商、去中心化資源共享）就是另一個賽道值得討論的問題了。