Vitalik 詳解 5 種不同類型的 ZK-EVM

注：原文作者是以太坊聯合創始人 Vitalik Buterin。

特別感謝 PSE、Polygon Hermez、Zksync、Scroll、Matter Labs 以及 Starkware 團隊的討論和審查。

最近有很多“ZK-EVM”項目發布了華麗的公告，比如 Polygon 開源了他們的 ZK-EVM 項目，ZKSync 發布了他們的 ZKSync 2.0 計劃，而相對較新的 Scroll 在最近也宣布了他們的 ZK-EVM。隱私和擴容探索團隊（Privacy and Scaling Explorations）、Nicolas Liochon 等人的團隊、從 EVM 到 Starkware 的 Cairo 語言的alpha 編譯器也在不斷努力，當然，還有一些是我錯過的。

所有這些項目的核心目標都是相同的：使用 ZK-SNARK 技術來制作類似以太坊交易執行的密碼學證明，或者更容易驗證以太坊區塊鏈本身，或者構建與以太坊提供的功能相當（接近）但可擴展性更強的 ZK-rollup。但這些項目之間存在細微的差異，以及它們在實用性和速度之間做出了權衡。這篇文章將試圖描述 EVM 等效的不同“類型”的分類法，以及嘗試實現每種類型系統的好處與代價。

ZK-EVM 概覽圖

類型 1（完全等效于以太坊）

類型 1 的 ZK-EVM 力求完全且毫不妥協地與以太坊等效，它們不會改變以太坊系統的任何部分來更容易生成證明。它們不會取代哈希、狀態樹、tx 樹、預編譯或任何其他共識邏輯，無論這些邏輯多么次要。

優點：完美兼容

目標是能夠像今天一樣驗證以太坊區塊，或者至少驗證執行層端（因此，不包括信標鏈共識邏輯，但包括所有交易執行和智能合約和賬戶邏輯）。

類型 1 的 ZK-EVM 是我們最終需要的，它使以太坊 L1 層本身更具可擴展性。從長遠來看，在類型 2 或類型 3 ZK-EVM 中測試過的以太坊修改可能會引入到以太坊本身，但這種重新架構也有其自身的復雜性。

類型 1 的 ZK-EVM 也是 rollup 的理想選擇，因為它們允許 rollup 重用大量基礎設施。例如，以太坊執行客戶端可以按原樣使用來生成和處理 rollup 區塊（或者至少，一旦實現提款，它們就可以使用，并且可以重新使用該功能來支持將 ETH 存入 rollup 中），因此例如區塊瀏覽器、區塊生產等工具都是非常容易重新使用的。

缺點：證明者（prover）時間

以太坊最初并不是圍繞 ZK 友好性設計的，因此以太坊協議的許多部分需要大量計算才能進行 ZK 證明。類型 1 的 ZK-EVM 旨在精確復制以太坊，因此它無法緩解這些低效率問題。目前，以太坊區塊的證明需要很多小時才能夠產生。這可以通過巧妙的工程大規模并行化證明者（prover）來緩解，長期也可以通過 ZK-SNARK ASIC 來緩解。

那誰在構建 類型 1 的 ZK-EVM 呢？

隱私和擴容探索團隊（The Privacy and Scaling Explorations team）正在構建一個類型 1 的 ZK-EVM。（譯者注：The Privacy and Scaling Explorations 團隊即更名后的 appliedzkp）

類型 2（完全 EVM 等效）

類型 2 的 ZK-EVM 力求完全等效于 EVM，但不完全等效于以太坊。也就是說，它們“從內部”看起來與以太坊完全一樣，但它們在外部存在一些差異，特別是在區塊結構和狀態樹等數據結構方面。

目標是與現有應用完全兼容，但對以太坊進行一些小的修改，以使開發更容易并更快地生成證明。

優點：VM 級別的完美等效

類型 2 的 ZK-EVM 對保存諸如以太坊狀態之類的數據結構進行更改，幸運的是，這些結構是 EVM 本身無法直接訪問的，因此在以太坊上工作的應用，幾乎總是能在類型 2 的 ZK-EVM rollup 上運行。你將無法按原樣使用以太坊執行客戶端，但你可以通過一些修改來使用它們，并且你仍然可以使用 EVM 調試工具和大多數其他開發者基礎設施。

當然，也有少數例外的情況。對于驗證以太坊歷史區塊的 Merkle 證明以驗證歷史交易、收據或狀態聲明的應用，會出現一種不兼容的情況（例如，橋有時會這樣做）。用不同的哈希函數替換 Keccak 的 ZK-EVM 會破壞這些證明。但是，我通常建議不要以這種方式構建應用，因為未來的以太坊更改（例如 Verkle 樹）甚至會破壞以太坊本身的此類應用。更好的選擇是讓以太坊本身添加經得起未來考驗的歷史訪問預編譯。

缺點：盡管改進了，但證明者（prover）時間依然很慢

類型 2 的 ZK-EVM 提供比類型 1 的 ZK-EVM 更快的證明者時間，主要是通過刪除以太坊堆棧中依賴不必要的復雜和對 ZK 不友好的密碼學部分。特別是，它們可能會改變以太坊對 Keccak 和基于 RLP 的 Merkle-Patricia 樹，可能還會改變區塊和收據結構。類型 2 對 ZK-EVM 可能會使用不同的哈希函數，比如Poseidon。另一個自然修改是修改狀態樹以存儲代碼哈希和 keccak，從而無需驗證哈希來處理EXTCODEHASH和EXTCODECOPY操作碼。

這些修改顯著改善了證明者（prover）時間，但并不能解決所有問題。由于 EVM 固有的所有低效率和 ZK 不友好性，證明 EVM 的速度仍然很緩慢。一個簡單的例子是內存：因為一個MLOAD可以讀取任意 32 個字節，包括“未對齊”chunk 塊（開始和結束不是 32 的倍數），所以不能簡單地將一個MLOAD解釋為讀取一個塊；相反，它可能需要讀取兩個連續的塊并執行位操作來組合結果。

那誰在構建 類型 2 的 ZK-EVM 呢？

Scroll 的 ZK-EVM項目正朝著類型 2 的 ZK-EVM 方向發展，Polygon Hermez 也是如此。當然，這兩個項目都還沒有完成。特別是，很多更復雜的預編譯還沒有實現。因此，目前這兩個項目被歸類到 類型 3 的 ZK-EVM 會更好一些。

類型 2.5（EVM 等效，gas 成本除外）

顯著改善最壞情況證明者時間的一種方法，是大大增加 EVM 中很難進行 ZK 證明的特定操作的 gas 成本。這可能涉及到預編譯、KECCAK 操作碼，以及調用合約或訪問內存或存儲或恢復的可能特定模式。

更改 gas 成本可能會降低開發人員工具的兼容性，并破壞一些應用，但通常我們認為它比“更深入”的 EVM 更改風險更低。開發人員應該注意不要在一筆交易中要求超過一個區塊的 gas，永遠不要使用硬編碼的 gas 量進行調用（這已經是長期以來的一種標準建議）。

管理資源約束的另一種方法，是簡單地對每個操作可調用的次數設置硬限制。這在電路中更容易實現，但在 EVM 安全假設下的表現要差得多。我將這種方法稱為 類型 3 而不是 類型 2.5。

類型 3（幾乎等效于 EVM）

類型 3 的 ZK-EVM 幾乎等效于 EVM，但為了進一步改進證明者（prover）時間并使 EVM 更易于開發，需要在精確等效性上做出一些犧牲。

優點：易于構建，證明者（prover）時間更快

類型 3 的 ZK-EVM 可能會刪除一些在 ZK-EVM 實施中非常難以實現的特性，而預編譯通常位于該列表的頂部，此外，類型 3 的 ZK-EVM 有時在處理合約代碼、內存或堆棧方面也存在細微差別。

缺點：不兼容的地方會相對多一些

類型 3 ZK-EVM 的目標是與大多數應用兼容，而其余部分只需要最少的重寫工作。也就是說，有些應用需要重寫，因為它們使用了類型 3 ZK-EVM 刪除的預編譯，或者因為對 VM 不同處理的邊緣情況的微妙依賴。

那誰在構建類型 3 的 ZK-EVM？

Scroll 和 Polygon 在當前構建的 ZK-EVM 都是屬于類型 3，盡管它們有望隨著時間的推移提高兼容性。Polygon 有一個獨特的設計，他們對自己的內部語言zkASM 進行 ZK 驗證，并使用 zkASM 實現來解釋 ZK-EVM 代碼。盡管有這個實現細節，但我仍將其稱為真正的類型 3 ZK-EVM，它仍然可以驗證 EVM 代碼，它只是使用了一些不同的內部邏輯來完成它。

今天，沒有 ZK-EVM 團隊的目標是成為類型 3 的 ZK-EVM，類型 3 只是一個過渡階段，直到添加預編譯的復雜工作完成，然后項目就可以轉移到類型 2.5 的 ZK-EVM。然而，在未來，類型 1 或類型 2 的 ZK-EVM 可能會自動成為類型 3 的 ZK-EVM，方法是添加新的 ZK-SNARK 友好的預編譯，為開發人員提供低證明者（prover）時間和 gas 成本的功能。

類型 4（高級語言等效）

類型 4 系統的工作原理，是將用高級語言編寫的智能合約源代碼（例如 Solidity、Vyper 或中間語言）編譯為某種明確設計為 ZK-SNARK 友好的語言。

優點：非常快的證明者（prover）時間

通過不對每個 EVM 執行步驟的所有不同部分進行 ZK 證明，并直接從更高 level 的代碼開始，你可以避免大量開銷。

我在這篇文章中僅用一句話來描述類型 4 系統的這一優勢（與下面列出的與兼容性相關的缺點相比），但這不應該被解釋為一種價值判斷！直接從高級語言編譯，確實可以大大降低成本，并通過更容易成為證明者（prover）來幫助實現去中心化。

缺點：兼容性會更糟

用 Vyper 或 Solidity 編寫的“普通”應用可通過編譯“正常工作”，但有一些重要的方式使得很多應用無法“正常工作”。

1. 合約在類型 4 系統中的地址可能與 EVM 中的地址不同，因為 CREATE2 合約地址取決于確切的字節碼。這破壞了依賴尚未部署的“反事實合約”、ERC-4337 錢包、EIP-2470 單件和很多其他應用程序的應用。

2. 手寫的 EVM 字節碼更難使用，很多應用在某些部分會使用手寫 EVM 字節碼以提高效率。而類型 4 的系統可能不支持它，盡管有一些方法可以實現有限的 EVM 字節碼支持來滿足這些用例，而無需努力成為一個完整的類型 3 ZK-EVM。

3. 很多調試基礎設施無法兼容，因為這樣的基礎設施運行在 EVM 字節碼上。也就是說，通過從“傳統”高級或中間語言（例如 LLVM）更多地訪問調試基礎設施，可以緩解這一缺點。

開發人員應該注意這些問題。

那誰在構建類型 4 的系統？

ZKSync 就是一個類型 4 系統，盡管隨著時間的推移，它可能會增加對 EVM 字節碼的兼容性。Nethermind 的 Warp 項目正在構建一個從 Solidity 到 Starkware 的 Cairo 語言的編譯器，這將使 StarkNet 變成事實上的類型 4 系統。

ZK-EVM 類型的未來

本文并沒有明確判斷以上各種類型的 ZK-EVM 哪個“更好”或“更差”，相反，它們只是在不同的點上進行了權衡：編號較低的類型與現有基礎設施更兼容，但速度會較慢，而編號較高的類型與已有基礎設施不太兼容，但它們會更快。總的來說，所有類型 ZK-EVM 的探索都是有益的。

此外，ZK-EVM 項目可以很容易地從編號較高的類型開始，并隨著時間推移跳轉到編號較低的類型（反之亦然）。例如：

1. 一個 ZK-EVM 可以從類型 3 開始，它決定不包含一些特別難以 ZK 證明的功能。之后，他們可以隨著時間的推移添加這些功能，并轉向類型 2 的 ZK-EVM。

2. ZK-EVM 也可以從類型 2 開始，然后成為混合類型 2/類型 1 的 ZK-EVM，通過提供在完全以太坊兼容模式下運行的可能性，或者提供可以更快證明的修改狀態樹，比如 Scroll 正在考慮朝這個方向發展。

3. 通過添加處理 EVM 代碼的能力，從類型 4 開始的系統，可能會隨著時間的推移變成類型 3（盡管仍然鼓勵開發人員直接從高級語言編譯以減少費用和證明者時間）。

4. 如果以太坊本身采用修改以變得對 ZK 更加友好，則類型 2 或類型 3 的 ZK-EVM 可以成為類型 1 的 ZK-EVM。

5. 類型 1 或類型 2 的 ZK-EVM 可以通過添加預編譯來驗證 ZK-SNARK 友好語言中的代碼，從而成為類型 3 的 ZK-EVM。這將使開發人員在以太坊兼容性和速度之間做出選擇，而類型 3 就是這樣的選擇，因為它打破了完美的 EVM 等效性，但出于實際目的，它將具有類型 1 和類型 2 ZK-EVM 的很多好處。主要的缺點可能是某些開發人員工具無法理解 ZK-EVM 的自定義預編譯，盡管這可以修復：開發者工具可通過支持包含預編譯的 EVM 代碼等效實現的配置格式來添加通用預編譯支持。

就我個人而言，我希望隨著時間的推移，通過 ZK-EVM 的改進以及以太坊本身的改進（使其對 ZK-SNARK 更友好），讓一切都變成類型 1 的 ZK-EVM。在這樣的未來，我們將有多個 ZK-EVM 實現，它們既可以用于 ZK rollup，也可以用于驗證以太坊區塊鏈本身。從理論上講，以太坊不需要為 L1 使用在單個 ZK-EVM 實現上進行標準化。不同的客戶端可以使用不同的證明，因此我們繼續受益于代碼冗余。

然而，要實現這樣的一個未來，還需要相當長的時間。與此同時，我們將在擴展以太坊和基于以太坊的 ZK-rollup 的不同路徑上看到很多創新。