“當我們討論隱私的時候,我們實際上是在保護鏈下數據,不被獲取;而當我們討論擴容的時候,我們是利用 ZK 節省鏈上計算空間”。本文中, Yolo 著重從生態發展角度,來分析 ZK 技術和其應用場景,描述目前 ZK 相關的競爭格局,並對未來發展的方向做了一些大膽暢想。
作者: YOLO SHEN,Cipholio Ventures
特別感謝: Nicole,ZhangYe 在此文章編輯過程中提供的幫助
TL;DR
- ZK 的技術具有隱私和擴容兩個最主要的使用場景,當我們討論隱私的時候,我們利用 ZK 技術保護鏈下數據,不被獲取;而當我們討論擴容的時候,我們則是利用 ZK 節省鏈上計算空間。舉個例子,如果我要確認某個賬戶有 100 塊錢,傳統區塊鏈的方式是讓每個節點都確認一遍,而現在我只需要一個節點,在保證數據完整性的前提下,找到最近淨流入 100 塊的憑證,即可證明賬戶有 100 元,區別就是前者需要大量計算和證明,後者只需要鏈下證明。
- ZKVM 發展的核心權衡在於是發揮 ZK 潛力重要,還是發揮目前開發者資源重要。圍繞著發揮 ZK 潛力,意味著 CPU 寄存器的硬件加速,IR 語言和 assembly 語言的再組織;而圍繞著利用開發者資源,則意味著 Solidity 轉化 bytecode 後,如何將 Bytecode 所映射的 opcode,進行 ZK 證明的問題。
- 以 assembly 語言獨立設計 ZK 證明的專用型的 ZKapp,由於具有較低的可組合性和解耦能力,將在未來的發展過程中面臨很大的阻礙。這些方案由於和其他 ZK 方案不兼容 VM,不兼容語言,不兼容,存在較大的調用難度。
- 按照模塊化區塊鏈的觀點,L1 解決共識問題,L2 解決計算和執行問題,DA 層解決數據可得性和完整性的問題。由於 Zk 類的 L2 其證明。
- 依賴,時間序列的交易 Log,數據安全性和證明的完整性決定了其執行的可靠性。在目前 ZK 方案大部分閉源的狀態下,ZK 安全審計有很大的發展前景。
- 由於 ZKP 依賴鏈下數據,交由 DA 鏈則會失去數據的隱私性。想要兼容數據隱私性和 ZK 證明節點不作惡,就需要新的解決方案。我們看好未來諸如 MPC/FHE 等安全計算方案。
- 隨著不同 Circuit 的不斷成熟,Zk 證明可能也會迎來提效和分工,ZK 證明的硬件提速方案,以及專業的 ZK 礦工也可能應運而生。
- ZKP 經驗局限性問題。典型問題包括:約束系統(constraint system)無法有效約束數據,當證明一些複雜交叉的命題時,約束面臨不夠充分的問題;私有數據洩露,私有數據當做公開數據處理;針對鏈下數據的攻擊,合約層的 “metadata-attack”;ZK 證明節點的作惡等等。
- 短期來看,ZK 方案的安全性存在局限,目前大量的共識還是建立在鏈下節點的自律上,缺乏一系列必要的工具(測試,證明,等等),來保障鏈下環境的安全性。
概覽
一直以來 ZK 技術由於其重巒疊嶂的專業術語,使得人們難以對這一主題充分討論。本文將著重從生態發展角度,來分析 ZK 技術和其應用場景,描述目前 ZK 相關的競爭格局,並為未來發展的方向做一些暢想。本文著重討論:
- 當我們在討論 ZK 技術的時候我們在討論什麼?(知識鋪墊,機構投資者可以從第二部分開始讀。)
- 從技術發展角度看待 gzkvm(generalized zk vm)的發展規律和結構?
- 目前主要 ZKvm 技術方案的比較?
- 分析和展望
一:虛擬機 ABC — 從日常計算機說起
在介紹 ZKEVM 相關的知識以前,我想先從我們日常的計算機的結構講起。我們都知道計算機分為軟件和硬件兩部分,為了讓軟件順利的在硬件上運行,我們需要為軟件匹配適宜的運行環境。從結構來看,運行環境由【硬件+操作系統】兩部分組成。
其中黃色部分為硬件,綠色部分為操作系統。這裡可能有同學會提出疑問:為什麼運行環境不等價於操作系統,這主要是因為操作系統難以兼容所有的硬件,只有操作系統和硬件的匹配才能為軟件提供服務。這個問題,我們再後面 ZKVM 的發展路線鐘,還會提到。
有了運行環境,我們還需要具體的軟件(程序/app)才可以實現具體需求。那麼程序是怎樣跑起來的呢?
從圖上我們可以看到,軟件經操作系統交由硬件層來進行計算的整個流程,在過程中程序語言經過了三個階段的變化,高級語言用來寫程序完成實際需求,彙編語言用來和計算機溝通,底層本地代碼(16 進制數)由計算機具體執行。具體來看,程序員完成 APP 的代碼後,經由轉譯器翻譯成 obj(目標語言),這些離散的目標語言,將會通過操作系統中的 Linker 得以鏈接,兩者輸出可執行的 exe 文件存儲在硬盤中。
當運行的時候,exe 文件會將數據放入內存,經由 CPU 將 Obj 轉化為本地代碼(字節碼)進行計算操作,實現 app 的 I/O。這一過程中存在非常多的選擇,多樣的語言,多樣的操作系統,多樣的硬件,從商業角度面臨了非常多的 Tradeoff,而這些選擇最後便體現在編譯器內核 LLVM(low level virtual machine)的改進中。
下圖我們可以看到,硬件(黃色)和操作系統之間有多種對應關係和限制條件:
- 同一類型的硬件可以安裝多種操作系統,不同硬件需要匹配不同類型的操作系統。 例如, 同樣的 AT 兼容機 A 中, 既可以安裝 Windows, 也可以安裝 LinuxB 等操作系統。又如,X86 芯片的硬件,需要 x86 版本的 windows 來匹配。這主要是由於操作系統底層彙編語言需要與芯片匹配。
- App 的成功運行需要與 CPU 匹配,也需要與操作系統匹配。 例如:1,為了保證 Office 2017 的正常運行, 需要具備 x86C 的 CPU;2,有些 APP 只能在 window XP 上運行,在 2000 上則運行不了。
- 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):
- 本地的計算。
- Circuit 的定義。比如確認你錢包有沒有錢,確認信息是不是完整,確認簽名是否正確。
- 算術化證明。運用數學方法證明計算是可執行的。
- 將算數證明結果和實際結果比對。
- 將結果遞交上鍊。
以 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 承上啟下的作用:
- 站在 ZK 電路硬件層的角度,EVM 可能無法全部兼容。由於 EVM 有一些變長的指令,比如 CALL,DATACOPY,EXP,CREATE 等等,這些對 ZK 電路不友好。
- 站在開發者角度,能否不需要重新學習語言(Solidity 仍然兼容),保留 EVM 的 API 特性。在這種情況下,整個生態就可能失去對一些 ZK 算法的支持。
除此以外,ZKVM 還需要考量很多技術兼容,比如:
- 寄存器的兼容。Machine Type. 傳統 EVM 是一個 Stack-based 的 State machine,因此大量的計算式串聯的,不可並行的,這確保了整個計算機的原子性。這一架構對於 ZK 是非常不利的,如果要發揮 ZK 算法的全部效率,則需要做一個 Register-Based,也就是以 CPU-寄存器為核心架構來設計 VM。
- 語言上的兼容。Function Calls. VM 系統將底層特性封裝成 API,如何讓 API 支持動態調用,支持像 Python 一樣的高級語言。
- 計算機底層的兼容。Native Field. 不同的 CPU 有不同的位數,在不同算法上的表現不同。需要為 ZK 專用計算機做謀劃。
- 傳統公鏈結構的兼容。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 節省鏈上計算空間。
- ZKVM 發展的核心權衡技術與 devs。圍繞著發揮 ZK 潛力,意味著 CPU 寄存器的硬件加速,IR 語言和 assembly 語言的再組織;而圍繞著利用開發者資源,則意味著 Solidity 轉化 bytecode 後,如何將 Bytecode 所映射的 opcode,進行 ZK 證明的問題。
- 以 assembly 語言獨立設計 ZK 證明的專用型的 ZKapp,由於具有較低的可組合性和解耦能力,將在未來的發展過程中面臨很大的阻礙。這些方案由於和其他 ZK 方案不兼容 VM,不兼容語言,不兼容證明,存在較大的調用難度。
- 按照模塊化區塊鏈的觀點,L1 解決共識問題,L2 解決計算和執行問題,DA 層解決數據可得性和完整性的問題。由於 Zk 類,數據安全性和證明的完整性決定了其執行的可靠性。這裡有一對矛盾,如果我們不信任鏈下節點,希望將數據交由 DA 獨立存儲,那麼對 DA 鏈就提出安全的要求,;如果存在本地,保證數據不被篡改,就需要證明節點本身不去作惡。這些都提升了對 MPC/FHE 解決方案的需求。
- 在目前 ZK 方案大部分閉源的狀態下,目前大量的共識還是建立在鏈下節點的自律上,缺乏一系列必要的工具(測試,證明,等等),來保障鏈下環境的安全性。未來 contraint 設計和代數證明將成為兩個最主要的審計環節。
- ZK 生態主要的風險。典型問題包括:約束系統(constraint system)不充分。當證明一些複雜交叉的命題時,約束面臨不夠充分的問題;私有數據洩露。私有數據當做公開數據處理;針對鏈下數據的攻擊,合約層的 “metadata-attack”;ZK 證明節點的作惡等等。
- 隨著不同 Circuit 的不斷成熟,Sequencer/Roller/Miner 也會迎來提效和分工,我們期待 ZK 證明的硬件加速機會。
參考材料:
- Shize J. & Li F. How program works . (Ren min you dian chu ban she, 2015).
- 編譯器與解釋器的區別和工作原理. https://zhuanlan.zhihu.com/p/39141067
- The Zero Knowledge Frontier: On SNARKs, STARKs, and Future Applications. https://research.thetie.io/zero-knowledge-starks-snarks/
- ZK Identity: Why and How (Part 1). https://0xparc.org/blog/zk-id-1
- ZK Identity: Why and How (Part 2). https://0xparc.org/blog/zk-id-2
- https://twitter.com/LuozhuZhang/status/1523603947809693697
- Hermez Team. Jordi Baylina : ZK-EVM. https://www.youtube.com/watch?v=17d5DG6L2nw
- Introducing Hermez zkEVM. https://blog.hermez.io/introducing-hermez-zkevm/
- ZKEVM EVM Circuit Explore. https://hackmd.io/@liangcc/zkvmbook/%2Fq8EhMIp_TimpPWWFXtwOVw
- Ethereum EVM illustrated. Exploring some mental models and implementations. https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
- Introduction to ZKPs slides video. https://www.youtube.com/watch?v=AaEPRKmVazk&list=PLOEty2U8Y69UWNCoQbe__zs4Fiv4J9DAe&index=4
- Fundamentals of Zero Knowledge: Scaling Ethereum with STARKs. https://www.youtube.com/watch?v=AaEPRKmVazk&list=PLOEty2U8Y69UWNCoQbe__zs4Fiv4J9DAe&index=4
- ZK HACK #5 — Introduction to Aztec Connect. https://www.youtube.com/watch?v=Cs9cI2v1hdE
- zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]. https://www.youtube.com/watch?v=l_pIrHVz87I
- https://twitter.com/LuozhuZhang/status/1521124870385405953?s=20&t=tAtoypY5N_lbOBYKd86dlQ
- Zero knowledge, from proofs to rollups. https://github.com/thecryptofruit/education/blob/master/zk-proofs-rollups.md .
- ZK7: Structuring Computation for Privacy-Preserving Apps — Wei Dai — Bain Capital Crypto. https://www.youtube.com/watch?v=W93SMLywRT4
- ZK Hack Mini #1 — Introduction to Miden VM https://www.youtube.com/watch?v=Q8xYSOx82U0
- Polygon Hermez Fireside Chat. https://www.youtube.com/watch?v=dcR1lbJCqP8
- Navigating Privacy on Public Blockchains. https://wdai.us/posts/navigating-privacy/
免責聲明:作為區塊鏈信息平台,本站所發布文章僅代表作者及嘉賓個人觀點,與 Web3Caff 立場無關。本文內容僅用於信息分享,均不構成任何投資建議及要約,並請您遵守所在國家或地區的相關法律法規。