作者： Yolo，Cipholio Ventures
1、ZK的技術具有隱私和擴容兩個最主要的使用場景，當我們討論隱私的時候，我們利用ZK技術保護鏈下數據，不被獲取；而當我們討論擴容的時候，我們則是利用ZK節省鏈上計算空間。舉個例子，如果我要確認某個賬戶有100塊錢，傳統區塊鏈的方式是讓每個節點都確認一遍，而現在我只需要一個節點，在保證數據完整性的前提下，找到最近淨流入100塊的憑證，即可證明賬戶有100元，區別就是前者需要大量計算和證明，後者只需要鏈下證明。
2、ZKVM發展的核心權衡在於是發揮ZK潛力重要，還是發揮目前開發者資源重要。圍繞著發揮ZK潛力，意味著CPU寄存器的硬件加速，IR語言和assembly語言的再組織；而圍繞著利用開發者資源，則意味著Solidity轉化bytecode後，如何將Bytecode所映射的opcode，進行ZK證明的問題。
3、按照模塊化區塊鏈的觀點，L1解決共識問題，L2解決計算和執行問題，DA層解決數據可得性和完整性的問題。由於Zk類的L2其證明。
4、以assembly 語言獨立設計ZK證明的專用型的ZKapp，由於具有較低的可組合性和解耦能力，將在未來的發展過程中面臨很大的阻礙。這些方案由於和其他ZK方案不兼容VM，不兼容語言，不兼容，存在較大的調用難度。
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相關的競爭格局，並為未來發展的方向做一些暢想。本文著重討論：
- 當我們在討論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）:
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與JVM非常相似。兩者都是執行字節碼的堆棧機。 EVM增加了一個存儲的概念，它的字節碼指令更適合於合同開發。
圖中我們以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節省鏈上計算空間。
- 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證明的硬件加速機會。
聲明：本內容為作者獨立觀點，不代表0x财经 立場，且不構成投資建議，請謹慎對待，如需報導或加入交流群，請聯繫微信：VOICE-V。
來源： Cipholio