聽V神解讀不同類型ZK-EVM的未來

原文標題：《The different types of ZK-EVMs》

原文來源：Vitalik Buterin 個人首頁

原文作者：Vitalik Buterin

原文作者：Vitalik Buterin

原文編譯：Block unicorn

最近有許多“ZK-EVM”項目高調發佈公告。 Polygon 開放了他們的 ZK-EVM 項目，ZKSync 發布了他們的 ZKSync 2.0 計劃，相對較新的 Scroll 最近也發布了他們的 ZK-EVM。還有來自隱私和拓展探索的團隊、Nicolas Liochon 等人的團隊的持續努力，從 EVM 到 Starkware 的 zk 友好語言 Cairo 的 alpha 編譯器，當然有一些項目我會錯過。

所有這些項目的核心目標都是相同的：使用ZK-SNARK 技術來對類似以太坊的交易執行進行加密證明，要麼讓驗證以太坊鏈本身變得更容易，要麼建立與以太坊提供的內容(接近) 相同但可擴展性更強的zk rollup。 但這些項目之間存在著微妙的差異，以及它們在實用性和速度之間的權衡。這篇文章將嘗試描述 EVM 等價性的不同「類型」的分類，以及嘗試實現每種類型的好處和成本。

概述(圖表形式)

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

類型1 ZK - EVM 力求完全且不妥協的等值於以太坊。它們不會改變以太坊系統的任何部分，以使生成證明更容易。它們不會取代哈希、狀態樹、事務樹、預編譯或任何其他共識邏輯，無論它有多外圍。

優點:完美的相容性

我們的目標是能夠像現在一樣驗證以太坊區塊，或至少驗證執行層(因此，信標鏈共識邏輯不包括在內，但包括所有的交易執行和智能合約和帳戶邏輯)。

類型 1 ZK-EVM 是我們最終需要的，使乙太網路第 1 層本身更具可擴展性。從長遠來看，在類型 2 或類型 3 ZK-EVM 中測試出的對以太的修改可能會被引入到以太本身，但這樣的重新設計伴隨著它自己的複雜性。

類型 1 ZK-EVM 也是匯總的理想選擇，因為它們允許匯總重複使用大量基礎設施。例如，Etherum Execution 用戶端可以按原樣使用來產生和處理ROLLUP 區塊(或至少，一旦實現提取，它們就可以重新使用，並且該功能可以被重複使用以支援存放到ROLLUP 中的ETH)，因此區塊資源管理器、區塊生產等工具非常容易重複使用。

劣勢: 驗證時間

以太坊最初並不是圍繞zk 友善性設計的，所以以太坊協議的許多部分需要進行大量的計算來驗證zk。類型 1 的目標是完全複製以太坊，所以它沒有辦法緩解這些低效率。目前，以太坊區塊的證明需要許多小時來產生。這種情況可以透過巧妙的工程來大規模並行化驗證器，或者從長遠來看，可以透過 ZK-SNARK 專用積體電路來緩解。

建構者是誰?

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

類型2 (完全等效EVM)

類型2 ZK - EVM 力求完全等價於EVM，但不完全等價於以太坊。 也就是說，它們「從內部」看起來完全像以太坊，但它們在外部有一些不同，特別是在資料結構上，如區塊結構和狀態樹。

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

優點：在虛擬機器層級實現完全對等

類型2 ZK-EVM 對保存以太狀態等內容的資料結構進行變更。幸運的是，這些結構是 EVM 本身無法直接存取的，因此在 Etherum 上工作的應用程式幾乎總是在類型 2 ZK-EVM 匯總上工作。您將無法按原樣使用 Etherum Execution 用戶端，但您可以透過一些修改使用它們，並且您仍然可以使用 EVM 偵錯工具和大多數其他開發人員基礎架構。

但也有少數例外。對於驗證歷史以太塊的 Merkle 證明以驗證關於歷史交易、收據或狀態的聲明的應用程序，出現了一種不兼容性 (例如，橋樑有時會這樣做)。用不同的雜湊函數取代 Keccak 的 ZK-EVM 將打破這些證明。然而，我通常建議不要以這種方式構建應用程序，因為未來的以太更改 (例如。Verkle Trees) 甚至在以太本身上也會破壞這樣的應用。對以太坊本身來說，一個更好的替代方案是添加未來可靠的歷史存取預編譯。

缺點：改進了驗證時間，但仍然很慢

類型2 ZK-EVM 提供比類型1 更快的驗證時間，主要是透過移除依賴不必要的複雜和不友善的ZK 加密的以太堆疊的部分。特別是，它們可能會改變 Etherum 的 Keccak 和基於 RLP 的 Merkle Patricia 樹，可能還會改變區塊和接收結構。類型 2 ZK-EVM 可能會使用不同的雜湊函數，例如，Poseidon。另一個自然的修改是修改狀態樹以儲存程式碼雜湊和 keccak，從而不再需要驗證雜湊來處理 EXTCODEHASH 和 EXTCODECOPY 操作碼。

這些修改顯著提高了驗證時間，但它們不能解決所有問題。由於 EVM 固有的低效性和對 zk 的不友善性，證明 EVM 原樣的過程仍然緩慢。一個簡單的例子是記憶體:因為MLOAD 可以讀取任何32 字節，包括「未對齊」的區塊(其中開始和結束不是32 的倍數)，MLOAD 不能簡單地解釋為讀取一個區塊;相反，它可能需要讀取兩個連續的區塊，並執行位元操作來合併結果。

建構者是誰？

Scroll 的 ZK-EVM 專案正朝著 2 型 ZK-EVM 的方向發展，正如 Polygon Hermez 一樣。也就是說，這兩個專案都還沒有完成（沒有完成 ZKEVM 工作）;特別是，許多更複雜的預編譯還沒有實現。因此，目前兩個項目都最好考慮類型 3。

2.5 類型(與evm 相當，不包括gas 費用)

顯著改善最壞情況驗證時間的一種方法是大幅增加EVM 中很難證明的特定操作的費用成本。這可能涉及預編譯、KECCAK 操作碼，也可能涉及呼叫約定或存取記憶體、儲存或復原的特定模式。

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

類型3 (幾乎等同於EVM)

第3 型zk -EVM 幾乎同等於EVM，但為了實現完全相同，需要做出一些犧牲，以進一步提高驗證時間並使EVM 更容易開發。

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

類型3 ZK-EVM 可能會刪除一些在ZK-EVM 實作中特別難實現的功能。在這裡，預編譯通常位於列表的頂部；此外，類型 3 ZK-EVM 在處理合約程式碼、記憶體或堆疊的方式上有時也有細微的差異。

缺點：更多的不相容

類型3 ZK-EVM 的目標是與大多數應用程式相容，其餘部分只需要最少的重寫。也就是說，有些應用程式需要重寫，要么是因為它們使用了類型3 ZK-EVM 刪除的預編譯，要么是因為對邊緣情況的微妙依賴，而這些邊緣情況是由EVM 以不同的方式處理的。

建構者是誰？

Scroll 和 Polygon 目前形式都是類型 3，儘管隨著時間的推移，他們有望改善相容性。 Polygon 有一個獨特的設計，他們用 ZK 驗證自己的內部語言 zkASM，並使用 zkASM 實作解釋 ZK-EVM 程式碼。儘管有這樣的實作細節，我仍然稱之為真正的 Type3ZK-EVM；它仍然可以驗證 EVM 程式碼，只是使用了一些不同的內部邏輯來完成。

今天，沒有ZK-EVM 團隊想要成為類型3；類型3 只是一個過渡階段，直到添加預編譯的複雜工作完成，專案可以轉移到類型2.5。然而，在未來，類型 1 或類型 2 ZK-EVM 可能會自願成為類型 3 ZK-EVM，方法是添加新的 ZK-SNARK 友善預編譯器，為開發人員提供低驗證時間和 gas 費用成本的功能。

類型4 (相當於高階語言)

類型4 系統的工作方式是採用用高級語言編寫的智能合約原始碼(例如，SOLIDITY、VYPER 或某種兩者都編譯為的中間語言)，並將其編譯成某種明確設計為ZK-snark 友善的語言。

優點:驗證時間非常快速

透過不使用ZK 來證明每個EVM 執行步驟的所有不同部分，並直接從更高層級的程式碼開始，可以避免很多開銷。

我在這篇文章中只用一句話描述了這一優點(與下面與兼容性相關的缺點的大項目符號列表比較)，但這不應被解釋為價值判斷！直接從高級語言編譯確實可以極大地降低成本，並通過使其更容易成為證明者來幫助分散。

缺點：更多的不相容

一個用Vyper 或Solidity 編寫的“正常”應用程式可以被編譯下來，它會“正常工作”，但有一些重要的方面，很多應用程式不是“正常工作」的:

1. 合約在類型 4 系統中的位址可能不同於它們在 EVM 中的位址，因為 CREATE2 協定位址取決於確切的字節碼。這打破了依賴尚未部署的「反事實合約」、ERC-4337 錢包、EIP-2470 單例和許多其他應用程式的應用程式。

2. 手寫的 EVM 字節碼更難使用。為了提高效率，許多應用程式在某些部分使用手寫 EVM 字節碼。類型 4 系統可能不支援它，儘管有一些方法可以實現有限的 EVM 位元組支援來滿足這些用例，而不需要努力成為完整的 Type3ZK-EVM。

3. 許多調試基礎設施不能繼續，因為這些基礎設施運行在EVM 字節碼上。也就是說，透過更多地從「傳統」高階或中間語言存取偵錯基礎設施，這一缺點得到了緩解 (例如，LLVM)。

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

建構者是誰？

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

ZK-EVM 類型的未來

這些類型並不是明確地比其他類型「更好」或「更差」。相反，它們在權衡空間上是不同的點：編碼難度較低的類型與現有基礎設施更相容，但速度較慢；編碼難度較高的類型與現有基礎設施不太相容，但速度更快。總體而言，所有這些類型的人都在探索，這對這個領域是健康的。

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

2.ZK-EVM 可以從型2 開始，然後透過提供在全以太相容模式下運轉或使用可以更快證明的經修改的狀態樹的可能性而變成混合型2/類型1 ZK-EVM。 Sroll 正在考慮朝這個方向發展。

3. 從類型4 開始的系統可能會隨著時間的推移而變成類型3，因為後來增加了處理EVM 程式碼的能力(儘管仍鼓勵開發人員直接從高級語言編譯，以減少費用和驗證時間)。

4. 如果Etherum 本身採用其修改以努力變得對ZK 更友好，則類型2 或類型3 ZK-EVM 可以成為類型1 ZK-EVM。

5. 類型1 或類型2 的ZK-EVM 可以透過新增預編譯器來驗證ZK-SNARK 友善語言中的代碼，從而成為類型3 ZK-EVM。這將讓開發人員在以太相容性和速度之間做出選擇，這將是類型3，因為它打破了完美EVM 的同等性，但從實際目的和目的來看，它將具有類型1 和類型2的許多好處。主要缺點可能是一些開發人員工具不理解 ZK-EVM 的自訂預編譯，儘管這是可以修復的：開發人員工具可以透過支援包括預編譯的 EVM 程式碼等價實現的配置格式來添加通用預編譯支援。

就我個人而言，我希望隨著時間的推移，所有的東西都會變成類型1，透過改進ZK-EVM 和改進以太坊本身來使其更適合ZK-Snark。 在這樣的未來，我們將有多個 ZK-EVM 實現，既可以用於 ZK 匯總，也可以用於驗證以太鏈本身。從理論上講，以太坊沒有必要為 L1 使用的單一 ZK-EVM 實作進行標準化；不同的客戶端可以使用不同的證明，因此我們繼續受益於程式碼冗餘。

然而，我們需要相當長的時間才能達到這樣的未來。同時，我們將在擴展以太坊和基於以太坊的 ZK-匯總的不同途徑上看到許多創新。

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia