以太坊創始人 Vitalik Buterin 最新的這篇文章將為你論述不同類型 ZK-EVM 的未來，並為當下 Zk 類項目進行歸類。

原文：The different types of ZK-EVMs

作者： Vitalik Buterin

編譯： Web3Caff

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

最近有許多 “ZK-EVM” 項目陸續高調發布了公告，Polygon 開源了他們的 ZK-EVM 項目，ZKSync 發布了他們的 ZKSync 2.0 計劃，而相對較新的 Scroll 最近也宣布了他們的 ZK-EVM。還有來自隱私和擴展解決方案研究團隊，Nicolas Liochon 等人團隊的持續努力，推出了從 EVM 到 Starkware 的 ZK 友好語言 Cairo 的 alpha 編譯器，當然至少還有其他一些我錯過的。

所有這些項目的核心目標都是一樣的：使用 ZK-SNARK 技術對類似以太坊交易的執行進行加密證明，或者使驗證以太坊鏈本身更容易，或者構建（或接近）以太坊但擴展性更強的 ZK-rollup。但這些項目之間存在著微妙的差異，以及他們在實用性和速度之間的權衡設計。這篇文章將試圖描述 EVM 等價的不同"類型"的分類法，以及試圖證明每種類型的好處和成本是什麼。

概覽（圖表形式）

Type 1（完全等效於以太坊）


Type 1 ZK-EVM 力求完全且毫不妥協地與以太坊等效。他們不改變以太坊系統的任何部分，使其更容易產生證明。它們不會取代哈希、狀態樹、事務樹、預編譯或任何其他共識邏輯，無論它有多麼邊緣化。

優勢：完美兼容

我們的目標是能夠如同現在一樣驗證以太坊區塊，或者至少驗證執行層方面（因此，信標鏈的共識邏輯不包括在內，但所有的交易執行和智能合約和賬戶邏輯都包括在內）。

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

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

弊端：證明時間

以太坊最初並不是圍繞 ZK 友好性設計的，所以以太坊協議的許多部分都需要大量的計算來進行 ZK 證明。Type1 的目標是完全複製以太坊，所以它沒有辦法減輕這些低效率的問題。目前，以太坊區塊的證明需要許多小時才能產生。這種情況可以通過巧妙的工程來大規模並行驗證，從來長遠來看可通過 ZK-SNARK ASIC 來緩解。

誰在構建？

隱私和擴展探索團隊 ZK -EVM 正在構建 Type 1 ZK-EVM。

Type 2（完全 EVM 等效）

Type 2 ZK-EVM 努力做到完全 EVM 等效，但不完全等同於以太坊。也就是說，它們"從內部"看起來與以太坊完全一樣，但它們在外部有一些差異，特別是在數據結構方面，如塊結構和狀態樹。

其目標是與現有的應用程序完全兼容，但對以太坊做一些小的修改，以使其開發更容易，並使更快生成證明。

優勢：VM 級別的完美等價

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

不過有少數例外。對於驗證歷史以太坊區塊的 Merkle 證明以驗證有關歷史交易、收據或狀態的聲明的應用程序出現了一種不兼容（例如，橋樑有時會這樣做）。用不同的哈希函數替換 Keccak 的 ZK-EVM 會破壞這些證明。但是，我通常建議不要以這種方式構建應用程序，因為未來的以太坊變化（如 Verkle 樹）將打破這樣的應用程序，甚至在以太坊本身。更好的選擇則是讓以太坊本身添加面向未來的歷史訪問預編譯。

弊端：改進驗證時間，但仍然很慢

Type 2 ZK-EVM 提供比 Type 1 更快的驗證器時間，主要是通過移除以太坊堆棧中依賴於不必要的複雜和 ZK 不友好的密碼學的部分。特別是，他們可能會改變以太坊的 Keccak 和基於 RLP 的 Merkle Patricia 樹，也許還有區塊和接收結構。Type 2 ZK-EVM 可能會改用不同的哈希函數，例如 Poseidon。另一種較為自然的修改是修改狀態樹以存儲代碼哈希和 keccak，進而消除驗證哈希的需要以處理 EXTCODEHASH 和 EXTCODECOPY 操作碼。

這些修改顯著提高了證明者的時間，但它們並不能解決所有問題。由於 EVM 固有的低效性和對 zk 的不友好性，因此證明 EVM 原樣的過程仍很緩慢。一個簡單的例子是內存：因為 MLOAD 可以讀取任何 32 個字節，包括 “未對齊” 塊（開始和結束不是 32 的倍數），所以不能簡單地將 MLOAD 解釋為讀取一個塊；相反，它可能需要讀取兩個連續的塊並執行位操作來合併結果。

誰在構建？

Scroll 的 ZK-EVM 項目正朝著 Type 2 ZK-EVM 方向發展，Polygon Hermez 也是如此。也就是說，這兩個項目都還沒有完成。特別是，許多更複雜的預編譯還沒有實現。因此，目前這兩個項目最好被認為是第三類。

Type 2.5（等同於 EVM，除 Gas 成本）

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

改變 gas 成本可能會降低開發者工具的兼容性，並破壞一些應用程序，但一般認為它比"更深層次"的 EVM 變化風險要小。開發者應該注意不要在一個事務中要求更多的氣體，不要用硬編碼的氣體量進行調用（這已經是對開發者的標準建議了很久）。

更改 gas 成本可能會降低開發人員工具的兼容性並破壞一些應用程序，但通常認為它比 “更深層次” 的 EVM 更改風險更小。開發人員應該注意，在交易中需要的 gas 費用不要超過區塊的容量，永遠不要使用硬編碼的 gas 量進行調用 (這已經是很長時間以來對開發人員的標準建議)。

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

Type 3（幾乎等效於 EVM）

Type 3 ZK-EVM 幾乎與 EVM 等效，但在精確等效性方面做出了一些犧牲，以進一步改善驗證器的時間，使 EVM 更容易開發。

優勢：更容易構建，更快的驗證時間

Type 3 ZK-EVM 可能會刪除一些在 ZK-EVM 實現中極難實現的功能。預編譯通常位於此處列表的頂部；此外，Type 3 ZK-EVM 有時在處理合約代碼、內存或堆棧方面也存在細微差別。

弊端：更多的不兼容性

Type 3 ZK-EVM 的目標是與大多數應用程序兼容，並且只需要對其餘的應用程序進行最小的重寫。也就是說，會有一些應用程序需要重寫，要么是因為它們使用了 Type 3 ZK-EVM 所刪除的預編譯，要么是因為對邊緣情況的微妙依賴，而虛擬機的處理方式不同。

誰在構建？

Scroll 和 Polygon 在目前的形式下都是 Type 3，儘管他們預計會隨著時間的推移提高兼容性。Polygon 有一個獨特的設計，他們對自己的內部語言 zkASM 進行 ZK 驗證，並使用 zkASM 實現來解釋 ZK-EVM 代碼。儘管有這樣的實現細節，我仍然會把它稱為真正的第三類 ZK-EVM；它仍然可以驗證 EVM 代碼，只是使用一些不同的內部邏輯來完成。

今天，沒有一個 ZK-EVM 團隊想成為第 3 類；第 3 類只是一個過渡階段，直到添加預編譯的複雜工作完成，項目可以轉移到第 2.5 類。然而，在未來，Type 1 或 Type 2 ZK-EVM 可能會自願成為 Type 3 ZK-EVM，通過添加新的對 ZK-SNARK 友好的預編譯，為開發者提供功能，並降低驗證器時間和 gas 成本。

Type 4（相當於高級語言）

Type 4 系統的工作原理是，將用高級語言（如 Solidity、Vyper 或一些兩者都能編譯的中間語言）編寫的智能合約源代碼，編譯成一些明確設計為 ZK-SNARK 友好的語言。

優勢：驗證器時間非常快

如果不對每個 EVM 執行步驟的所有不同部分進行 ZK 驗證，而直接從高級別的代碼開始，就可以避免大量的開銷。

在這篇文章中，我只用了一句話來描述這個優點（相比之下，下面有一個很大的與兼容性有關的缺點列表），但這不應該被解釋為一種價值判斷！直接從高級語言編譯確實可以大大降低成本，並通過使其更容易成為驗證者來幫助去中心化。

弊端：更多的不兼容性

一個用 Vyper 或 Solidity 編寫的"正常"的應用程序可以被編譯下來，它可以"正常工作"，但在一些重要的方面，很多應用程序都會不"正常"工作。

合約在 Type 4 系統中的地址可能與 EVM 中的地址不一樣，因為 CREATE2 合約地址取決於確切的字節碼。這打破了依賴尚未部署的"反事實合約"、ERC-4337 錢包、EIP-2470 單子和許多其他應用程序。

手寫的 EVM 字節碼更難使用。許多應用程序在某些部分使用手寫的 EVM 字節碼以提高效率。Type 4 系統可能不支持它，儘管有辦法實現有限的 EVM 字節碼支持來滿足這些用例，而不需要經過努力成為一個完整的 Type 3 ZK-EVM。

大量的調試基礎設施不能被帶過去，因為這些基礎設施在 EVM 字節碼上運行。也就是說，這個缺點被"傳統"高級語言或中間語言（如 LLVM）的調試基礎設施的更大訪問量所緩解。

開發者應注意這些問題。

誰在構建？

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

ZK-EVM 類型的未來

這些類型並不明確地比其他類型"更好"或"更差"。相反，它們是權衡空間的不同點：編號難度較小的類型與現有的基礎設施更兼容，但速度較慢，而編號難度較大的類型與現有的基礎設施不兼容，但速度較快。總的來說，所有這些類型都在探索，這對這個領域來說是健康的。

此外，ZK-EVM 項目可以很容易地從編號難度較大的類型開始，並隨著時間的推移跳到編號難度較小的類型（或相反）。例如：

  • ZK-EVM 可以從 Type 3 開始，決定不包括一些特別難於 ZK 證明的功能。之後，他們可以隨著時間的推移增加這些功能，並轉移到 Type 2
  • ZK-EVM 可以從 Type 2 開始，然後成為第 2 類/第 1 類 ZK-EVM 的混合體，通過提供在完全以太坊兼容模式下運行的可能性，或者使用可以更快地證明的修改後的狀態樹，Scroll 正在考慮往這個方向發展。
  • 從 Type 4 開始的系統隨著時間的推移，通過增加處理 EVM 代碼的能力，可能會變成 Type 3 系統，（為了減少費用和驗證器時間，因此鼓勵開發人員直接從高級語言編譯）。
  • 如果以太坊本身採用其修改以變得更加 ZK 友好，則 Type 2 或 Type 3 ZK-EVM 可以成為 Type 1 ZK-EVM。
  • Type 1 或 Type 2 ZK-EVM 可以通過添加預編譯來驗證 ZK-SNARK 友好語言中的代碼，從而成為 Type 3 ZK-EVM，這將使開發人員在以太坊兼容性和速度之間做出選擇。這將是 Type 3，因為它打破了完美的 EVM 等效性，但出於實際目的和目的，它將具有 Type 1 和 2 的很多好處。主要缺點可能是某些開發人員工具無法理解 ZK-EVM 的自定義預編譯，儘管這可以修復：開發人員工具可以通過支持包含預編譯的 EVM 代碼等效實現的配置格式來添加通用預編譯支持。

我個人希望，隨著時間的推移，通過對 ZK-EVM 的改進和對以太坊本身的改進，使其對 ZK-SNARK 更加友好，一切都會變成第一類（Type 1）。在這樣的未來，我們將有多個 ZK-EVM 實現，既可用於 ZK rollups，又可用於驗證以太坊鏈本身。理論上，以太坊沒有必要為 L1 使用的單一 ZK-EVM 實現進行標準化；不同的客戶可以使用不同的證明，所以我們繼續從代碼冗餘中受益。

然而，在我們達到這樣的未來之前，還需要相當長的時間。在此期間，我們將看到在擴展以太坊和基於以太坊的 ZK-rollup 的不同路徑上有很多創新。

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。