a16z：如何分階段實現安全高效的zkVM（開發者必看）

原文來自 a16z crypto

編譯｜ Golem（@web3_golem）

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

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

儘管存在這些現實挑戰，但區塊鏈行業的大部分公司都將 zkVM 描繪為可以立即得到部署。 事實上，一些項目已經支付了大量計算成本來生成鏈上活動的證明。

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

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

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

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

可能存在漏洞。 這是由於隨機預言機過於理想化和實際使用的哈希函數之間的差異。 在最壞的情況下，由於 Fiat-Shamir 問題，已經達到第 2 階段的系統後來可能會被發現完全不安全。 這引起了嚴重的擔憂和持續的研究。 我們可能需要修改轉換本身以更好地防範此類漏洞。

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

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

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

是這種情況，，今天仍然如此。

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

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

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

• “我們最新的 zkVM 比其前身快 1000 倍。”

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

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

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

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

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

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

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

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

這與當前的基準測試方法不同，後者通常將所有三個因素歸結為一個“標題數字”。 這相當於根據鑽石的拋光時間而不是其固有的淨度來判斷鑽石價值。  我們的目標是排除通用證明系統的內在開銷——幫助社區消除混雜因素，專注於證明系統設計的真正進展。

性能階段

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

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

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

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

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

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

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

• 最大證明大小： 256 KB。

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

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

但驗證成本必須如前所述“合理且非平凡”。

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

內存階段 1 

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

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

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

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

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

我預計剩餘的階段（速度階段 3 和內存階段 2）將需要幾年時間才能實現。

總結

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

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