作者: 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