jakiro
作者：Justin Thaler 來源：a16z 翻譯：善歐巴，比特鏈視界
零知識虛擬機（zkVMs） 旨在「讓 SNARKs 走向大眾化」，使得即使沒有 SNARK 專業知識的人，也能證明他們在特定輸入（或見證）上正確運行了某個程序。其核心優勢在於開發者體驗，但當前 zkVMs 在 安全性 和 性能 方面仍面臨巨大挑戰。如果 zkVMs 想兌現承諾，設計者必須克服這些障礙。本文將探討 zkVM 發展的可能階段，整個過程可能需要 數年 才能完成——別聽信任何人說這能很快實現。
面臨的挑戰
在 安全性 方面，zkVMs 是高度複雜的軟體項目，仍然充滿漏洞。
在 性能 方面，證明一個程序的正確執行可能比原生運行慢 數十萬倍 ，使得大多數應用在現實世界的部署 暫不可行 。
儘管如此，區塊鏈行業的許多聲音仍然宣傳 zkVMs 已經可以立即部署 ，甚至一些項目已經在支付高昂的計算成本，以生成鏈上活動的零知識證明。然而，由於 zkVMs 仍存在諸多漏洞，這種做法實際上只是 一種昂貴的偽裝 ，讓系統看起來像是由 SNARK 保護，而實際上它要麼依賴 權限控制 ，要麼更糟糕—— 暴露於攻擊風險 。
現實情況是，我們距離構建真正安全且高效的 zkVM 仍有數年之遙。 本文提出了一系列 具體且分階段 的目標，以幫助我們追蹤 zkVM 的真實進展，削弱炒作，並引導社區關注真正的技術突破。
安全性發展階段
背景
基於 SNARK 的 zkVMs 通常包含兩個核心組件：
1. 多項式交互式預言機證明（Polynomial Interactive Oracle Proof, PIOP） ：用於證明多項式（或由多項式派生的約束）的交互式證明框架。
2. 多項式承諾方案（Polynomial Commitment Scheme, PCS） ：確保證明器無法偽造多項式評估結果而不被檢測到。
zkVM通過 將有效的執行軌跡編碼為約束系統 ，確保虛擬機的 寄存器 和 內存 的正確使用，然後利用 SNARK 證明這些約束的滿足性。
在如此複雜的系統中，唯一能確保 zkVM 無漏洞的方法就是 形式化驗證 。以下是 zkVM 安全性的不同階段，其中 第一階段關注協議正確性 ， 第二和第三階段關注實現正確性 。
安全性階段 1：正確的協議
-
PIOP 可靠性的正式驗證證明；
-
PCS 在某些加密假設或理想模型下具有約束力的形式驗證證明；
-
如果使用 Fiat-Shamir，則通過結合 PIOP 和 PCS 獲得的簡潔論證在隨機預言模型中是安全的正式驗證證明（根據需要使用其他加密假設進行增強）；
-
PIOP 所應用的約束系統等同於 VM 的語義的形式驗證證明；
-
將以上所有這些部分全面「粘合」成一個單一的、經過形式化驗證的安全 SNARK 證明，用於運行 VM 字節碼指定的任何程序。如果協議打算實現零知識，則還必須對此屬性進行形式化驗證，以確保不會洩露有關見證人的敏感信息。
如果 zkVM 使用 遞歸 ，那麼在遞歸過程中涉及的 PIOP、承諾方案和約束系統 都必須經過驗證 ，否則該子階段不能算作完成。
安全性階段 2：正確的驗證器實現
這一階段要求對 zkVM 驗證器 的實際實現（如 Rust、Solidity 等）進行 形式化驗證 ，確保其符合第一階段已經驗證的協議。完成該階段意味著 zkVM 的 實現 與 理論設計 是一致的，而不僅僅是一個 紙面上的安全協議 ，或一個使用 Lean 等語言編寫的低效規範。
為什麼 只關注驗證器，而不關注證明者 主要有兩個原因：首先， 確保驗證器正確，即可保證 zkVM 證明系統的完備性 （即：確保驗證器不會被欺騙，使其接受一個錯誤的證明）。其次， zkVM 的驗證器實現比證明者實現簡單一個數量級以上 ，驗證器的正確性更容易在短期內得到保障。
安全性階段 3：正確的證明者實現
這一階段要求對 zkVM 證明者 的實際實現進行 形式化驗證 ，確保它能夠 正確生成 第一、二階段中已經驗證的證明系統的證明。這一階段的目標是 完備性 ，即：任何使用 zkVM 的系統都不會因為無法證明某個合法語句而 卡死 。如果 zkVM 需要具備零知識屬性，則必須提供形式化驗證，以確保證明不會洩露關於見證的任何信息。
預計時間表
第 1 階段進展 ：我們可以期待明年取得一些進展（例如， ZKLib 就是這樣一項努力）。但至少兩年內沒有一個 zkVM 能夠完全滿足第 1 階段的要求。
第 2 和第 3 階段 ：這些階段可以與第 1 階段的某些方面同時推進。例如，一些團隊已經證明Plonk 驗證器的實現與論文中的協議相匹配（儘管論文的協議本身可能未得到完全驗證）。儘管如此，我預計任何 zkVM 都不會在不到四年的時間內達到第 3 階段——甚至可能更長。
關鍵注意事項：Fiat-Shamir 安全性與已驗證的字節碼
一個主要的複雜性問題是， Fiat-Shamir 變換的安全性仍然存在未解的研究問題 。所有三個安全階段都將 Fiat-Shamir 和隨機預言機視為絕對安全，但實際上整個範式可能存在漏洞。這是由於 隨機預言機的理想化模型與實際使用的哈希函數之間存在差異 。
在最壞的情況下，一個已經達到 安全性階段 2 的系統，可能 因 Fiat-Shamir 相關問題而被發現完全不安全 。這值得我們高度關注，並持續進行研究。我們可能需要 修改 Fiat-Shamir 變換本身，以更好地防禦此類漏洞 。
不使用遞歸的系統在理論上更安全 ，因為已知的一些攻擊涉及的電路類似於遞歸證明中使用的電路。但這一風險仍然是一個 未解決的基本問題 。
另一個需要注意的問題是，即使 zkVM 證明了某個計算程序（由字節碼指定）被 正確執行 ，但如果 字節碼本身存在缺陷 ，那麼這個證明的價值 極其有限 。因此，zkVM 的實用性在很大程度上依賴於 如何生成經過形式化驗證的字節碼 ，而這一挑戰 極其巨大 ，並且 超出了本文的討論範圍 。
關於抗量子安全性
在未來至少 5 年（甚至更長時間）內，量子計算機不會構成嚴重威脅，而軟體漏洞則是一個生死攸關的問題。 因此，目前的首要任務應該是實現本文所提出的安全性和性能目標。如果非抗量子安全的 SNARKs 能夠更快滿足這些目標，我們應該優先使用它們。等到抗量子 SNARKs 趕上發展，或者有跡象表明具備實際威脅的量子計算機即將出現時，再考慮切換。
具體的安全級別
100-bit 經典安全性 是任何 SNARK 用於保護有價值資產的 最低標準 （但仍然有一些系統 未達到這一低標準 ）。即便如此，這仍然 不應被接受 ，標準密碼學實踐通常要求 128-bit 安全性及以上 。 如果 SNARK 的性能真正達標，我們不應該為了提升性能而降低安全性 。
性能階段
當前情況
目前，zkVM 證明器 的計算開銷大約是 原生執行的 100 萬倍 。換句話說，如果一個程序的原生執行需要 X 個 CPU 周期 ，那麼 生成正確執行的證明 大約需要 X × 1,000,000 個 CPU 周期 。這一情況在 一年前如此，今天仍然如此 （儘管存在一些誤解）。
當前行業中的一些流行說法可能會造成誤導，例如：
1. 「為整個以太坊主網生成證明的成本低於每年 100 萬美元。」
2. 「我們幾乎實現了以太坊區塊的實時證明生成，只需要幾十張 GPU。」
3. 「我們的最新 zkVM 比前代快 1000 倍。」
然而，這些說法在沒有上下文的情況下可能具有誤導性：
• 比舊版 zkVM 快 1000 倍，仍然可能非常慢 ，這更能說明 過去有多糟糕，而不是現在有多好 。
• 以太坊主網的計算量可能在未來增加 10 倍 ，這將使當前 zkVM 的性能遠遠跟不上需求。
• 所謂的「幾乎實時」 證明生成，在許多區塊鏈應用的需求下仍然 過於緩慢 （例如 Optimism 的區塊時間為 2 秒，比以太坊的 12 秒快得多 ）。
• 「幾十張 GPU 長時間 24/7 運行」 並不能提供 足夠的活性保證 。
• 這些 證明生成時間通常是針對超過 1MB 的證明大小 ，而這對於許多應用來說 過大 。
• 「每年不足 100 萬美元的成本」 只是因為 以太坊完整節點一年僅執行約 25 美元的計算 。
對於區塊鏈之外的應用場景，這種計算開銷顯然過高。無論多少並行計算或工程優化，都無法彌補如此巨大的計算開銷。
我們應該設定的基本目標是：性能開銷不超過原生執行的 100,000 倍。但即便如此，這仍然只是第一步。如果要實現真正的大規模主流應用，我們可能需要將開銷降低到原生執行的 10,000 倍或更少。
性能測量
SNARK 性能有三個主要組成部分：
1. 底層證明系統的固有效率 。
2. 針對特定應用的優化 （例如預編譯）。
3. 工程和硬體加速 （例如 GPU、FPGA 或多核 CPU）。
雖然（2）和（3）對於實際部署至關重要，但它們適用於任何證明系統，因此 不一定能反映基本開銷的改進 。例如，給 zkEVM 添加 GPU 加速和預編譯可以輕鬆比單純依賴 CPU 提高 50 倍的速度——這可能會讓一個固有效率較低的系統看起來優於另一個未經過相同優化的系統。
因此，本文重點衡量 在沒有專用硬體和預編譯的情況下，SNARK 的基本性能 。這與當前的基準測試方法不同，後者通常將所有三個因素合併為一個「總體數值」。這就像 通過拋光時間來評判鑽石，而不是評估其固有的清晰度 。
我們的目標是 隔離通用證明系統的固有開銷 ，降低尚未深入研究的技術的進入門檻，並幫助社區排除幹擾因素，從而聚焦於 證明系統設計的真正進展 。
性能階段
以下是我提出的五個性能階段的裡程碑。首先，我們需要在 CPU 上大幅降低證明者開銷，之後才能進一步依靠硬體減少開銷。同時，內存使用也必須得到改善。
在所有階段中， 開發者不應為了 zkVM 的性能而調整代碼 。開發者體驗是 zkVM 的核心優勢。如果為了滿足性能基準而犧牲 DevEx，那不僅失去了基準測試的意義，也違背了 zkVM 的初衷。
這些指標主要關注 證明者成本 。然而，如果允許驗證器 成本無限制增長 （即無上限的證明大小或驗證時間），那麼任何證明者指標都可以輕鬆滿足。因此，要滿足下述階段的要求， 必須同時限定最大證明大小和最大驗證時間 。
階段 1 要求：「合理的非平凡驗證成本」
• 證明大小 ：必須小於見證大小。
• 驗證時間 ：驗證證明的速度不得比程序的原生執行慢（即，不得比直接執行計算慢）。
這些是 最低限度的簡潔性要求 ，確保 證明大小和驗證時間不會比直接發送見證給驗證器並讓其直接檢查更糟糕 。
階段 2 及以上
• 最大證明大小 ：256 KB。
• 最大驗證時間 ：16 毫秒。
這些上限有意設置得較為寬鬆，以適應新穎的快速證明技術，即使它們可能帶來更高的驗證成本。同時，這些上限排除了成本高昂到幾乎沒有項目願意在區塊鏈上使用的證明。
速度階段 1
單線程證明速度不得比原生執行慢超過 100,000 倍 （適用於多種應用，而不僅僅是以太坊區塊證明），且不得依賴預編譯。
具體而言 ，假設一臺現代筆記本上的 RISC-V 處理器運行速度約為 30 億周期/秒 ，那麼達到階段 1 意味著該筆記本能夠以 30,000 RISC-V 周期/秒 的速度生成證明（單線程）。
驗證器成本必須滿足之前定義的「合理的非平凡驗證成本」標準。
速度階段 2
單線程證明速度不得比原生執行慢超過 10,000 倍 。
或者 ，由於某些有前景的 SNARK 方法（特別是二進位域 SNARK）受當前 CPU 和 GPU 限制，可以通過 FPGA（甚至 ASIC）來滿足此階段：
1. 計算 FPGA 以原生速度模擬的 RISC-V 內核數量。
2. 計算模擬和證明 RISC-V 執行（接近實時）所需的 FPGA 數量。
3. 如果（2）的數量 不超過（1）的 10,000 倍 ，則滿足階段 2。
• 證明大小 ：最大 256 KB。
• 驗證時間 ：標準 CPU 上最大 16 毫秒。
速度階段 3
在達到 速度階段 2 的基礎上，實現 1000× 以內的證明開銷 （適用於多種應用），並且必須使用 自動合成和形式化驗證的預編譯 。本質上， 動態定製每個程序的指令集，以加速證明生成 ，但必須保證 易用性和形式化驗證 。（關於 預編譯為何是一把雙刃劍 ，以及為什麼「手寫」 預編譯不是可持續的方法，請參閱下一部分。）
內存階段 1
在少於 2 GB 內存的情況下 達到 速度階段 1 ，並同時滿足 零知識要求 。這一階段對於 行動裝置或瀏覽器 至關重要，並為 大量客戶端 zkVM 用例 打開了大門。例如，智慧型手機用於 位置隱私、身份憑證等 。如果證明生成需要超過 1-2 GB 內存，大多數行動裝置將無法運行。
兩點重要說明：
1. 即使是大規模計算（需要數萬億 CPU 周期的原生執行），證明系統也必須維持 2 GB 內存上限，否則適用性將受限。
2. 如果證明速度極慢，則保持 2 GB 內存上限很容易。因此，為了讓內存階段 1 有意義，必須在 2 GB 內存限制內達到速度階段 1。
內存階段 2
在少於 200 MB 內存的情況下 達到 速度階段 1 （比內存階段 1 提高 10 倍）。
為什麼要降低到 200 MB？考慮一個 非區塊鏈場景 ：當你訪問 HTTPS 網站時，會下載認證和加密證書。如果網站改為發送這些證書的 zk 證明，大型網站每秒可能需要生成 數百萬個證明 。如果每個證明需要 2 GB 內存，計算資源需求將達到 PB 級別 ，顯然不可行。因此，進一步降低內存使用對 非區塊鏈應用 至關重要。
預編譯：最後一英裡，還是拐杖？
預編譯 指的是 專門為特定函數（如哈希、橢圓曲線籤名）優化的 SNARK 約束系統 。在以太坊中，預編譯能降低 Merkle 哈希和籤名驗證的開銷，但過度依賴預編譯並不能真正提升 SNARK 的核心效率。
預編譯的問題
1.仍然過慢 ：即使使用哈希和籤名預編譯，zkVM 在區塊鏈內外仍然存在核心證明系統的低效問題。
2.安全漏洞 ：手寫預編譯如果未經形式化驗證，幾乎必然存在漏洞，可能導致災難性安全失敗。
3.開發者體驗差 ：目前，許多 zkVM 需要開發者 手寫約束系統 ，類似 1960 年代的編程方式，嚴重影響開發體驗。
4.基準測試誤導 ：如果基準測試依賴於優化特定預編譯，可能會誤導人們關注優化手工約束系統，而非提升 SNARK 設計本身。
5.I/O 開銷和無 RAM 訪問 雖然預編譯可以提高繁重加密任務的性能，但它們可能無法為更多樣化的工作負載提供有意義的加速，因為它們在傳遞輸入/輸出時會產生大量開銷，並且它們不能使用 RAM。
即使在區塊鏈環境中，只要你超越了像以太坊這樣的單一 L1（比如，你想建立一系列跨鏈橋），你就會面臨不同的哈希函數和籤名方案。為了解決這個問題而不斷進行預編譯，這既不可擴展，又會帶來巨大的安全風險。
我確實相信預編譯從長遠來看仍然至關重要，但只有在它們自動合成並經過正式驗證後才會如此。這樣，我們可以保持 zkVM 的開發人員體驗優勢，同時避免災難性的安全風險。這一觀點反映在階段3 中。
預期時間表
我預計少數 zkVM 將在今年晚些時候達到 速度階段 1 和 內存階段 1 。我認為在接下來的兩年內，我們也能實現 速度階段 2 ，但目前尚不清楚能否在沒有新的研究思路的情況下達到這一目標。
我預計其餘階段（ 速度階段 3 和 內存階段 2 ）將需要數年時間才能達成。
儘管本文分別列出了 zkVM 的安全性和性能階段，但這兩者並非完全獨立。隨著 zkVM 中的漏洞不斷被發現，我預計其中一些漏洞的修復將不可避免地導致性能大幅下降。因此，在 zkVM 達到 安全階段 2 之前，其性能測試結果都應被視為暫定數據。
zkVM 在讓零知識證明真正普及方面具有巨大潛力，但目前仍處於早期階段——充滿安全挑戰，並且存在嚴重的性能瓶頸。市場炒作和營銷宣傳讓衡量真正的進展變得困難。通過明確的安全性和性能裡程碑，我希望提供一條能夠撥開迷霧的路線圖。我們終將到達目標，但這需要時間，以及在研究和工程上的持續努力。
