文/Vitalik
感謝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的ZK友好語言Cairo的alpha編譯器，當然還有一些我不知道。
所有這些項目的核心目標都是相同的：使用ZK-SNARK技術來製作類似以太坊交易執行的加密證明，或者更容易驗證以太坊鏈本身，或者構建（接近）相當於以太坊提供的，但更具可擴展性的ZK-rollup。但是這些項目之間存在細微的差異，以及它們在實用性和速度之間做出的權衡。
這篇文章將嘗試分類不同“類型”ZK-EVM的EVM等效性，以及嘗試實現每種類型的好處和成本。
概覽（圖表形式）
類型1（完全等效於以太坊）
1型ZK-EVM力求完全且毫不妥協地與以太坊等效。他們不會改變以太坊系統的任何部分來更容易生成證明。它們不會取代哈希、狀態樹、交易樹、預編譯或任何其他共識邏輯，無論多麼外圍。
優點：完美兼容
其目標是能夠像今天一樣驗證以太坊區塊，或者至少驗證執行層端（因此，不包括信標鏈共識邏輯，但包括所有交易執行以及智能合約和賬戶邏輯） .
1型ZK-EVM是我們最終需要的，使以太坊第1層本身更具可擴展性。從長遠來看，在2型或3型ZK-EVM中測試的對以太坊的修改可能會被引入到以太坊本身，但這種重新架構也有其自身的複雜性。
1型ZK-EVM也是Rollup的理想選擇，因為它們允許Rollup重用大量基礎架構。例如，以太坊執行客戶端可以按原樣使用來生成和處理rollup區塊（或者至少，它們可以在實現提款後使用，並且可以重新使用該功能來支持將ETH存入rollup中），因此工具例如區塊瀏覽器、區塊生產等非常容易重用。
缺點：證明時間
以太坊最初並不是圍繞ZK友好性設計的，因此以太坊協議的許多部分需要大量計算才能進行ZK證明。 1型ZK-EVM旨在精確複製以太坊，因此它無法緩解這些低效率。目前，以太坊區塊的證明需要很多小時才能產生。這可以通過巧妙的大規模並行化證明者工程或從長遠來看通過ZK-SNARK ASIC來緩解。
誰在建造它？
Privacy and Scaling Explorations團隊ZK -EVM正在構建1型ZK-EVM。
類型2（完全等效於EVM）
類型2 ZK-EVM力求完全等同於EVM，但不完全等同於以太坊。也就是說，它們“從內部”看起來與以太坊一模一樣，但它們在外部存在一些差異，特別是在區塊結構和狀態樹等數據結構方面。
目標是與現有應用程序完全兼容，但對以太坊進行一些小的修改，以使開發更容易並更快地生成證明。
優點：VM級別的完美等效
2型ZK-EVM對保存諸如以太坊狀態之類的數據結構進行更改。幸運的是，這些是EVM本身無法直接訪問的結構，因此在以太坊上運行的應用程序幾乎總是可以在2型ZK-EVM Rollup上運行。你將無法按原樣使用以太坊執行客戶端，但可以通過一些修改來使用它們，並且仍然可以使用EVM調試工具和大多數其他開發人員基礎設施。
有少數例外。對於驗證以太坊歷史區塊的Merkle證明以驗證有關歷史交易、收據或狀態的聲明的應用程序出現了一種不兼容（例如，橋有時會這樣做）。用不同的哈希函數替換Keccak的ZK-EVM會破壞這些證明。但是，我通常建議不要以這種方式構建應用程序，因為未來的以太坊更改（例如Verkle樹）甚至會在以太坊本身上破壞此類應用程序。更好的選擇是讓以太坊本身添加面向未來的歷史訪問預編譯。
缺點：改進但仍然很慢證明時間
2型ZK-EVM提供比1型更快的證明時間，主要是通過刪除依賴於不必要的複雜和ZK不友好密碼學部分的以太坊堆棧。特別是，他們可能會改變以太坊的Keccak和基於RLP的Merkle Patricia 樹，可能還會改變區塊和收據結構。 2型ZK-EVM可能會使用不同的哈希函數，例如Poseidon。另一個自然的修改是修改狀態樹以存儲代碼哈希和keccak，從而無需驗證哈希來處理EXTCODEHASH和EXTCODECOPY操作碼。
這些修改顯著提高了證明者的時間，但它們並不能解決所有問題。必須按原樣證明EVM的緩慢性以及EVM固有的所有低效率和ZK不友好性仍然存在。一個簡單的例子是內存：因為anMLOAD可以讀取任何32個字節，包括“未對齊”的區塊（開始和結束不是32的倍數），所以不能簡單地將MLOAD解釋為讀取一個區塊；相反，它可能需要讀取兩個連續的區塊並執行位操作來組合結果。
誰在建造它？
Scroll的ZK-EVM項目正朝著Type 2 ZK-EVM方向發展，Polygon Hermez也是如此。也就是說，這兩個項目都還沒有完成。特別是，許多更複雜的預編譯還沒有實現。因此，目前這兩個項目都被更好地考慮為Type 3。
類型2.5 （EVM等效，gas成本除外）
顯著改善證明者時間最壞情況的一種方法是大大增加EVM中很難進行ZK證明的特定操作的gas成本。這可能涉及預編譯、KECCAK操作碼，以及調用合約或訪問內存或存儲或恢復的可能特定模式。
更改gas成本可能會降低開發人員工具的兼容性並破壞一些應用程序，但通常認為它比“更深”的EVM更改風險更小。開發人員應該注意不要在交易中超過一個區塊容量的gas，永遠不要使用硬編碼的gas量進行調用（這已經是開發人員很長時間以來的標準建議）。
管理資源約束的另一種方法是簡單地對每個操作可以調用的次數設置硬限制。這在電路中更容易實現，但在EVM安全假設下的表現要差得多。我將這種方法稱為Type 3而不是Type 2.5。
類型3（幾乎等效於EVM）
3型ZK-EVM幾乎與EVM等效，但在精確等效性方面做出了一些犧牲，以進一步縮短驗證者時間並使EVM更易於開發。
優勢：更容易建設，更快的驗證時間
3型ZK-EVM可能會刪除一些在ZK-EVM實現中極難實現的功能。預編譯通常位於此處列表的頂部。此外，3型ZK-EVM有時在處理合約代碼、內存或堆棧方面也存在細微差別。
缺點：不兼容較多
3型ZK-EVM的目標是與大多數應用程序兼容，並且只需要對其餘部分進行最少的重寫。也就是說，將有一些應用程序需要重寫，因為它們使用3型ZK-EVM刪除的預編譯，或者因為對VM 不同處理的邊緣情況的微妙依賴。
誰在建造它？
Scroll和Polygon在其當前形式中都是3型ZK-EVM，儘管它們有望隨著時間的推移提高兼容性。 Polygon有一個獨特的設計，他們正在ZK驗證他們自己的稱為zkASM的內部語言，並且他們使用zkASM實現來解釋ZK-EVM代碼。儘管有這個實現細節，但我仍將其稱為真正的Type 3 ZK-EVM；它仍然可以驗證EVM代碼，它只是使用一些不同的內部邏輯來完成它。
今天，沒有ZK-EVM團隊想成為Type 3；Type 3只是一個過渡階段，直到完成添加預編譯的複雜工作並且項目可以移動到Type 2.5。然而，在未來，Type 1或Type 2 ZK-EVM可能會自願成為Type 3 ZK-EVM，方法是添加新的ZK-SNARK友好型預編譯，為開發人員提供低驗證時間和gas成本的功能。
類型4（高級語言等效）
4型ZK-EVM系統通過獲取以高級語言（例如Solidity、Vyper或兩者都編譯到的中間體）編寫的智能合約源代碼並將其編譯為明確設計為ZK-SNARK友好的某種語言來工作。
優勢：非常快的驗證時間
通過不對每個EVM執行步驟的所有不同部分進行ZK證明，並且直接從更高級別的代碼開始，可以避免很多開銷。
我只是在這篇文章中用一句話描述了這一優勢（與下面的一個大項目符號列表相比，兼容性相關的劣勢），但這不應該被解釋為價值判斷！直接從高級語言編譯確實可以大大降低成本並通過更容易成為證明者來幫助去中心化。
缺點：不兼容較多
一個用Vyper或Solidity編寫的“正常”應用程序可以被編譯下來，它會“正常工作”，但有一些重要的方式使很多應用程序不“正常”：
-
合約在4型ZK-EVM系統中的地址可能與它們在EVM中的地址不同，因為CREATE2合約地址取決於確切的字節碼。這破壞了依賴尚未部署的“反事實合約”（ counterfactual contracts）、ERC-4337 錢包、EIP-2470 singletons和許多其他應用程序的應用程序。
-
手寫的EVM字節碼（Handwritten EVM bytecode）更難使用。許多應用程序在某些部分使用手寫EVM字節碼以提高效率。 4型ZK-EVM系統可能不支持它，儘管有一些方法可以實現有限的EVM字節碼支持來滿足這些用例，而無需努力成為一個完整的3型ZK-EVM。
-
很多調試基礎設施不能被繼承，因為這樣的基礎設施運行在EVM字節碼上。也就是說，通過從“傳統”高級或中級語言（例如LLVM）更多地訪問調試基礎架構，可以緩解這一缺點。
開發人員應該注意這些問題。
誰在建造它？
ZKSync是一個4型ZK-EVM系統，儘管隨著時間的推移它可能會增加對EVM字節碼的兼容性。 Nethermind的Warp項目正在構建一個從Solidity到Starkware的Cairo的編譯器，它將把StarkNet變成事實上的4型ZK-EVM系統。
ZK-EVM類型的未來
一些類型並不比其他類型明確地“更好”或“更差”。相反，它們權衡空間上的不同點：編號較小的類型與現有基礎架構的兼容性更高，但速度較慢，編號較高的類型與現有基礎架構的兼容性較差，但速度更快。一般來說，探索所有這些類型的空間是健康的。
此外，ZK-EVM項目可以輕鬆地從較高編號的類型開始，並隨著時間的推移跳轉到較低編號的類型（反之亦然）。例如：
ZK-EVM可以從類型3開始，決定不包含一些特別難以ZK證明的功能。之後，他們可以隨著時間的推移添加這些功能，並轉向類型2。
ZK-EVM可以從類型2開始，後來成為混合類型2/類型1的ZK-EVM，通過提供在完全以太坊兼容模式下運行的可能性或使用可以更快證明的修改狀態樹的可能性。 Scroll正在考慮朝這個方向發展
通過添加處理EVM代碼的能力，從類型4開始的系統可能會隨著時間的推移變成類型3（儘管仍然鼓勵開發人員直接從高級語言編譯以減少費用和驗證時間）
如果以太坊本身採用其修改以變得更加ZK友好，那麼類型2或類型3ZK-EVM可以成為類型1 ZK-EVM。
1型或2型ZK-EVM可以通過添加預編譯來驗證ZK-SNARK友好語言中的代碼，從而成為3型ZK-EVM。這將使開發人員在以太坊兼容性和速度之間做出選擇。這將是類型3，因為它打破了完美的EVM等效性，但出於實際目的和目的，它將具有類型1和2的很多好處。主要缺點可能是某些開發人員工具無法理解ZK-EVM的自定義預編譯，儘管這可以修復：開發人員工具可以通過支持包含預編譯的EVM代碼等效實現的配置格式來添加通用預編譯支持。
就我個人而言，我希望隨著時間的推移，通過ZK-EVM的改進和以太坊本身的改進相結合，使其對ZK-SNARK更加友好，一切都將成為類型1。在這樣的未來，我們將有多個ZK-EVM實現，它們既可用於ZK Rollup，也可用於驗證以太坊鏈本身。從理論上講，以太坊不需要為L1 使用單一的ZK-EVM實現進行標準化；不同的客戶端可以使用不同的證明，因此我們繼續從代碼冗餘中受益。
但是，要實現這樣的未來，還需要相當長的時間。與此同時，我們將在擴展以太坊和基於以太坊的ZK-rollup的不同路徑中看到許多創新。
