APP:Cipholio 深度分析：漫談ZKVM的方案及未來_code幣騙局

TL;DR

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經驗局限性問題。典型問題包括：約束系統無法有效約束數據，當證明一些復雜交叉的命題時，約束面臨不夠充分的問題；私有數據泄露，私有數據當做公開數據處理；針對鏈下數據的攻擊，合約層的“metadata-attack”；ZK證明節點的作惡等等。

Optimism：5月31日OP流通量將增加，會有大量鏈上轉賬用于分發:5月18日消息，Optimism 發推表示，伴隨著 OP 推出即將滿一周年，5 月 31 日 OP 流通量將增加，在此之前的兩周內，用戶可能會注意到大量鏈上轉賬，這些是為分發做準備的計劃交易。[2023/5/18 15:11:07]

9、短期來看，ZK方案的安全性存在局限，目前大量的共識還是建立在鏈下節點的自律上，缺乏一系列必要的工具，來保障鏈下環境的安全性。

概覽

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

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

一、虛擬機ABC--從日常計算機說起

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

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

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

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

彭博社：傳統金融公司最有可能從美國加密托管新規中獲益:2月22日消息，彭博社發文稱，傳統金融公司及其支持的加密貨幣托管機構最有可能從美國保護數字資產監管擬議的變化中獲利，這要歸功于現有的許可證組合以及在處理客戶資金方面值得信賴的聲譽。

對傳統金融公司六位高管的采訪顯示，傳統金融客戶對數字資產托管服務的興趣正在上升，與此同時，紐約梅隆銀行和納斯達克等大型機構的發言人表示，它們正在繼續打造自己的數字資產托管產品，評估擬議的規則變化可能對其計劃產生的影響。[2023/2/22 12:21:54]

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

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

同一類型的硬件可以安裝多種操作系統，不同硬件需要匹配不同類型的操作系統。例如，同樣的AT兼容機A中，既可以安裝Windows，也可以安裝LinuxB等操作系統。又如，X86芯片的硬件，需要x86版本的windows來匹配。這主要是由于操作系統底層匯編語言需要與芯片匹配。

App的成功運行需要與CPU匹配，也需要與操作系統匹配。例如：1，為了保證Office2017的正常運行，需要具備x86C的CPU；2，有些APP只能在windowXP上運行，在2000上則運行不了。

CPU只能解釋其自身固有的機器語言。不同的CPU能解釋的機器語言的種類也是不同的。也就是說，用不同高級語言編寫的APP，如果不能通過編譯成CPU可以運算的語言，CPU也是無法執行的。

二、ZkVM是什么？

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

使用ZK作為Scaling方案RollupL2。使用zkp進行證明的應用，dydx，Zklink等等。zkproof作為一種密碼算法。用什么語言，在什么環境下，用什么硬件執行？這是廣義VM所要解決的問題。

Binance推出原生預言機服務Binance Oracle:10月26日消息，Binance 推出原生預言機服務 Binance Oracle，允許區塊鏈智能合約與現實世界的數據連接，首先從 BNB Chain 開始。Binance Oracle 將允許 BNB 鏈上現有的去中心化應用程序（DApps）和 Web3 生態系統合作伙伴訪問現有數據源和高級計算，目前已有十多個 BNB Chain 項目與 Binance Oracle 網絡集成。（CoinDesk）[2022/10/27 11:46:18]

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

具體來看ZK證明經過幾個部分:

1.本地的計算；

2.Circuit的定義。比如確認你錢包有沒有錢，確認信息是不是完整，確認簽名是否正確；

3.算術化證明：運用數學方法證明計算是可執行的。

4.將算數證明結果和實際結果比對

5.將結果遞交上鏈

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

舉個例子，如果我要確認某個賬戶有100塊錢，傳統區塊鏈的方式是讓每個節點都確認一遍，而現在我只需要一個節點，在保證數據完整性的前提下，再加上最近凈流入100塊的證明，然后進行確認完成后，即可證明賬戶有100元，區別就是前者需要每一個節點的計算，后者只需要單一節點計算和zk證明。在這個例子中，確認的是“如何在鏈下證明賬戶有充足余額”，證明需要的約束是“當最近歷史時間軸內賬戶凈流入大于100，然后將節點計算結果與ZKP比對，從而決定狀態是否正確。

數據：ENS交易量在過去一周增長了61.84%:金色財經消息，Tokenview數據顯示，ENS交易量在過去一周增長了61.84%，昨日ENS交易量為29,367，活躍地址數為5,102，新地址數為1,439。[2022/8/22 12:40:12]

ZK語言的公約數

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

先不論Devs是否能夠合理設立約束的能力問題，如何防范ZKP證明節點的作惡意愿問題，無疑是更為重要的。

舉例來看，一些ZKdex更像是在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電路不友好。

BTC富豪排行榜上排名103-114的地址昨日增持超百枚BTC:5月15日消息，根據加密貨幣分析師Benjamin Cowen的說法，BTC富豪排行榜上排名103-114的地址，不約而同地在5月14日購入了比特幣（約109枚），由于地址余額數量相同且行為一致，合理判斷這些地址背后都是同一巨鯨。這位巨鯨抄底效率更高，地址創建到現在一共只出手三次，第一次出手是2018年12月，第二次出手是2021年7月，第三次就是昨天。[2022/5/15 3:17:12]

2.站在開發者角度：

能否不需要重新學習語言，保留EVM的API特性。在這種情況下，整個生態就可能失去對一些ZK算法的支持。

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

1.寄存器的兼容。MachineType.傳統EVM是一個Stack-based的Statemachine，因此大量的計算式串聯的，不可并行的，這確保了整個計算機的原子性。這一架構對于ZK是非常不利的，如果要發揮ZK算法的全部效率，則需要做一個Register-Based，也就是以CPU-寄存器為核心架構來設計VM。

2.語言上的兼容。FunctionCalls.VM系統將底層特性封裝成API，如何讓API支持動態調用，支持像Python一樣的高級語言。

3.計算機底層的兼容。NativeField.不同的CPU有不同的位數，在不同算法上的表現不同。需要為ZK專用計算機做謀劃。

4.傳統公鏈結構的兼容:Sequencer/Roller/Miner.

三、ZKVM的架構

主流技術方案

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

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

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

Starkware

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

Zksync

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

HermezbyPolygon

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生態主要的風險。典型問題包括：約束系統不充分。當證明一些復雜交叉的命題時，約束面臨不夠充分的問題；私有數據泄露。私有數據當做公開數據處理；針對鏈下數據的攻擊，合約層的“metadata-attack”；ZK證明節點的作惡等等。隨著不同Circuit的不斷成熟，Sequencer/Roller/Miner也會迎來提效和分工，我們期待ZK證明的硬件加速機會。

Tags：CODEODECODAPPOVCodecode幣騙局DECODE價格Wrapped Basic CryptoKitties

火幣APP