“當我們討論隱私的時候，我們實際上是在保護鏈下數據，不被獲取；而當我們討論擴容的時候，我們是利用 ZK 節省鏈上計算空間”。本文中, Yolo 著重從生態發展角度，來分析 ZK 技術和其應用場景，描述目前 ZK 相關的競爭格局，並對未來發展的方向做了一些大膽暢想。

作者： YOLO SHEN，Cipholio Ventures

特別感謝： Nicole，ZhangYe 在此文章編輯過程中提供的幫助

TL;DR

  1. ZK 的技術具有隱私和擴容兩個最主要的使用場景，當我們討論隱私的時候，我們利用 ZK 技術保護鏈下數據，不被獲取；而當我們討論擴容的時候，我們則是利用 ZK 節省鏈上計算空間。舉個例子，如果我要確認某個賬戶有 100 塊錢，傳統區塊鏈的方式是讓每個節點都確認一遍，而現在我只需要一個節點，在保證數據完整性的前提下，找到最近淨流入 100 塊的憑證，即可證明賬戶有 100 元，區別就是前者需要大量計算和證明，後者只需要鏈下證明。
  2. ZKVM 發展的核心權衡在於是發揮 ZK 潛力重要，還是發揮目前開發者資源重要。圍繞著發揮 ZK 潛力，意味著 CPU 寄存器的硬件加速，IR 語言和 assembly 語言的再組織；而圍繞著利用開發者資源，則意味著 Solidity 轉化 bytecode 後，如何將 Bytecode 所映射的 opcode，進行 ZK 證明的問題。
  3. 以 assembly 語言獨立設計 ZK 證明的專用型的 ZKapp，由於具有較低的可組合性和解耦能力，將在未來的發展過程中面臨很大的阻礙。這些方案由於和其他 ZK 方案不兼容 VM，不兼容語言，不兼容，存在較大的調用難度。
  4. 按照模塊化區塊鏈的觀點，L1 解決共識問題，L2 解決計算和執行問題，DA 層解決數據可得性和完整性的問題。由於 Zk 類的 L2 其證明。
  5. 依賴，時間序列的交易 Log，數據安全性和證明的完整性決定了其執行的可靠性。在目前 ZK 方案大部分閉源的狀態下，ZK 安全審計有很大的發展前景。
  6. 由於 ZKP 依賴鏈下數據，交由 DA 鏈則會失去數據的隱私性。想要兼容數據隱私性和 ZK 證明節點不作惡，就需要新的解決方案。我們看好未來諸如 MPC/FHE 等安全計算方案。
  7. 隨著不同 Circuit 的不斷成熟，Zk 證明可能也會迎來提效和分工，ZK 證明的硬件提速方案，以及專業的 ZK 礦工也可能應運而生。
  8. ZKP 經驗局限性問題。典型問題包括：約束系統（constraint system）無法有效約束數據，當證明一些複雜交叉的命題時，約束面臨不夠充分的問題；私有數據洩露，私有數據當做公開數據處理；針對鏈下數據的攻擊，合約層的 “metadata-attack”；ZK 證明節點的作惡等等。
  9. 短期來看，ZK 方案的安全性存在局限，目前大量的共識還是建立在鏈下節點的自律上，缺乏一系列必要的工具（測試，證明，等等），來保障鏈下環境的安全性。

概覽

一直以來 ZK 技術由於其重巒疊嶂的專業術語，使得人們難以對這一主題充分討論。本文將著重從生態發展角度，來分析 ZK 技術和其應用場景，描述目前 ZK 相關的競爭格局，並為未來發展的方向做一些暢想。本文著重討論：

  1. 當我們在討論 ZK 技術的時候我們在討論什麼？(知識鋪墊，機構投資者可以從第二部分開始讀。)
  2. 從技術發展角度看待 gzkvm（generalized zk vm）的發展規律和結構?
  3. 目前主要 ZKvm 技術方案的比較？
  4. 分析和展望

一：虛擬機 ABC — 從日常計算機說起

在介紹 ZKEVM 相關的知識以前，我想先從我們日常的計算機的結構講起。我們都知道計算機分為軟件和硬件兩部分，為了讓軟件順利的在硬件上運行，我們需要為軟件匹配適宜的運行環境。從結構來看，運行環境由【硬件+操作系統】兩部分組成。

其中黃色部分為硬件，綠色部分為操作系統。這裡可能有同學會提出疑問：為什麼運行環境不等價於操作系統，這主要是因為操作系統難以兼容所有的硬件，只有操作系統和硬件的匹配才能為軟件提供服務。這個問題，我們再後面 ZKVM 的發展路線鐘，還會提到。

有了運行環境，我們還需要具體的軟件（程序/app）才可以實現具體需求。那麼程序是怎樣跑起來的呢？

從圖上我們可以看到，軟件經操作系統交由硬件層來進行計算的整個流程，在過程中程序語言經過了三個階段的變化，高級語言用來寫程序完成實際需求，彙編語言用來和計算機溝通，底層本地代碼（16 進制數）由計算機具體執行。具體來看，程序員完成 APP 的代碼後，經由轉譯器翻譯成 obj（目標語言），這些離散的目標語言，將會通過操作系統中的 Linker 得以鏈接，兩者輸出可執行的 exe 文件存儲在硬盤中。

當運行的時候，exe 文件會將數據放入內存，經由 CPU 將 Obj 轉化為本地代碼（字節碼）進行計算操作，實現 app 的 I/O。這一過程中存在非常多的選擇，多樣的語言，多樣的操作系統，多樣的硬件，從商業角度面臨了非常多的 Tradeoff，而這些選擇最後便體現在編譯器內核 LLVM（low level virtual machine）的改進中。

下圖我們可以看到，硬件（黃色）和操作系統之間有多種對應關係和限制條件：

  1. 同一類型的硬件可以安裝多種操作系統，不同硬件需要匹配不同類型的操作系統。  例如， 同樣的 AT 兼容機 A 中， 既可以安裝 Windows， 也可以安裝 LinuxB 等操作系統。又如，X86 芯片的硬件，需要 x86 版本的 windows 來匹配。這主要是由於操作系統底層彙編語言需要與芯片匹配。
  2. App 的成功運行需要與 CPU 匹配，也需要與操作系統匹配。  例如：1，為了保證 Office 2017 的正常運行， 需要具備 x86C 的 CPU；2，有些 APP 只能在 window XP 上運行，在 2000 上則運行不了。
  3. CPU 只能解釋其自身固有的機器語言。不同的 CPU 能解釋的機器語言的種類也是不同的。  也就是說，用不同高級語言編寫的 APP，如果不能通過【操作系統】編譯成 CPU 可以運算的語言，CPU 也是無法執行的。

二：Zk VM 是什麼？

通常我們在討論 ZK 的時候，通常是在三個語境當中：

一，使用 ZK 作為 Scaling 方案 RollupL2。

二，使用 zkp 進行證明的應用，dydx，Zklink 等等。

三，zkproof 作為一種密碼算法。

用什麼語言，在什麼環境下，用什麼硬件執行？這是廣義 VM 所要解決的問題。

前面我們剛剛介紹了傳統操作系統（也是一種 VM），再來看 ZKVM 的時候，我們可以發現，ZKVM 也完成了類似的職能，完成了硬件層（原生鏈+ZK 證明系統）和高級語言（solidity 或者原生 ZK 語言）的溝通。其核心是數據證明與狀態更新，當系統接收到兩類 input，原始數據（狀態和指令）和證明（對於狀態和指令的相關證明），比對計算後，輸出指令（更新狀態）和 ZKP（證明），提交 L1 進行共識廣播。

具體來看 ZK 證明經過幾個部分（by  JP Aumasson, Taurus）：

  1. 本地的計算。
  2. Circuit 的定義。比如確認你錢包有沒有錢，確認信息是不是完整，確認簽名是否正確。
  3. 算術化證明。運用數學方法證明計算是可執行的。
  4. 將算數證明結果和實際結果比對。
  5. 將結果遞交上鍊。

以 Scroll 的方案為例，我們看到從 Geth 出發，系統完成了本地的計算，將交易 Trace（交易的歷史 log）拆解轉化成 Circuits 算子，然後使用算數方法（列如多項式拆解，密碼學）得出 ZK 證明。然後比對數據和證明，如果無誤即可廣播上鍊。這當中涉及許多關鍵技術，比如如何設定 Circuits，有哪幾類 Circuits？如何對 Circuits 進行拆解? 整個確認方法，可以想像一張巨大的表，每一個變量都有其參數，在已知歷史數據的背景下，求特定結果的必然性。

舉個例子，如果我要確認某個賬戶有 100 塊錢，傳統區塊鏈的方式是讓每個節點都確認一遍，而現在我只需要一個節點，在保證數據完整性的前提下，再加上最近淨流入 100 塊的證明，然後進行確認（案例中的情形比較簡單，看一眼便知，實際情況中是需要數學運算的。）完成後，即可證明賬戶有 100 元，區別就是前者需要每一個節點的計算，後者只需要單一節點計算和 zk 證明。在這個例子中，確認的是 “如何在鏈下證明賬戶有充足餘額”，證明需要的約束是 “當最近歷史時間軸內賬戶淨流入大於 100（實質基於 Merkle Root 的證明）“，然後將節點計算結果與 ZKP 比對，從而決定狀態是否正確。

ZK 語言的公約數

根據 MidenVM 的總結，目前市場上主要的 Zkapp 所採用的的工具都是以 WASM 和 RISC V 為主的彙編語言，一些工具包能讓應用很快打上 “ZK” 的概念或者標籤。但稍微拆解一下結構，我們會發現傳統智能合約由 L1 來保證安全性，全網廣播形成共識的安全性已經經過歷史檢驗了，而利用鏈下 ZKP 證明，則存在 ZKP 證明節點是否作惡的問題。

先不論 Devs 是否能夠合理設立約束（Contraint）的能力問題，如何防範 ZKP 證明節點的作惡意願問題，無疑是更為重要的。舉例來看，一些 ZK dex 更像是在 Cex 和 Dex 之間尋找一個平衡點，相較於 Cex 而言，用戶可以將資金保管在自己的 L1 賬戶；而相對 Dex 而言，又能有更優的效率表現。但在實踐中，大量的項目都存在鏈下證明的安全隱患。

此外，由於從 APP 層到 IR 層，都是由 zkAPP 團隊獨立開發，家家戶戶有著自己的編程習慣和輪子庫，這也導致團隊與團隊之間難以形成可組合性，也不利於加速市場分工和硬件設備的加速。因此，市場破解尋找一個在密碼學和高級語言之間找到一層公約數。來為各類應用提供一個通用的框架，而 ZK-VM 則是適配整套系統，承上啟下的重要部分。

EVM is quite similar to JVM in terms of execution model. Both are stack machines executing bytecodes. EVM adds a concept of storage and its bytecode instructions are more suited for contract development. link

圖中我們以 ETH 舉例，傳統 ETH 由三部分構成，ETH 網絡（節點+共識機制），EVM，Dapp 開發生態。這裡我們可以很清晰的感受到 ZK 承上啟下的作用：

  1. 站在 ZK 電路硬件層的角度，EVM 可能無法全部兼容。由於 EVM 有一些變長的指令，比如 CALL，DATACOPY，EXP，CREATE 等等，這些對 ZK 電路不友好。
  2. 站在開發者角度，能否不需要重新學習語言（Solidity 仍然兼容），保留 EVM 的 API 特性。在這種情況下，整個生態就可能失去對一些 ZK 算法的支持。

除此以外，ZKVM 還需要考量很多技術兼容，比如：

  1. 寄存器的兼容。Machine Type. 傳統 EVM 是一個 Stack-based 的 State machine，因此大量的計算式串聯的，不可並行的，這確保了整個計算機的原子性。這一架構對於 ZK 是非常不利的，如果要發揮 ZK 算法的全部效率，則需要做一個 Register-Based，也就是以 CPU-寄存器為核心架構來設計 VM。
  2. 語言上的兼容。Function Calls. VM 系統將底層特性封裝成 API，如何讓 API 支持動態調用，支持像 Python 一樣的高級語言。
  3. 計算機底層的兼容。Native Field. 不同的 CPU 有不同的位數，在不同算法上的表現不同。需要為 ZK 專用計算機做謀劃。
  4. 傳統公鏈結構的兼容。Sequencer/Roller/Miner.

三：ZKVM 的架構：

主流技術方案

用什麼語言，在什麼環境下，用什麼硬件執行？這是廣義 VM 所要解決的問題。

VM 當中最為重要的內核便是 LLVM（low-level-virtual-machine），他可以看作是編譯器最重要的內核。圖中是原始 EVM 的運作方案，智能合約通過 LLVM IR 的中間代碼進行轉化，轉化成 Bytecode。這些 Bytecode 會存儲在區塊鏈上，當智能合約被調用的時候，便會將 Bytecode 轉化成對應的 Opcode，再由 EVM 和節點硬件來執行。

結合上 ZK，各個不同的解決方案是怎樣實現的呢？

  • Starkware:

Starkware 由於在整個 ZK 領域起步較早，技術積累較為充分，擁有一定的技術領先。他是代表性的 ZK 中心主義的技術架構，圍繞 ZK 構建了 Cairo VM 和 Cairo 的語言。但由於他是閉源狀態，一些技術細節並不清晰。其缺點在於，Cairo 的學習成本。雖然官方也開發了 Solidity 轉換 Cairo 的一些框架，但由於其底層核心均建立於 CairoVM 上，意味著有相當多 Solidity-EVM 兼容的特徵會損失。

  • Zksync:

ZKsync 的框架兼容了 EVM 和 ZK 兩方面的特點，將 Solidity 和其自主開發的電路語言 Zinc 做了一個融合，在編譯器內部將兩者在 IR 層面上做了統一。其優點在於編譯器內核的 LLVM 可以兼容多種語言。Zksync 也是閉源框架。

Hermez by Polygon

Scroll

  • HermZ 和 Scroll 兩個技術方案更側重以太坊生態，他們在 Bytecode 上和 ETH 生態做了融合。由於 EVM 天然支持 bytecode 和其對應的 opcode，這兩者和 ETH 生態有著更高的融合性。Solidity 在這兩個 Zkvm 上能充分的調用 EVM 的 API，最大保留了 EVM 的架構優點。兩個方案有所差異的是，Hermz 會將 opcode 在內部進行統一，然後再進行證明；而 Scroll 則會將 Opcode 拆解 circuit 進行證明，再進行整合。為什麼要選擇兼容 EVM？因為 EVM 當中有一些架構經過檢驗，安全性比較好，兼容性也比較好。舉例來說 Geth 模型和 RPC 架構，這些 API 已經被 EVM 較好的封裝，也經過歷史檢驗。

總結來看，Starkware 最底層從 WASM 和機器碼層面進行統一，ZKsync 最淺在 IR 層面進行統一，Hermz 和 Scroll 居中在 Bytecode 上進行統一。Starkware 是技術轉型最徹底的，但也是用戶學習門檻最高的；而 Zksync 相對比較均衡，保留一部分 solidity 特性，發揮局部 ZK 性能；Hermz 和 Scroll 相對最易應用和拆解，全面集成 Bytecode，整合 EVM，尤其是 Scroll，開放 ZK 證明，也給了硬件加速更大的空間。相對來說，無論是技術驅動還是生態整合驅動，都在未來有各自的發展空間，“貿工技” 還是 “技工貿” 都有機會找到自己的場景，發揮更大價值。

如果我們對照回顧 Windows 歷史，在強有力的操作系統出現以前，不同的開發者需要對不同的硬件，掌握不同的開發工具。不掌握彙編，不理解計算機底層的開發者在開發過程中會遇到非常多的挫折。而操作系統在硬件當中尋找最大的公約數，將 CPU 以外的 I/O 系統都封裝成統一的接口，這些技術積累，使得軟件開發的門檻大大降低了，也使得大部分程序員只需要理解高級語言即可，即使不具備彙編和底層代碼知識仍然可以寫出漂亮的 App。對照看到 ZKVM 的發展，我們可以看到一些端倪，如果說現在的 ZKapp 需要傳統程序員+彙編+密碼學知識儲備才能開發，未來隨著 ZKVM 的成熟，越來越多的底層技術封裝進高級語言當中，開發門檻漸次降低，生態繁榮是可以想見的。

對於 Founder 而言，有兩個注意點：

1，ZK 技術將鏈上共識轉為鏈下證明，目前證明技術還不成熟，相關審計機構，測試工具都存在空白缺位。

2，ZK 技術的使用場景尚待發掘。通用型 ZKVM 緊鑼密鼓開發，ZK 對應高級語言也有待技術人員的學習，從技術成熟到解決問題還有很長一段時間。想要用 ZK 解決問題，founder 需要回答：如果是個細分場景，是否需要自己用 WASM 去搭建，一旦 ZKVM 成熟，自己的技術積累是否還有先發優勢？是否支持其他 ZKapp 調用？

展望與結論

ZK 的技術具有隱私和擴容兩個最主要的使用場景，當我們討論隱私的時候，我們實際上是在保護鏈下數據，不被獲取；而當我們討論擴容的時候，我們是利用 ZK 節省鏈上計算空間。

  1. ZKVM 發展的核心權衡技術與 devs。圍繞著發揮 ZK 潛力，意味著 CPU 寄存器的硬件加速，IR 語言和 assembly 語言的再組織；而圍繞著利用開發者資源，則意味著 Solidity 轉化 bytecode 後，如何將 Bytecode 所映射的 opcode，進行 ZK 證明的問題。
  2. 以 assembly 語言獨立設計 ZK 證明的專用型的 ZKapp，由於具有較低的可組合性和解耦能力，將在未來的發展過程中面臨很大的阻礙。這些方案由於和其他 ZK 方案不兼容 VM，不兼容語言，不兼容證明，存在較大的調用難度。
  3. 按照模塊化區塊鏈的觀點，L1 解決共識問題，L2 解決計算和執行問題，DA 層解決數據可得性和完整性的問題。由於 Zk 類，數據安全性和證明的完整性決定了其執行的可靠性。這裡有一對矛盾，如果我們不信任鏈下節點，希望將數據交由 DA 獨立存儲，那麼對 DA 鏈就提出安全的要求，；如果存在本地，保證數據不被篡改，就需要證明節點本身不去作惡。這些都提升了對 MPC/FHE 解決方案的需求。
  4. 在目前 ZK 方案大部分閉源的狀態下，目前大量的共識還是建立在鏈下節點的自律上，缺乏一系列必要的工具（測試，證明，等等），來保障鏈下環境的安全性。未來 contraint 設計和代數證明將成為兩個最主要的審計環節。
  5. ZK 生態主要的風險。典型問題包括：約束系統（constraint system）不充分。當證明一些複雜交叉的命題時，約束面臨不夠充分的問題；私有數據洩露。私有數據當做公開數據處理；針對鏈下數據的攻擊，合約層的 “metadata-attack”；ZK 證明節點的作惡等等。
  6. 隨著不同 Circuit 的不斷成熟，Sequencer/Roller/Miner 也會迎來提效和分工，我們期待 ZK 證明的硬件加速機會。

參考材料：

  1. Shize J. & Li F.  How program works . (Ren min you dian chu ban she, 2015).
  2. 編譯器與解釋器的區別和工作原理.  https://zhuanlan.zhihu.com/p/39141067
  3. The Zero Knowledge Frontier: On SNARKs, STARKs, and Future Applications.  https://research.thetie.io/zero-knowledge-starks-snarks/
  4. ZK Identity: Why and How (Part 1).  https://0xparc.org/blog/zk-id-1
  5. ZK Identity: Why and How (Part 2).  https://0xparc.org/blog/zk-id-2
  6. https://twitter.com/LuozhuZhang/status/1523603947809693697
  7. Hermez Team. Jordi Baylina : ZK-EVM.  https://www.youtube.com/watch?v=17d5DG6L2nw
  8. Introducing Hermez zkEVM.  https://blog.hermez.io/introducing-hermez-zkevm/
  9. ZKEVM EVM Circuit Explore.  https://hackmd.io/@liangcc/zkvmbook/%2Fq8EhMIp_TimpPWWFXtwOVw
  10. Ethereum EVM illustrated. Exploring some mental models and implementations.  https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
  11. Introduction to ZKPs slides video.  https://www.youtube.com/watch?v=AaEPRKmVazk&list=PLOEty2U8Y69UWNCoQbe__zs4Fiv4J9DAe&index=4
  12. Fundamentals of Zero Knowledge: Scaling Ethereum with STARKs.  https://www.youtube.com/watch?v=AaEPRKmVazk&list=PLOEty2U8Y69UWNCoQbe__zs4Fiv4J9DAe&index=4
  13. ZK HACK #5 — Introduction to Aztec Connect.  https://www.youtube.com/watch?v=Cs9cI2v1hdE
  14. zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus].  https://www.youtube.com/watch?v=l_pIrHVz87I
  15. https://twitter.com/LuozhuZhang/status/1521124870385405953?s=20&t=tAtoypY5N_lbOBYKd86dlQ
  16. Zero knowledge, from proofs to rollups.  https://github.com/thecryptofruit/education/blob/master/zk-proofs-rollups.md .
  17. ZK7: Structuring Computation for Privacy-Preserving Apps — Wei Dai — Bain Capital Crypto.  https://www.youtube.com/watch?v=W93SMLywRT4
  18. ZK Hack Mini #1 — Introduction to Miden VM  https://www.youtube.com/watch?v=Q8xYSOx82U0
  19. Polygon Hermez Fireside Chat.  https://www.youtube.com/watch?v=dcR1lbJCqP8
  20. Navigating Privacy on Public Blockchains.  https://wdai.us/posts/navigating-privacy/

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。