作者：Michael Zhu（a16z Crypto研究工程師），Sam Ragsdale（a16z Crypto投資工程師）；翻譯：金色財經xiaozou
2024年4月9日，a16z 加密研究和工程團隊發布了Jolt的初步實現，這是一種新的SNARK 設計方法，速度比現有技術快2 倍，並且還會有更多改進。
可驗證計算（俗稱ZK）是一項非常強大的技術，既適用於區塊鏈也適用於非區塊鏈。它使一台計算機（verifier驗證者）能夠將計算委託給另一台更強大的計算機（prover證明者），並由其有效地驗證計算是否正確執行。
在加密產業，可驗證計算的應用（尤其是SNARKs）包括：
Layer 2（L2）區塊鏈使用SNARKs來保證其狀態轉換的完整性。
-
跨鏈橋使用SNARKs來證明一條鏈到另一條鏈上的存款/提款轉移。
-
一個「ZK協處理器」（由Axiom定義）使用SNARKs來證明一些鏈上資料的鏈下計算，如若這些鏈上資料在智慧合約中進行原生運算成本則太過高昂。
還有許多幾乎未被探索的有趣的非區塊鏈用例。例如，雲端服務提供者可以向其客戶端證明他們正確地運行了委託給其伺服器的某些運算。像npm或crates.io這樣的軟體註冊表可以證明二進位檔案是從特定的原始碼編譯的，從而降低了軟體供應鏈攻擊的風險。或者一個人可以證明他們的《超級瑪利歐兄弟》的工具輔助競速（TAS）打破了世界紀錄（RISC Zero也描寫過這個想法）。
這些應用程式中有很多涉及的程式過於複雜，無法轉換成電路DSL（特定域語言）——想像一下，例如，使用Circom語言重寫整個編譯器或NES模擬器。但是，如果程式編譯成由zkVM支援的指令集，則不需要手寫電路或DSL轉換：程式設計師只需要用他們選擇的高階程式語言編寫程序，由zkVM處理其餘的工作。
那麼，剩下的挑戰就是zkVM prover的效能：它需要夠快才有用。這對於區塊鏈用例尤其重要，因為prover時間會影響延遲，進而影響用戶體驗。
可驗證計算長期以來一直被吹捧為有望是區塊鏈擴容的終極解決方案，但該技術在採用方面面臨三大障礙：
-
效能：與原生執行相比，證明程式的執行會引入高幾個數量級的開銷。
-
複雜性：SNARKs的複雜性引發了人們對其實現安全的擔憂，因為將肩負著數十億美元鏈上資產的安全保障。
-
可用性：像Circom這樣的特定領域語言（DSLs）所要求的專業知識是大多數軟體開發人員無法獲得的。
零知識虛擬機（zkVMs）的發展克服了第三個障礙（可用性），因為zkVMs允許開發人員使用Rust或Go等高階程式語言編寫程序，而不需要任何底層SNARK的知識來證明其執行。但是zkVMs可用性的提高也導致了高昂的效能開銷（8到9個數量級）和複雜的部署。
去年，一篇Jolt文章為zkVMs引入了一個新範式，承諾克服效能開銷和部署複雜性這兩大挑戰。與基於STARK的既有想法相比，Jolt的理論背景有所不同。透過利用Lasso查詢參數和其他基於sumcheck的技術，Jolt可以比以往更快地證明程序，並且比以往更容易部署新的VM指令。
如今，我們很高興為RV32I指令集發布一個Jolt開源部署，實現了那篇Jolt文章裡所做的承諾。
-
快速：我們的部署比RISC Zero快5倍以上，比剛發布的SP1在初步基準測試中快2倍。
-
（相對）簡潔：整個程式碼庫不到25,000行Rust（不到其他zkVMs的一半），單一CPU指令只需50行程式碼即可實現。
下面，我們一起來看效能基準，可以看出Jolt是最先進的新興zkVM。我們也為有興趣開發使用Jolt的應用程式的開發者提供了一些指導，同時也為有興趣為Jolt做出貢獻的開發者提供了路線圖預覽——我們預計在未來幾個月裡，Jolt會變得更快、更容易使用。
a16z加密工程團隊是建立在對開源價值的堅定信念之上的。將Jolt打造為開源的公共產品將加速zkVM研究、更廣泛的SNARK研究以及整個web3產業的發展。在封閉原始碼的孤島中建立加密技術（程式碼無法由公眾審查），通常會給本不可信的系統帶去信任。
1、性能
一直以來，與原生執行相比，zkVMs會帶來大約8個數量級的開銷，這使得許多可驗證計算的應用程式無法實現。目前版本的Jolt將這一開銷降低到了6個數量級以下。
雖然我們已經具備了最先進的性能，但Jolt的底層技術（基於sumcheck協定）並沒有像更流行的技術（基於FRI）那樣受到工程師的關注。這表明Jolt還有更多的發展空間——我們已經在路線圖上設定了一些優化，我們預計還會有未發現的機會。
我們的a16z/zkvm基準測試在各種不同Rust程式上對Jolt、SP1和RISC Zero進行了基準點測定。結果是在許多同類RV32程序中，相對性能是相似的。下圖將參考一個執行Sha2哈希鏈的程式。
這些基準測試的結果如下所示。基準測試是在AWS r7g. 16xlarge ARM機上運行的，具有64 CPU核心和512 GiB DDR5 RAM。所有基準測試都僅針對CPU。
使用continuations的連續系統面臨prover時間和證明大小之間的利弊權衡——當證明被分割成更多“shard分片”（或“段”）時，prover變得更快（由於分片之間的並行化），但在遞歸之前具有證明體積更大。證明大小基準測試如下所示，其中SP1的結果由分片計數參數化：SP1（shard_count）。 RISC Zero有一個固定大小的分片，因此它的分片計數隨著程式週期計數隱式增長。 RISC Zero支援遞歸（SP1和Jolt尚未支援），但以下的基準測試是在沒有遞歸的情況下進行的效能檢測。我們也不使用“預編譯”，因此基準測試反映了核心zkVM證明系統的效能。
2、如何在Jolt上開發建設
為了讓Jolt盡可能易用，Jolt SDK（由a16z crypto工程合作夥伴Noah Citron建構）提供了圍繞Jolt核心功能的簡式wrappers。你要做的就是：為要證明的函式加入jolt_sdk::provable屬性。
然後，你將能夠使用build_*函數來建立一個prover和verifier。
請在程式碼庫中查看完整的Fibonacci範例（及其他）。
為了更深入了解Jolt架構，Jolt Book（WIP）是一個關於沒有在Jolt文章中記錄的設計選擇和程式碼庫的即時更新文件。在接下來的幾週內，我們將針對有興趣在Jolt上進行開發建置或想要了解Jolt內部機制的開發者發布更多內容。
3.接下來是什麼
雖然Jolt是zkVM領域的一個重要里程碑，但我們還有很長的路要走。退一步說，我們的性能基準測試表明，Jolt prover（在M3 Max上）證明了一個程式的速度與100kHz處理器一樣快——是阿波羅11號載人飛行登月任務機載運算能力的兩倍多。再做一個謙虛的比較，和TI-84圖形計算器相比慢150倍。
為了達到電腦等級的效能，我們有很多工作要做。我們將繼續改進Jolt的效能和可用性，以便為開發者提供最佳的開發體驗。路線圖上的以下主要任務讓我們感到興奮：
-
Binius：Ben Diamond和Jim Posen最近提出了一個多線性多項式承諾方案，該方案對像Jolt這樣的系統尤其有用，因為承諾值很小。 Binius與Justin Thaler的小域sumcheck演算法結合，將顯著提高Jolt的prover性能（我們預計是5-10倍）。
-
更多指令：Jolt程式碼庫目前部署了RV32I，但Jolt結構非常靈活。我們計劃添加RISC-V “M” extension提供對整數乘法和除法的支持，如Jolt一文所述。此外，Jolt可以輕鬆支援64位元變體RV64IM。
-
Continuations連續系統：目前，由於記憶體限制，Jolt無法證明任意長度的計算。我們將使用continuations將長計算分成較小的計算區塊，每個區塊都可以由Jolt證明。這將減少記憶體使用，並在證明單一計算時支援額外的並行性。
-
證明遞歸：透過將Jolt與另一個證明系統組合在一起，我們進一步減少了證明大小和驗證時間。例如，Jolt驗證器可以使用Circom語言實現，以產生可在鏈上有效驗證的恆定大小的Groth16證明。
