A16z：構建者的關鍵要素：‘Jolt Inside’

前言

今天，LayerZero 發布了他們的新鏈 Zero，該鏈包含多項技術進步——包括一種全新的零知識證明方法，該方法將交易執行與驗證解耦。這一切都得益於“Jolt Inside”。

什麼是 Jolt？Jolt 是一款開源的 RISC-V zkVM（零知識虛擬機，或者更確切地說，是一款“簡潔”虛擬機），它快速、安全且易於使用。它代表了一種基於 a16z crypto 三年研發的全新、最先進的 SNARK 設計方法，我們將其開源，供任何人使用或進一步開發。但 Jolt 的誕生實際上是一個歷經數十年酝酿的故事。

為什麼 zkVM 和 SNARK 設計如此重要？

在深入探討 SNARK 設計的演變之前，我們首先需要詳細了解一下 zkVM 是什麼。

這類虛擬機通常被稱為“zk”虛擬機，但這裡更常用的特性是簡潔性。雖然“零知識”對於隱私保護至關重要，但“簡潔”意味著證明短且易於驗證——這是兩個有用但不同的特性，卻常常被混為一談。（Jolt 已經具備簡潔性，而且很快也將實現零知識。）

但為什麼 zkVM 如此重要？zkVM 以及更廣義上的 SNARK（簡潔非交互式知識論證）是區塊鏈擴展性、隱私性、安全性等多方面的重要組成部分。這類證明、論證和零知識（統稱為可驗證計算技術）在加密行業及其他領域都有著無數的應用。

由於傳統設計架構和其他原因，業界迄今為止在構建 zkVM 方面一直採取較為複雜的方法；下文將对此進行更詳細的闡述。然而，Jolt 從一開始就專注於一種截然不同的 SNARK 設計方法，旨在實現更高的效率、可用性和性能。

簡而言之，zkVM 是一種證明你正確運行了計算機程序的方法。zkVM 相較於其他 SNARK 的優勢在於其對開發者友好。通過利用現有的計算基礎設施（例如開源的 LLVM 編譯器生態系統），開發者無需使用領域特定語言 (DSL)，即可在自己選擇的程式語言中發揮 SNARK 的強大功能。

這與當今許多現代密碼學領域頗為相似——我們擁有用於加密和數字簽名的標準、內建庫——普通開發者每天都在使用這些庫，而無需了解其內部運作機制。Jolt 為開發者提供了同樣的抽象層：只需使用現有程序並對其進行驗證，而無需擔心兩者之間的交互。這是任何新型密碼學普及應用的必要條件。

開發者可以專注於實際操作。借助 Jolt，開發者無需任何 SNARK 方面的專業知識，只需按下一個按鈕，即可使用他們已編寫的計算機代碼生成 Jolt 證明。

然而，即使 Jolt 取得了諸多進步，證明任何中等複雜程度的證明（例如單個標準 CPU 核心執行一秒鐘的操作）仍然需要強大的計算能力。要在合理時間內生成複雜的證明，你需要多個 GPU。LayerZero 將 Jolt 證明器移植到 CUDA，並推出了 Zero：它將 Jolt 底層高度並行化的算法與 GPU 的並行硬體相結合，從而實現了更高階的擴展性。

LayerZero 致力於將 Jolt 推向生產級 GPU 證明，包括與我們合作開發 Jolt 算法的 GPU 友好版本，這對提升 zkVM 和證明的可擴展性至關重要。

開源研發

Jolt 本身是開源的，因此任何人都可以使用或基於其創新技術進行開發。開源是終極倍增器：公開共享成果，讓生態系統中更多的人能夠使用、重用、進行壓力測試/審核/修復、改進，並在此基礎上進行進一步創新。

風險投資公司投資開源項目或許看似不同尋常，但現代研發的結構決定了大部分開發工作要麼發生在公司內部——例如過去的企業實驗室或如今的基金會實驗室——要麼發生在學術界。我們成立 a16z 加密研究機構的目的，就是為了打造一個連接學術理論與產業實踐的產業研究實驗室和工程團隊。作為一家風險投資公司，我們還能資助其他機構無法資助的項目……尤其是在逆向投資的情況下。

支持 SNARK 的逆向設計方法對於 Jolt 而言尤為重要，因為它代表著與以往設計方法截然不同的重大“範式轉變”。這種設計演進歷經多年。

創新的故事往往是關於架構設計轉變的故事

要理解 Jolt 針對 SNARK 設計方法所採取的重大變革，我們必須追溯到兩千多年前：古希臘人開創了形式化數學證明系統的發展，後來中東、亞洲及其他地區的學者也對其進行了拓展。

這些早期的證明——一步一步寫出的邏輯推導——被用形式語言或公式記錄下來，以便任何人能夠驗證。例如，一位數學家可以將證明寫在一本“書”中，然後另一位數學家逐字閱讀這本書來驗證它。這種傳統的靜態書面證明概念，正是著名的“P vs. NP”複雜度類 NP 的體現。

值得注意的是，這種傳統的證明方法是順序的，需要輪流進行：它是靜態的，而非交互式的。

但時間快進到 1985 年*，Shafi Goldwasser、Silvio Micali 和 Charles Rackoff 提出了交互式證明（“IP”）的概念。[*實際上，他們的論文提出時間更早幾年，但論文被多次拒絕後才被接受。]這種交互式證明方法的核心思想是：例如，如果兩位數學家在交流，他們無需等待一方寫下證明，然後再去說服另一方。相反，他們可以實時提問；換句話說，通過互動來探尋證明的真諦。

這類交互式證明的巨大威力——相對於古希臘人開創的傳統靜態證明——直到五年後的 1990 年才被人們充分認識。當時，Carsten Lund、Lance Fortnow、Howard Karloff 和 Noam Nisan 提出了求和檢驗協議：用於交互式證明系統的代數方法。結合 Adi Shamir 的後續工作，這很快促成了“IP=PSPACE”這一基礎性結論——這是一種技術性的說法，它概括了以下直觀的陳述：

如果證明者和驗證者能夠交互——即像傳統證明系統那樣進行挑戰-回應，（假設一個說謊的證明者不會被其無法回答的挑戰“抓到”），那麼，與古希臘傳統的、靜態的、書面證明相比，我們可以快速驗證更為複雜的陳述。

換句話說：交互屬性賦予了我們在證明系統中極大的優勢。而求和檢驗（sum-check）正是將這種優勢轉化為高效驗證的核心——它允許驗證者在無需重構整個待證明的計算過程的情況下，驗證所聲稱的結果。

幾年後，Joe Kilian 提出了從概率可驗證證明（PCP）出發構建簡潔的零知識論證。在 PCP 的證明理論中，證明者（可以想像成古希臘的數學家，只不過現在是計算機）將一個普通的證明寫在一本“書”裡，但格式高度冗餘。值得注意的是，這種冗餘使得驗證者無需閱讀整本書：驗證者只需隨機抽取固定數量的證明位置——比如書中的三個“詞”——就能高置信度地判斷整個證明是否有效。

然而，問題在於 PCP 證明本身很長，儘管驗證成本很低。

因此，Kilian 展示了如何將 PCP 與密碼學相結合，允許證明者“承諾”完成這本“長書”，然後只公開抽取的幾個詞，並附上簡短的密碼學認證。Kilian 協議中的最終證明實際上就是這幾個詞（加上一些密碼學認證數據）——但它們足以讓驗證者相信整本書都有效。

這些證明當時仍是交互式的。隨後，Micali 展示了如何通過應用 Fiat-Shamir 變換，將 Kilian 基於 PCP 的交互式論證轉化為非交互式論證。簡而言之，Fiat-Shamir 變換“消除”了驗證者的隨機挑戰，使證明者能夠自行生成挑戰並一次性輸出整個證明。

遺留架構的持久影響

縱觀證明系統的歷史和演進，我們經歷了從靜態到交互式，再到概率性和非交互式（PCP），然後又回到交互式（參見 Kilian），最後再次回到非交互式（參見 Micali）的演變。SNARK 出現在這一演進的末端：通過將 Fiat-Shamir 變換應用於 Kilian 的交互式論證，Micali 得到了我們現在所說的第一個 SNARK 構造。

但在這些早期的基於 PCP 的 SNARK 中，證明者的工作量巨大——計算耗時過長——使得它們難以實際部署。

然而，SNARK 的設計方式卻沿用了數十年。即使業界嘗試擺脫基於 PCP 的 SNARK 設計方法，設計者仍然使用相關的概念（例如“線性 PCP”等），這些概念實際上只是 PCP 啟發式技術的變體。雖然這些方法確實帶來了證明極短的 SNARK，但它們並沒有帶來證明者速度最快的 SNARK。

SNARK 設計師們始終沒有回歸其根本來源——求和校驗協議——來獲得如今借助現代計算已然可能實現的更快、更易用的證明者。

退一步講：要更早地採用求和校驗協議，就需要以非線性的方式審視我們上面概述的 SNARK 的歷史和演變。從 (a) 交互式證明 → (b) PCP → © 簡潔交互式論證 → (d) 早期 SNARK 的發展歷程中，業界經歷了以下轉變：

在從(a) 交互式證明 → (b) PCP 的轉變過程中，主要挑戰在於如何在保持驗證簡潔性的同時，從證明系統中移除交互。這促使設計者摒棄了求和校驗協議（即交互部分）。

但當從 (b) PCP 過渡到 © 簡潔零知識論證時，交互又重新出現……最終，通過 Fiat-Shamir 變換將其移除，從而實現了從 © 簡潔交互式論證到 (d) 早期 SNARK 的轉變。

事後來看，從 (a) → (b) → © → (d) 線性地審視所有這些步驟，我們可以清楚地看到，SNARK 設計者實際上兩次省略了交互——一次是從 (a) → (b)，另一次是從 © → (d)。

但如果我們打算使用 Fiat-Shamir 來消除交互……我們應該直接跳過中間步驟 (b)，也就是概率可驗證證明！跳過中間這個 (b) 步驟，正是 Jolt 方法背後的關鍵洞見，它直接從交互式證明構建 SNARK——直奔求和驗證。

為什麼更多的人沒有更早地轉向基於求和驗證協議的設計方法呢？早期的 SNARK 設計者可能沒有這樣做，是因為 PCP 和 SNARK 表面上看起來很相似，因為它們都實現了簡潔驗證的概念。至於後續發展，架構——以及誤解——可能會持續存在。

對我們而言，將大量工程和研究資源投入到基於求和校驗的 zkVM Jolt 中，是一種逆向押注，因為它與 SNARK 領域數十年來占據主導地位的範式背道而馳。

‘Jolt Inside’

Jolt 的 SNARK 設計方法（其本身基於批量求值和內存檢查機制，例如 Twist + Shout）基於交互式證明和求和校驗協議。

如今，在我們開始構建 Jolt 幾年之後，其他人也開始在他們的設計中採用求和校驗協議方法。那么，Jolt 在當今的 zkVM 中有哪些顯著特點呢？Jolt 最大限度地利用了 CPU 執行中的重複結構。通過觀察每個 CPU 核心的“取指-解碼-執行”抽象如何適用於批量求值機制，Jolt 以最小的複雜度實現了無與倫比的效率。

與之相對，其他 zkVM 則嚴重依賴“預編譯”（類似於 ASIC 的加速器，用於特定子程序）來實現合理的性能。Jolt 摒棄了這些預編譯，因為它們會重蹈 zkVM 出現之前 SNARK 設計方法的覆轍：由於需要專家來設計這類專用 SNARK，它們更容易出現 bug，也更難被廣大開發者使用。Jolt 的重點在於普及 SNARK。

驗證 CPU 執行的正確性正是 zkVM 的核心價值所在——也是開發者體驗的一大突破——因為它允許重用現有的、經過強化的通用計算基礎設施。全球的計算基礎設施都是為了支持 CPU 而構建的，而 Jolt 則充分利用了 CPU 執行固有的“結構”，最大限度地提升了簡潔性和性能。

Jolt 從一開始就將可用性與生產級性能放在首位：開發者可以直接驗證現有程序；即使是為了快速驗證，也無需修改任何代碼。Jolt 不會像其他方案那樣，為了達到可接受的性能而強迫團隊圍繞“預編譯”或特殊 API 重構應用程序，而是保持原始代碼的完整性，使其更易於採用、更易於審計，並且迭代成本更低。

更重要的是，Jolt 不僅速度更快，而且更簡單。其他方案需要 zkVM 設計者為虛擬機的每條基本指令指定一個電路，而 Jolt 則不需要：在 Jolt 中，每條基本指令只需大約十行 Rust 代碼即可指定。無需電路，只需十行代碼。

Jolt 的下一步是什麼？

我們在速度方面已經處於領先地位。隨著進一步的優化和功能的加入，包括遞歸和零知識證明——尤其是我們計劃從橢圓曲線密碼學到格密碼學的轉變——我們將在今年晚些時候實現速度的又一個數量級提升，更不用說後量子時代了。

Jolt 讓更多應用成為可能。對於區塊鏈而言，大家期待已久的擴展性和去中心化將變得更加易於部署。零知識證明匯總可以開箱即用，無需耗費數月甚至數年的密碼工程。

但隨著 Jolt 的進一步發展——例如，打造可在手機和筆記本電腦上運行的快速簡便的零知識證明虛擬機——開發者將能夠在客戶端和隱私保護方面解鎖更多用例。例如，手機上的隱私保護應用可以從難以維護、幾乎無法運行，輕鬆實現開箱即用。

從長遠來看，這些證明系統將成為世界數字基礎設施的核心組成部分，類似於加密和數字簽名。這種通用的加密壓縮技術——任何人只需發送一個 5萬字節的證明文件，而非全部數據，即可證明自己掌握了滿足特定屬性的數 GB 數據——功能如此強大，以至於很難預測人們會用它開發出哪些應用。其可能性無窮無盡。