原文標題：The path to secure and efficient zkVMs: How to track progress

原文作者： a16z crypto

原文編譯：Golem，Odaily 星球日報

zkVM（零知識虛擬機）承諾「使 SNARK 大眾化」，允許任何人（即使是沒有專業 SNARK 專業知識的人）證明他們已經正確運行了給定輸入（或見證）上的任何程序。它們的核心優勢在於開發人員體驗，但目前它們在安全性和性能方面都面臨巨大挑戰。為了讓 zkVM 的願景兌現承諾，設計人員必須克服這些挑戰。在這篇文章中，我列出了 zkVM 開發的可能階段，完成這些階段將需要幾年時間。

挑戰

在安全方面，zkVM 是高度複雜的軟件項目，仍然充滿了漏洞。在性能方面，證明程序正確執行的速度可能比本地運行慢數十萬倍，這使得大多數應用程序目前無法在現實世界中部署。

儘管存在這些現實挑戰，但區塊鏈行業的大部分公司都將 zkVM 描繪為可以立即得到部署。事實上，一些項目已經支付了大量計算成本來生成鏈上活動的證明。但因為 zkVM 仍不完善，這僅僅是假裝系統受到 SNARK 保護的一種昂貴的方式，而實際上它要麼通過許可來保護，要麼更糟的是，容易受到攻擊。

我們距離實現安全且高性能 zkVM 還有數年的時間。這篇文章提出了一系列分階段的具體目標來跟蹤 zkVM 的進展——這些目標可以消除炒作並幫助社區專注於真正的進步。

安全階段

基於 SNARK 的 zkVM 通常包括兩個主要組件：

· **多項式交互式 Oracle 證明 (PIOP)：**用於證明關於多項式（或從中得出的約束）的陳述的交互式證明框架。

· **多項式承諾方案 (PCS)：**確保證明者不能在不被發現的情況下對多項式評估撒謊。

zkVM 本質上將有效的執行跟蹤編碼為約束系統——廣義上意味著它們強制虛擬機正確使用寄存器和內存——然後應用 SNARK 來證明這些約束得到滿足。

確保像 zkVM 這樣複雜的系統沒有錯誤的唯一途徑是形式化驗證。以下是安全階段的細分。第 1 階段側重於正確的協議，而第 2 階段和第 3 階段側重於正確的實現。

安全階段 1 ：正確的協議

1、PIOP 可靠性的正式驗證證明；

2、PCS 在某些加密假設或理想模型下具有約束力的形式驗證證明；

3、如果使用 Fiat-Shamir，則通過結合 PIOP 和 PCS 獲得的簡潔論證在隨機預言模型中是安全的正式驗證證明（根據需要使用其他加密假設進行增強）；

4、PIOP 所應用的約束系統等同於 VM 的語義的形式驗證證明；

5、將以上所有這些部分全面「粘合」成一個單一的、經過形式化驗證的安全 SNARK 證明，用於運行 VM 字節碼指定的任何程序。如果協議打算實現零知識，則還必須對此屬性進行形式化驗證，以確保不會洩露有關見證人的敏感信息。

**遞歸警告：**如果 zkVM 使用遞歸，則必須驗證該遞歸中任何地方涉及的每個 PIOP、承諾方案和約束系統，才能將此階段視為完成。

安全階段 2 ：正確的驗證器實現

形式化驗證證明 zkVM 驗證器的實際實現（使用 Rust、Solidity 等）與第 1 階段驗證的協議相匹配。實現這一點可確保實現的協議是合理的（而不僅僅是紙面上的設計，或用 Lean 等編寫的低效規範）。

第 2 階段僅關注驗證器實現（而不是證明器）的原因有兩個方面。首先，正確使用驗證器已經足以保證可靠性（即確保驗證器無法相信任何虛假陳述實際上是真實的）。其次，zkVM 驗證器實現比 prover 實現簡單一個數量級以上。

安全階段 3 ：正確的證明器實現

zkVM 證明器的實際實現正確生成了第 1 階段和第 2 階段驗證的證明系統的證明，即得到正式驗證。這確保了完整性，也就是說，任何使用 zkVM 的系統都不會被無法證明的語句「卡住」。如果證明器打算實現零知識，則必須正式驗證此屬性。

預計時間表

**· 第 1 階段進展：**我們可以期待明年取得逐步成就（例如 ZKLib）。但至少兩年內沒有 zkVM 能夠完全滿足第 1 階段的要求；

**· 第 2 和第 3 階段：**這些階段可以與第 1 階段的某些方面同時推進。例如，一些團隊已經證明 Plonk 驗證器的實現與論文中的協議相匹配（儘管論文的協議本身可能沒有完全驗證）。儘管如此，我預計任何 zkVM 都不會在不到四年的時間內達到第 3 階段——而且可能更長。

關鍵注意事項：Fiat-Shamir 安全性和經過驗證的字節碼

一個主要的複雜因素是，圍繞 Fiat-Shamir 轉換的安全性存在未解決的研究問題。所有三個階段都將 Fiat-Shamir 和隨機預言機視為它們無懈可擊安全性的一部分，但實際上整個範式可能存在漏洞。這是由於隨機預言機過於理想化和實際使用的哈希函數之間的差異。在最壞的情況下，由於 Fiat-Shamir 問題，已經達到第 2 階段的系統後來可能會被發現完全不安全。這引起了嚴重的擔憂和持續的研究。我們可能需要修改轉換本身以更好地防範此類漏洞。

沒有遞歸的系統在理論上更為穩固，因為某些已知攻擊涉及的電路類似於遞歸證明中使用的電路。

另一個值得注意的是，如果字節碼本身存在缺陷，那麼證明即使已正確運行了計算機程序（通過字節碼指定），價值也是有限的。因此，zkVM 的實用性在很大程度上取決於生成形式化驗證的字節碼的方法——這是一個巨大的挑戰，超出了本文所討論的範圍。

關於後量子時代的安全性

至少在未來五年內（可能更長），量子計算機不會構成嚴重威脅，而漏洞則是一種生存風險。因此，現在的主要重點應該是滿足本文中討論的安全性和性能階段。如果我們能夠使用非量子安全的 SNARK 能夠更快地滿足了這些安全要求，那麼我們就應該這樣做，直到後量子 SNARK 趕上來，或者人們嚴重擔心加密相關的量子計算機出現在考慮其他。

zkVM 的性能現狀

**目前，zkVM 證明器產生的開銷係數接近原生執行成本的 100 萬倍。**如果程序需要 X 個週期才能運行，則證明正確執行的成本約為 X 乘以 100 萬個 CPU 週期。一年前便是這種情況，，今天仍然如此。

流行的敘事通常以聽起來可以接受的方式來描述這種開銷。例如：

·「為所有以太坊主網生成證明每年的成本不到一百萬美元。」

·「我們幾乎可以使用由數十個 GPU 組成的集群實時生成以太坊區塊證明。」

·「我們最新的 zkVM 比其前身快 1000 倍。」

雖然從技術上講這些說法是準確的，但如果沒有適當的背景，可能會產生誤導。例如：

· 比舊版 zkVM 快 1000 倍，但絕對速度仍非常慢。這更多說明的是事情有多糟糕，而不是有多好。

· 已經有人提議將以太坊主網處理的計算量增加 10 倍。這將使當前的 zkVM 性能變得更慢。

· 人們所說的「以太坊區塊的近乎實時證明」仍然比許多區塊鏈應用程序所要求的要慢得多（例如，Optimism 的區塊時間為 2 秒，比以太坊的 12 秒區塊時間快得多）。

·「數十個 GPU 始終運行，毫無差錯」無法達到可接受的活性保證。

· 每年花費不到一百萬美元來證明以太坊主網上的所有活動反映了以太坊完整節點每年僅需要花費約 25 美元執行計算的事實。

對於區塊鏈以外的應用程序，這樣的開銷顯然太高了。**任何並行化或工程都無法抵消如此巨大的開銷。**我們應該以相較於本機執行，zkVM 速度減慢不超過 100, 000 倍為基本基準——即使這只是第一步。真正的主流採用可能需要接近 10, 000 倍或更低的開銷。

如何衡量性能

SNARK 性能有三個主要組成部分：

· 底層證明系統的內在效率。

· 特定於應用程序的優化（例如預編譯）。

· 工程和硬件加速（例如 GPU、FPGA 或多核 CPU）。

雖然後兩者對於實際部署至關重要，但它們通常適用於任何證明系統，因此它們不一定能反映基本開銷。例如，在 zkEVM 中添加 GPU 加速和預編譯可以輕鬆實現 50 倍的加速，而這比純基於 CPU 的無預編譯方法要快得多——足以讓本質上效率較低的系統看起來優於沒有經過同樣打磨的系統。

**因此，下面重點介紹在沒有專門硬件和預編譯的情況下，SNARK 的性能。**這與當前的基準測試方法不同，後者通常將所有三個因素歸結為一個「標題數字」。這相當於根據鑽石的拋光時間而不是其固有的淨度來判斷鑽石價值。我們的目標是排除通用證明系統的內在開銷——幫助社區消除混雜因素，專注於證明系統設計的真正進展。

性能階段

以下是 5 個性能實現的里程碑。首先，我們需要將 CPU 上的證明器開銷削減多個數量級。只有這樣，重點才應該轉向通過硬件進一步減少。內存使用率也必須提高。

在下面的所有階段中，開發人員都不必根據 zkVM 設置定製的代碼來實現必要的性能。開發人員體驗是 zkVM 的主要優勢。犧牲 DevEx 來滿足性能基準會違背 zkVM 本身的意義。

這些指標側重於證明者成本。但是，如果允許無限制的驗證者成本（即證明大小或驗證時間沒有上限），則可以輕鬆滿足任何證明者指標。因此，對於要符合所述階段的系統，必須為證明大小和驗證時間指定最大值。

性能要求

第 1 階段要求：「合理且非平凡的驗證成本」：

· 證明大小：證明大小必須小於見證大小。

· 驗證時間：驗證證明的速度不得慢於本機運行程序（即，在沒有正確性證明的情況下執行計算）。

這些是最低限度的簡潔要求。它們確保證明大小和驗證時間不會比將見證發送給驗證者並讓驗證者直接檢查其正確性的方法更差。

第 2 階段及以後要求：

· 最大證明大小： 256 KB。

· 最大驗證時間： 16 毫秒。

這些截止值是故意有加大的，以適應可能帶來更高驗證成本的新型快速證明技術。同時，它們排除了非常昂貴的證明，以至於很少有項目願意將它們包含在區塊鏈中。

速度階段 1

單線程證明必須比本機執行慢最多十萬倍，在一系列應用程序中進行測量（不僅僅是證明以太坊區塊），而不依賴於預編譯。

具體來說，想象一下在現代筆記本電腦上以每秒大約 30 億次週期運行的 RISC-V 進程。實現第 1 階段意味著您可以在同一檯筆記本電腦上每秒證明大約 30, 000 個 RISC-V 週期（單線程）。但驗證成本必須如前所述「合理且非平凡」。

速度階段 2

單線程證明必須比本機執行慢最多一萬倍。

或者，由於一些有前途的 SNARK 方法（尤其是基於二進制字段的方法）受到當前 CPU 和 GPU 的阻礙，您可以通過比較使用 FPGA（甚至 ASIC）達到此階段：

FPGA 可以以本機速度模擬的 RISC-V 內核數量；

模擬和證明（近乎）實時執行 RISC-V 所需的 FPGA 數量。

如果後者最多比前者多 10, 000 倍，則您有資格進入第 2 階段。在標準 CPU 上，證明大小必須最多為 256 KB，驗證器時間最多為 16 毫秒。

速度階段 3

**除了達到速度階段 2 之外，還可以使用自動合成和形式驗證的預編譯實現低於 1000 倍的證明開銷（適用於廣泛的應用程序）。**本質上，可以為每個程序動態定製指令集以加速證明，但要以易於使用和形式驗證的方式進行。

內存階段 1

第 1 階段的速度是在證明器所需的內存少於 2 GB 的情況下實現的（同時還實現了零知識）。

這對於許多移動設備或瀏覽器來說至關重要，因此開啟了無數客戶端 zkVM 用例。客戶端證明很重要，因為我們的手機是我們與現實世界的持續聯繫：它們跟蹤我們的位置、憑證等。如果生成證明需要超過 1-2 GB 的內存，那麼對於當今的大多數移動設備來說實在是太多了。需要澄清兩點：

· 2 GB 空間界限適用於大型語句（需要數萬億個 CPU 週期才能本地運行的語句）。僅針對小型語句實現空間界限的證明系統缺乏廣泛的適用性。

· 如果證明器非常慢，則很容易將證明器的空間保持在 2 GB 內存以下。因此，為了使內存階段 1 變得不簡單，我要求在 2 GB 空間界限內滿足速度階段 1。

內存階段 2

階段 1 的速度是在內存使用量不到 200 MB 的情況下實現的（比內存階段 1 好 10 倍）。

為什麼要推到 2 GB 以下？考慮一個非區塊鏈示例：每次通過 HTTPS 訪問網站時，您都會下載證書以進行身份驗證和加密。相反，網站可以發送擁有這些證書的 zk 證明。大型網站每秒可能會發出數百萬個這樣的證明。如果每個證明都需要 2 GB 內存來生成，那麼總共需要 PB 級的 RAM。進一步降低內存使用量對於非區塊鏈部署至關重要。

預編譯：最後一英里還是柺杖？

在 zkVM 設計中，預編譯是指針對特定功能量身定製的專用 SNARK（或約束系統），例如用於數字簽名的 Keccak/SHA 哈希或橢圓曲線群運算。在以太坊中（大部分繁重工作涉及 Merkle 哈希和簽名檢查），一些手動製作的預編譯可以減少證明器開銷。但依賴它們作為柺杖並不能讓 SNARK 達到它們需要的目的。原因如下：

**· 對於大多數應用程序（區塊鏈內部和外部）來說仍然太慢：**即使使用哈希和簽名預編譯，當前的 zkVM 仍然太慢（無論是在區塊鏈環境內還是在區塊鏈環境之外），因為核心證明系統效率低下。

**· 安全故障：**未經正式驗證的手寫預編譯幾乎肯定充斥著錯誤，有可能導致災難性的安全故障。

**· 開發人員體驗不佳：**在當今的大多數 zkVMs 中，添加新的預編譯意味著為每個功能手動編寫約束系統——本質上回到了 1960 年代風格的工作流程。即使使用現有的預編譯，開發人員也必須重構代碼以調用每個預編譯。我們應該針對安全性和開發人員體驗進行優化，而不是為了追求增量性能而犧牲兩者。這樣做只能證明性能沒有達到應有的水平。

**· I/O 開銷且無 RAM：**儘管預編譯可提高繁重加密任務的性能，但它們可能無法為更多樣化的工作負載提供有意義的加速，因為它們在傳遞輸入/輸出時會產生大量開銷，並且它們無法使用 RAM。即使在區塊鏈環境中，只要您超越像以太坊這樣的單片 L1（例如，您想要構建一系列跨鏈橋），您就會面臨不同的哈希函數和簽名方案。在問題上一次又一次地進行預編譯無法擴展並帶來巨大的安全風險。

出於所有這些原因，我們的首要任務應該是提高底層 zkVM 的效率。產生最好的 zkVM 的技術也會產生最好的預編譯。我確實相信預編譯從長遠來看仍將至關重要，但前提是它們被自動合成並正式驗證。這樣，就可以保持 zkVM 的開發人員體驗優勢，同時避免災難性的安全風險。這一觀點反映在速度階段 3 中。

預計時間表

我預計少數 zkVM 將在今年晚些時候實現速度階段 1 和內存階段 1。我認為我們在未來兩年內也會實現速度階段 2，但目前尚不清楚，如果沒有一些尚未出現的新想法，我們能否實現這一目標。我預計剩餘的階段（速度階段 3 和內存階段 2）將需要幾年時間才能實現。

總結

雖然我在這篇文章中分別確定了 zkVM 安全性和性能的階段，但 zkVM 的這些方面並不完全獨立。隨著在 zkVM 中發現更多漏洞，預計有些漏洞只能在性能大幅下降的情況下才能修復。在 zkVM 達到安全階段 2 之前，性能應被暫緩。

zkVM 有望使零知識證明真正普及，但它們仍處於起步階段——充滿了安全挑戰和龐大的性能開銷。炒作和營銷宣傳使得評估真正的進展變得困難。通過闡明明確的安全和性能里程碑，希望能夠提供一個消除干擾的路線圖。我們會實現目標，但這需要時間和持續的努力。

原文鏈接

：