PRO:零知識證明與分布式計算的深度結合：將如何解鎖下一個萬億賽道？_ISC

作者：火必研究院&謝錦斌

編輯:?AndyHoo

1.分布式計算發展歷史和市場前景

1.1發展歷史

最開始的計算機每臺只能執行一個計算任務，隨著多核心多線程的CPU出現，單個計算機可以執行多個計算任務。

隨著大型網站的業務增加，單服務器模式很難進行擴容，又增加硬件成本。面向服務的架構出現，由多臺服務器組成。由服務注冊者、服務提供者和服務消費者，三者組成。

但是隨著業務增加和服務器增加，SOA模式下，點對點服務可維護性和可拓展性難度增加。類似微機原理中，總線模式出現，來協調各個服務單元。服務總線通過類似集線器的架構將所有系統連接在一起。這個組件被稱為ESB。作為一個中間角色，來翻譯協調各個不同格式或者標準的服務協議。

隨后基于應用程序編程接口的REST模型通信，以其簡潔、可組合性更高的特性，脫穎而出。各個服務以REST形式對外輸出接口。當客戶端通過RESTfulAPI提出請求時，它會將資源狀態表述傳遞給請求者或終端。該信息或表述通過HTTP以下列某種格式傳輸：JSON、HTML、XLT、Python、PHP或純文本。JSON是最常用的編程語言，盡管它的名字英文原意為“JavaScript對象表示法”，但它適用于各種語言，并且人和機器都能讀。

虛擬機、容器技術，以及谷歌的三篇論文：

2003年，GFS:TheGoogleFileSystem

2004年，MapReduce:SimplifiedDataProcessingonLargeClusters

2006年，Bigtable:ADistributedStorageSystemforStructuredData

分別是分布式文件系統、分布式計算、分布式數據庫，拉開了分布式系統的帷幕。Hadoop對谷歌論文的復現，更快更容易上手的Spark，滿足實時計算的Flink。

但是以往都是分布式系統，并不是完全意義上的Peertopeer系統。在Web3領域，完全顛覆以往的軟件架構。分布式系統的一致性，防欺詐攻擊，防粉塵交易攻擊等等一系列問題，都給去中心化計算框架帶來挑戰。

將以太坊為代表的智能合約公鏈，可以抽象理解為去中心化的計算框架，只不過EVM是有限指令集的虛擬機，無法做Web2需要的通用計算。而且鏈上資源也是極其昂貴。盡管如此，以太坊也是突破了點對點計算框架的瓶頸，點對點通信、計算結果全網一致性和數據一致性等等問題。

1.2市場前景

讀者在上面了解了分布式計算的歷史，但還是會存在很多困惑，我來替讀者列出大家可能存在的潛在疑問，如下：

從業務需求出發，為什么去中心化計算網絡很重要？整體市場規模有多大？現在處于什么階段，未來還有多少空間？哪些機會值得關注？怎么去賺錢？

1.2.1為什么去中心化計算很重要？

在以太坊最初的愿景中，是要成為世界的計算機。在2017年，ICO大爆發之后，大家發現還是主要以資產發行為主。但是到了2020年，Defisummer出現，大量Dapp開始涌現。鏈上數據爆炸，面對越來越多復雜的業務場景，EVM越來越顯得無力。需要鏈下拓展的形式，來實現EVM無法實現的功能。諸如像預言機等等角色，都是某種程度上的去中心化計算。

我們再以拓展思路去思考，現在Dapp高速增長，數據量也在爆炸式增長，這些數據的價值都需要更加復雜的算法來去計算，挖掘其商業價值。數據的價值由計算來體現和產生。這些都是大部分智能合約平臺無法去實現的。

現在Dapp開發已經過去當初只需要完成0到1的過程，現在需要更加強大的底層設施，來支撐它完成更加復雜的業務場景。整個Web3已經從開發玩具應用階段過去，未來需要面對更加復雜的邏輯和業務場景。

1.2.2整體市場規模有多大？

如何估算市場規模呢？通過Web2領域的分布式計算業務規模來估算？乘上web3市場的滲透率？把目前市面上相應融資項目的估值相加嗎？

螞蟻鏈隱私協作平臺AntChain FAIR引入基于零知識證明的可驗證計算技術:7月8日消息，在2023世界人工智能大會全球區塊鏈產業高峰論壇上，螞蟻鏈宣布隱私協作平臺AntChain FAIR進行全新架構升級，引入零知識證明（ZKP）為核心的可驗證計算技術，從可信數據流轉拓展到計算過程、數據屬性以及身份的可驗證。此外螞蟻鏈FAIR在可信計算架構中加入新型零知識證明虛擬機zkWASM，實現指令級別的可證明特性，可以依托 WASM 多語言生態將多種前端語言編寫的算法程序進行證明轉化，而無需關心底層復雜的算法細節，提升開發應用的友好性。

FAIR 是螞蟻鏈面向數據流轉推出的隱私協作平臺，綜合了區塊鏈和隱私計算的優勢，協作流程由智能合約驅動，數據流轉由隱私計算引擎來解決，并通過區塊鏈技術確權，登記和交易共識，可以解決數據流通過程中，數據共享與隱私保護之間的天然矛盾。目前 FAIR 已經在杭數交、貴數所等多家數據交易所得到應用。[2023/7/8 22:25:31]

我們不能將Web2的分布式計算市場規模照搬到Web3，理由是：1，Web2領域的分布式計算滿足了大部分需求，Web3領域的去中心化計算是差異化滿足市場需求。如果照搬，是有悖于市場客觀背景環境。2，Web3領域的去中心化計算，未來成長出的市場業務范圍是全球化的。所以我們需要更加嚴謹得去估算市場規模。

對于Web3領域潛在賽道整體規模預算通過以下幾點出發來進行計算：

1.對行業內，其他可被納入賽道范圍內的項目估值，做為基準市值。依據coinmarketcap網站上數據顯示，在市面上已經流通的分布式計算板塊的項目市值在67億美元。

2.營收模型來自于，代幣經濟模型的設計，例如目前比較普遍流行的代幣營收模型是，代幣作為交易時候支付手續費的手段。所以可以通過手續費收入，間接反映生態的繁榮程度，交易活躍程度。最終作為估值評斷的標準。當然，token還有其他成熟的模型，例如用于抵押挖礦，或者交易的交易對，或者是算法穩定幣的錨定資產。所以Web3項目的估值模型，區別于傳統股票市場，更像是國家貨幣。代幣可以被采用的場景會有多樣性。所以對于具體項目具體分析。我們可以嘗試探索Web3去中心化計算場景中，代幣模型應該如何進行設計。首先我們假定自己去設計一個去中心化計算框架，我們會遇到什么樣的挑戰？a).因為完全去中心化的網絡，在這樣不可信的環境中完成計算任務的執行，需要激勵資源提供者保障在線率，還要保障服務質量。在博弈機制上，需要保證激勵機制合理，還要如何防止攻擊者發起欺詐攻擊、女巫攻擊等等攻擊手段。所以需要代幣作為質押手段參與POS共識網絡，先保障所有節點的共識一致性。對于資源貢獻者，需要其貢獻的工作量來實施一定的激勵機制，代幣激勵對業務增加和網絡效率提升，必須要有正向循環增長的。b).相較于其他layer1，網絡本身也會產生大量交易，面對大量粉塵交易，每筆交易支付手續費，是經過市場驗證的代幣模型。c).如果代幣只是實際用途化，市值是很難再進一步擴大。如果作為資產組合的錨定資產，進行幾層資產嵌套組合，極大擴張金融化的效果。整體估值=質押率*Gas消耗率*(流通量的倒數）*單個價格

1.2.3現在處于什么階段，未來還有多少空間？

2017年到現在，很多團隊都在嘗試去中心化計算方向上發展，但是都嘗試失敗，后面會具體解釋失敗的原因。探索路徑由最初類似外星人探索計劃的項目，后來發展到模仿傳統云計算的模式，再到Web3原生模式的探索。

當前整個賽道的現狀，處于在學術層面已經驗證0到1的突破，一些大型項目在工程實踐上，有了較大的進展。例如當前的zkRollup和zkEVM實現上，都是剛剛發布產品的階段。

未來還有很大空間，理由如下：1，還需提升驗證計算的高效性。2，還需要補充豐富更多指令集。3，真正不同業務場景的優化。4，以往用智能合約無法實現的業務場景，可以通過去中心化計算實現。

我們通過一個具體案例來解釋，完全去中心化的游戲。目前大部分Gamefi需要一個中心化服務做為后端，其后端作用在于管理玩家的狀態數據和一些業務邏輯，其應用前端在于用戶交互邏輯和事件觸發后傳遞到后端。當前市面上還沒有完整的解決方案，可以支撐Gamefi的業務場景。但是可被驗證的去中心化計算協議出現，后端替換為zkvm。可以真正實現去中心化的游戲。前端將用戶事件邏輯，發送到zkvm執行相關業務邏輯，被驗證后，在去中心化數據庫記錄狀態。

歐盟或將在數字身份框架中包含零知識證明:金色財經報道，根據一份新聞稿，歐盟新的eID將允許公民通過歐洲數字身份錢包在線識別和驗證自己，而無需求助于商業提供商。此舉解決了當前實踐中產生的對信任、安全和隱私的擔憂。

Circle 歐盟政府事務高級主管Jonas Fredriksen強調該提案將如何促進數字經濟中的新商業模式和機遇。公司可以開發依賴于零知識證明和eID解決方案的創新產品和服務。[2023/2/16 12:11:30]

當然這只是提出的一個應用場景，而Web2有很多業務場景需要計算的能力。

1.2.4哪些機會值得關注？怎么去賺錢？

應用場景\虛擬機類型

通用型高性能虛擬機

AI虛擬機

DeFi

金融數據處理/高并發金融交易并行執行確認/高性能撮合。。。

人臉識別/信用評估/為更多借貸業務服務。。。

NFT

省Gas聚合交易/批量注冊任務

AIGC/價值估算。。

社交應用

遷移Web2的社交應用/高并發高并行的業務場景/基本的社交業務邏輯，之前智能合約無法實現的

推薦算法。。。

gamefi

去中心化游戲/多人在線網絡通信處理...

防作弊

創作者經濟

對于不同文件類型的內容創作平臺，需要支撐其業務邏輯執行的虛擬機

AIGC

2.去中心化的分布式計算嘗試

2.1云服務模式

目前以太坊有如下問題:

1.整體吞吐量低。消耗了大量的算力，但是吞吐量只相當于一臺智能手機。

2.驗證積極性低。這個問題被稱為Verifier'sDilemma。獲得打包權的節點得到獎勵，其他節點都需要驗證，但是得不到獎勵，驗證積極性低。久而久之，可能導致計算得不到驗證，給鏈上數據安全性帶來風險。

3.計算量受限(gasLimit)，計算成本較高。

有團隊嘗試采用，被Web2廣泛采用的云計算模式。用戶支付一定費用，按照計算資源使用時間來計算費用。采取這樣模式，其根本原因是因為其無法驗證計算任務是否被正確執行，只能通過可檢測的時間參數或者其他可控的參數。

最終這個模式沒有廣泛應用，沒有考慮人性的因素。大量資源被用于挖礦，以謀取最大利益。導致真正可被利用的資源較少。這是博弈系統內，各個角色謀求利益最大化的結果。

最終呈現的結果，和最開始的初衷完全背離。

2.2挑戰者模式

而TrueBit則利用博弈體系，達到全局最優解，來保障下發的計算任務是被正確執行。

https://www.aicoin.com/article/256862.html

我們快速這種計算框架的核心要點：

1.角色：問題解決者、挑戰者和法官

2.問題解決者需要質押資金，才可以參與領取計算任務

3.挑戰者作為賞金獵人，需要重復驗證問題解決者的計算結果，和自己本地的是否一致

4.挑戰者會去抽取與兩者計算狀態一致的最近時間的計算任務，如果出現分歧點，提交分歧點的默克樹hash值

5.最后法官評判是否挑戰成功

但是這個模式存在以下幾點缺陷：

1.挑戰者可以晚時間提交，只需要完成提交任務就行。這樣導致結果是，缺少及時性。

2.3利用零知識證明驗證計算

所以如何實現，既保證計算過程可被驗證，又能保障驗證的及時性。

例如zkEVM的實現，每個區塊時間，需要提交可被驗證的zkProof。這個zkProof包含邏輯計算業務代碼生成的字節碼，再由字節碼執行生成電路代碼。這樣實現了計算業務邏輯是被正確執行，而且通過較短和固定時間來保障驗證的及時性。

以太坊基金會、AMD、Polkadot 發起 700 萬美元競賽以促進零知識擴展:金色財經報道，ZPrize于4月19日宣布，多個加密貨幣項目聯合起來，為使用零知識（ZK）證明的創新團隊提供700萬美元的獎金。該競賽由21個Web3組織支持，包括Polygon、Polkadot、Mina和Ethereum基金會。AMD-Xilinx還將為參賽團隊提供高功率的計算設備。ZPrize在一份聲明中說，參賽團隊將嘗試設計 \"新的算法和技術，以實現最好的零知識系統無法比擬的性能指標。\"獲獎者必須將其提交的材料開源，以便其他開發者能夠將任何突破性的東西整合到他們的工作中。[2022/4/20 14:34:54]

雖然zkEVM只是針對智能合約執行的場景，本質還是在計算業務框架下面。如果我們將EVM邏輯順延到其他通用類型的虛擬機，例如WASM虛擬機，或者更加通用的LLVM高性能虛擬機。當然在具體落實到工程實踐上會有諸多挑戰，卻給我們更多的探索空間。

在假定條件下，有足夠高性能的零知識證明加速硬件和足夠被優化的零知識證明算法，通用計算場景可以得到充分發展。大量Web2場景下的計算業務，都可以被零知識證明通用虛擬機進行復現。就如前文所提到可賺錢的業務方向。

3.零知識證明和分布式計算的結合

3.1學術層面

我們回看一下零知識證明算法歷史發展演進的路線

1.GMR85是最早起源的算法，來源于Goldwasser、Micali和Rackoff合作發表的論文：TheKnowledgeComplexityofInteractiveProofSystems，該論文提出于1985年，發表于1989年。這篇論文主要闡釋的是在一個交互系統中，經過K輪交互，需要多少知識被交換，從而證明一個證言是正確的。

2.姚氏混淆電路。一種著名的基于不經意傳輸的兩方安全計算協議，它能夠對任何函數進行求值。混淆電路的中心思想是將計算電路分解為產生階段和求值階段。每一方都負責一個階段，而在每一階段中電路都被加密處理，所以任何一方都不能從其他方獲取信息，但他們仍然可以根據電路獲取結果。混淆電路由一個不經意傳輸協議和一個分組密碼組成。電路的復雜度至少是隨著輸入內容的增大而線性增長的。在混淆電路發表后，Goldreich-Micali-Wigderson將混淆電路擴展使用于多方，用以抵抗惡意的敵手。

3.sigma協議又稱為誠實驗證者的零知識證明。即假設驗證者是誠實的。這個例子類似Schnorr身份認證協議，只是后者通常采用非交互的方式。

4.2013年的Pinocchio(PGHR13)：Pinocchio:NearlyPracticalVerifiableComputation，將證明和驗證時間壓縮到適用范圍，也是Zcash使用的基礎協議。

5.2016年的Groth16：OntheSizeofPairing-basedNon-interactiveArguments，精簡了證明的大小，并提升了驗證效率，是目前應用最多的ZK基礎算法。

6.2017年的Bulletproofs(BBBPWM17)Bulletproofs:ShortProofsforConfidentialTransactionsandMore，提出了Bulletproof算法，非常短的非交互式零知識證明，不需要可信的設置，6個月以后應用于Monero，是非常快的理論到應用的結合。

7.2018年的zk-STARKs(BBHR18)Scalable,transparent,andpost-quantumsecurecomputationalintegrity，提出了不需要可信設置的ZK-STARK算法協議，這也是目前ZK發展另一個讓人矚目的方向，也以此為基礎誕生了StarkWare這個最重量級的ZK項目。

8.Bulletproofs的特點為：

1）無需trustedsetup的shortNIZK

2）基于Pedersencommitment構建

3）支持proofaggregation

Filecoin：Filecoin網絡已成為最大的零知識證明網絡:Filecoin發表博客稱，目前Filecoin已成為最大的零知識證明（zk-SNARK）網絡。據官方數據顯示，目前Filecoin網絡每日會運行6至7百萬次零知識證明，每一個零知識證明中包含了超過1億個約束電路證明。目前Filecoin網絡的可信配置已支持最高128M大小的電路證明，單個證明最大已超過100M，而Zcash最高僅支持2M。此外，目前Filecoin實現了通過SnarkPack將10個零知識證明捆綁至單次證明中，并正在研究零知識證明聚合以實現將數千個零知識證明聚合至單次證明中。硬件支持方面，Filecoin將零知識證明中高度可并行化的部分交由GPU完成，將CPU和內存釋放出來進行較為復雜的計算，進一步提高了零知識證明的效率。[2021/7/14 0:51:01]

4）Provertime為：O(N?log?(N))O(N\cdot\log(N))O(N?log(N))，約30秒

5）Verifiertime為：O(N)O(N)O(N)，約1秒

6）proofsize為：O(log?(N))O(\log(N))O(log(N))，約1.3KB

7）基于的安全假設為：discretelog

Bulletproofs適用的場景為：

1）rangeproofs

2）innerproductproofs

3）MPC協議中的intermediarychecks

4）aggregatedanddistributed(withmanyprivateinputs)proofs

9.Halo2主要特點為：

1）無需trustedsetup，將accumulationscheme與PLONKisharithmetization高效結合。

2）基于IPAcommitmentscheme。

3）繁榮的開發者生態。

4）Provertime為：O(N?log?N)O(N*\logN)O(N?logN)。

5）Verifiertime為：O(1)>O(1)>O(1)>Groth16。

6）Proofsize為：O(log?N)O(\logN)O(logN)。

7）基于的安全假設為：discretelog。

Halo2適于的場景有：

1）任意可驗證計算

2）遞歸proofcomposition

3）基于lookup-basedSinsemillafunction的circuit-optimizedhashing

Halo2不適于的場景為：

1）除非替換使用KZG版本的Halo2，否則在以太坊上驗證開銷大。

10.Plonky2主要特點為：

1）無需trustedsetup，將FRI與PLONK結合。

2）針對具有SIMD的處理器進行了優化，并采用了64byteGoldilocksfields。

3）Provertime為：O(log?N)O(\logN)O(logN)。

4）Verifiertime為：O(log?N)O(\logN)O(logN)。

5）Proofsize為：O(N?log?N)O(N*\logN)O(N?logN)。

6）基于的安全假設為：collision-resistanthashfunction。

Plonky2適于的場景有：

1）任意可驗證計算。

2）遞歸proofcomposition。

3）使用自定義gate進行電路優化。

Plonky2不適于的場景為：

1）受限于其non-nativearithmetic，不適于包含橢圓曲線運算的statements。

聲音 | V神評價MimbleWimble：只有零知識證明 ZK-SNARKs 等全局匿名集，才能真正保證隱私安全:針對 Dragonfly Capital 的分析師 Ivan Bogatyy 發布的關于闡述 MimbleWimble 協議有重大缺陷、Grin 網絡 96% 的交易可被破譯的文章。

以太坊創始人Vitalik在推特回應稱：如果隱私模型設置了一個中等的匿名集，那么它實際上設置了一個小范圍的匿名集。如果隱私模型的匿名集較小，則其匿名集為 1。只有全局匿名集（例如，使用 ZK-SNARKs 技術進行的加密）才真正具有安全性。[2019/11/19]

目前Halo2成為zkvm采用的主流算法，支持遞歸證明，支持驗證任意類型的計算。為零知識證明類型虛擬機做通用計算場景，奠定了基礎。

3.2工程實踐層面

既然零知識證明在學術層面突飛猛進，具體落地到實際開發時候，目前進展是怎樣的呢？

我們從多個層面去觀察：

編程語言：目前有專門的編程語言，幫助開發者不需要深入了解電路代碼如何設計，這樣就可以降低開發門檻。當然也有支持將Solidity轉譯成電路代碼。開發者友好程度越來越高。

虛擬機：目前有多種實現的zkvm，第一種是自行設計的編程語言，通過自己的編譯器編譯成電路代碼，最后生成zkproof。第二種是支持solidity編程語言，通過LLVM編譯成目標字節碼，最后轉譯成電路代碼和zkproof。第三種是真正意義的EVM等效兼容，最終將字節碼的執行操作，轉譯成電路代碼和zkproof。目前是zkvm的終局之戰嗎？并沒有，不管是拓展到智能合約編程之外的通用計算場景，還是不同方案的zkvm針對自身底層指令集的補齊和優化，都還是1到N的階段。任重而道遠，大量工程上的工作需要去優化和實現。各家在學術層到工程實現上實現了落地，誰能最終成為王者，殺出一條血路。不僅需要在性能提升有大幅進展，還要能吸引大量開發者進入生態。時間點是十分重要的前提要素，先行推向市場，吸引資金沉淀，生態內自發涌現的應用，都是成功的要素。

周邊配套工具設施：編輯器插件支持、單元測試插件、Debug調試工具等等，幫助開發者更加高效的開發零知識證明應用。

零知識證明加速的基礎設施：因為整個零知識證明算法中，FFT和MSM占用了大量運算時間，可以GPU/FPGA等并行計算設備來并行執行，達到壓縮時間開銷的效果。

不同編程語言實現：例如采用更加高效或者性能表現更好的編程語言：Rust。

明星項目涌現：zkSync、Starkware等等優質項目，相繼宣布其正式產品發布的時間。說明了，零知識證明和去中心化計算結合不再是停留在理論層面，在工程實踐上逐漸成熟。

4.遇到的瓶頸以及如何解決

4.1zkProof生成效率低

前面我們講到，關于這塊市場容量、目前行業發展情況、在技術上的實際進展，但是沒有存在一點挑戰嗎？

我們對整個zkProof生成的流程進行拆解：

在邏輯電路編譯數值化r1cs的階段，里面80%的運算量在NTT和MSM等計算業務上。另外對邏輯電路不同層級進行hash算法，隨著層級越多，Hash算法時間開銷線性增加。當然現在行業內提出時間開銷減少200倍的GKR算法。

但是NTT和MSM計算時間開銷，還是居高不下。如果希望給用戶減少等待時間，提升使用體驗效果，必須要在數學實現上、軟件架構優化、GPU/FPGA/ASIC等等層面進行加速。

下圖為各個zkSnark家族算法的證明生成時間和驗證時間的測試：

BenchmarkResults

Sudoku:compile

Miden

Plonk:3by3

Risc

Halo:3by3

1.52ms(?1.00x)

99.92ms(?65.80xslower)

1.86ms(?1.22xslower)

329.15ms(?216.76xslower)

Sudoku:prove

Miden

Plonk:3by3

Risc

Halo:3by3

477.41ms(?1.00x)

100.52ms(???4.75xfaster)

1.67s(?3.49xslower)

116.74ms(???4.09xfaster)

Sudoku:verify

Miden

Plonk:3by3

Risc

Halo:3by3

2.41ms(?1.00x)

7.28ms(?3.02xslower)

2.79ms(?1.15xslower)

4.39ms(?1.82xslower)

Sudoku:

Miden

Plonk:3by3

Risc

Halo:3by3

475.69ms(?1.00x)

205.22ms(???2.32xfaster)

1.67s(?3.52xslower)

450.98ms(?1.05xfaster)

fibonacci:compile

Miden:iter-93

Miden:fixed-92

Miden:fixed-50

Risc0:iter-93

Risc0:iter-50

Risc0:fixed-50

Risc0:fixed-92

64.89us(?1.00x)

55.92us(?1.16xfaster)

45.01us(?1.44xfaster)

387.69us(?5.97xslower)

388.34us(?5.98xslower)

391.42us(?6.03xslower)

390.26us(?6.01xslower)

fibonacci:prove

Miden:iter-93

Miden:fixed-92

Miden:fixed-50

Risc0:iter-93

Risc0:iter-50

Risc0:fixed-50

Risc0:fixed-92

472.51ms(?1.00x)

231.76ms(???2.04xfaster)

233.25ms(???2.03xfaster)

417.66ms(?1.13xfaster)

413.46ms(?1.14xfaster)

410.38ms(?1.15xfaster)

412.02ms(?1.15xfaster)

fibonacci:verify

Miden:iter-93

Miden:fixed-92

Miden:fixed-50

Risc0:iter-93

Risc0:iter-50

Risc0:fixed-50

Risc0:fixed-92

2.41ms(?1.00x)

2.36ms(?1.02xfaster)

2.36ms(?1.02xfaster)

2.55ms(?1.06xslower)

2.55ms(?1.06xslower)

2.55ms(?1.06xslower)

2.55ms(?1.06xslower)

fibonacci:

Miden:iter-93

Miden:fixed-92

Miden:fixed-50

Risc0:iter-93

Risc0:iter-50

Risc0:fixed-50

Risc0:fixed-92

475.43ms(?1.00x)

234.39ms(???2.03xfaster)

235.84ms(???2.02xfaster)

421.28ms(?1.13xfaster)

417.20ms(?1.14xfaster)

413.70ms(?1.15xfaster)

415.58ms(?1.14xfaster)

fibonaccilarge:compile

Miden:iter-1000

Risc0:iter-1000

64.91us(?1.00x)

387.43us(?5.97xslower)

fibonaccilarge:prove

Miden:iter-1000

Risc0:iter-1000

4.07s(?1.00x)

3.39s(?1.20xfaster)

fibonaccilarge:verify

Miden:iter-1000

Risc0:iter-1000

2.66ms(?1.00x)

2.96ms(?1.11xslower)

fibonaccilarge:

Miden:iter-1000

Risc0:iter-1000

4.07s(?1.00x)

3.40s(?1.20xfaster)

Blake:compile

Risc0:Library-Thequickbrownfoxjumpsoverthelazydog

466.84us(?1.00x)

Blake:prove

Risc0:Library-Thequickbrownfoxjumpsoverthelazydog

3.40s(?1.00x)

Blake:verify

Risc0:Library-Thequickbrownfoxjumpsoverthelazydog

4.24ms(?1.00x)

Blake:

Risc0:Library-Thequickbrownfoxjumpsoverthelazydog

3.40s(?1.00x)

Blake3:compile

Miden:Library-quickbrownfox

7.38ms(?1.00x)

Blake3:prove

Miden:Library-quickbrownfox

1.99s(?1.00x)

Blake3:verify

Miden:Library-quickbrownfox

3.12ms(?1.00x)

Blake3:

Miden:Library-quickbrownfox

2.01s(?1.00x)

既然我們可以看到缺陷和挑戰，同時也意味著其中深藏著機會：

1.設計針對特定zkSnark算法加速或者通用zkSnark算法加速的芯片。相比其他類型的加密算法，zkSnark產生較多臨時文件，對于設備的內存和顯存存在要求。芯片創業項目，同時也面臨大量資金投入，還不一定能保障最后可以流片成功。但是一旦成功，其技術壁壘和IP保護都將是護城河。芯片項目創業，必須要足夠議價能力的渠道，拿到最低成本。以及在整體品控上做到保障。

2.顯卡加速的Saas服務，利用顯卡做加速，是支出代價小于ASIC設計，而且開發周期也較短。但是軟件創新上，在長周期上最終會被硬件加速所淘汰。

4.2硬件資源占用大

目前和一些zkRollup項目接觸，最終發現還是大內存和大顯存顯卡比較適合他們用于軟件加速。例如在Filecoin挖礦中，大量閑置的數據封裝機成為了現在熱門zkRollup項目的目標設備。在Filecoin挖礦中，在C2階段，需要將生成的電路代碼文件，生成并緩存在內存中。如果業務代碼邏輯十分復雜，其對應生成的電路代碼規模也會非常大，最終呈現形式就是體積大的臨時文件，特別涉及對電路代碼進行Hash運算，需要AMDCPU指令來加速。因為直接CPU和內存之間高速交換，效率非常高。這里面還需要涉及到NVME的固態硬盤，都會是對zkSnark運算起到加速作用。以上我們對可能存在加速實現的可能性進行探討，發現對資源要求還是非常高的。

在未來，如果想大規模普及zkSnark應用，通過不同層面優化，勢在必行。

4.3Gas消耗成本

我們觀察到所有zkRollupLayer2需要將zkProof傳遞到layer1進行驗證和存儲，因為ETH鏈上資源十分昂貴，如果大規模普及后，需要為ETH支付大量Gas。最終由用戶承擔這個成本，和技術發展的初衷。

所以很多zkp項目提出，數據有效層、利用遞歸證明壓縮提交的zkProof，這些都是為了降低Gascost。

4.4虛擬機的指令缺失

當前大部分zkvm面向智能合約編程的平臺，如果要更加通用的計算場景，對zkvm底層指令集有大量的補齊工作。例如zkvm虛擬機底層支持libc指令，支持矩陣運算的指令，等等其他更加復雜的計算指令。

5.結語

因為智能合約平臺更多面向資產進行編程，如果我們希望更多真實業務場景可以接入到Web3，零知識證明和去中心化計算的結合帶來了契機。我們相信零知識證明將會成為主流賽道，不再是細分領域的技術。

Tags：TERPROISCSTEMetaXHunterProsperBISCSTEPI價格

Uniswap