兼容性和速度哪個更重要？
注：原文作者是以太坊聯合創始人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 編寫的“普通”應用可通過編譯“正常工作”，但有一些重要的方式使得很多應用無法“正常工作”。
- 合約在類型4 系統中的地址可能與EVM 中的地址不同，因為CREATE2 合約地址取決於確切的字節碼。這破壞了依賴尚未部署的“反事實合約”、ERC-4337 錢包、EIP-2470 單件和很多其他應用程序的應用。
- 手寫的EVM 字節碼更難使用，很多應用在某些部分會使用手寫EVM 字節碼以提高效率。而類型4 的系統可能不支持它，儘管有一些方法可以實現有限的EVM 字節碼支持來滿足這些用例，而無需努力成為一個完整的類型3 ZK-EVM。
- 很多調試基礎設施無法兼容，因為這樣的基礎設施運行在EVM 字節碼上。也就是說，通過從“傳統”高級或中間語言（例如LLVM）更多地訪問調試基礎設施，可以緩解這一缺點。
開發人員應該注意這些問題。
那誰在構建類型4 的系統？
ZKSync 就是一個類型4 系統，儘管隨著時間的推移，它可能會增加對EVM 字節碼的兼容性。 Nethermind 的Warp 項目正在構建一個從Solidity 到Starkware 的Cairo 語言的編譯器，這將使StarkNet 變成事實上的類型4 系統。
ZK-EVM 類型的未來
本文並沒有明確判斷以上各種類型的ZK-EVM 哪個“更好”或“更差”，相反，它們只是在不同的點上進行了權衡：編號較低的類型與現有基礎設施更兼容，但速度會較慢，而編號較高的類型與已有基礎設施不太兼容，但它們會更快。總的來說，所有類型ZK-EVM 的探索都是有益的。
此外，ZK-EVM 項目可以很容易地從編號較高的類型開始，並隨著時間推移跳轉到編號較低的類型（反之亦然）。例如：
- 一個ZK-EVM 可以從類型3 開始，它決定不包含一些特別難以ZK 證明的功能。之後，他們可以隨著時間的推移添加這些功能，並轉向類型2 的ZK-EVM。
- ZK-EVM 也可以從類型2 開始，然後成為混合類型2/類型1 的ZK-EVM，通過提供在完全以太坊兼容模式下運行的可能性，或者提供可以更快證明的修改狀態樹，比如Scroll 正在考慮朝這個方向發展。
- 通過添加處理EVM 代碼的能力，從類型4 開始的系統，可能會隨著時間的推移變成類型3（儘管仍然鼓勵開發人員直接從高級語言編譯以減少費用和證明者時間）。
- 如果以太坊本身採用修改以變得對ZK 更加友好，則類型2 或類型3 的ZK-EVM 可以成為類型1 的ZK-EVM。
- 類型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 的不同路徑上看到很多創新。
展開全文打開碳鏈價值APP 查看更多精彩資訊
