以太坊:Vitalik：不同類型的 ZK-EVM

特別感謝 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 et al 的團隊，以及 Nethermind 團隊致力于將 EVM 的 Solidity 語言轉譯為 StarkWare 的 ZK 友好語言 Cairo 的一個 Alpha 編譯器，這些團隊都在為此不斷努力，當然，還有一些項目我沒有例舉出來。

這些項目的核心目標是一致的：利用 ZK-SNARK 技術對以太坊類交易的執行生成加密證明，不是讓證明更易于驗證以太坊鏈本身，就是構建（接近）相當于以太坊所提供的一些功能，但比它更具有可擴展性的 ZK-rollups。但這些項目之間也有些細微區別，并且他們在實用性和速度之間所做的權衡也有差異。這篇文章將描述不同 EVM 等效“類型”的分類學，以及每種類型的優勢和開銷。

概覽（圖表形式）

類型 1：完全以太坊等效的 ZK-EVM

第一類 ZK-EVM 力圖成為完全不妥協的以太坊等效 ZK-EVM 。他們不會更改以太坊系統的任何部分來讓它更容易生成證明：不會替換哈希、狀態樹、交易樹、預編譯或是共識中的其他邏輯，不管這些部分多么次要。

Vitalik：跨鏈證明是實現跨鏈社交恢復錢包的關鍵，ZK-SNARK等是可行選擇:6月20日消息，以太坊聯合創始人VitalikButerin在最新文章《更深入探討錢包和其他用例的跨L2讀取》中指出，實現跨鏈社交恢復錢包的一個可行方案是維護一個存放在特定位置的密鑰庫，以及多個不同位置的錢包，這些錢包可以讀取密鑰庫來更新自身的驗證密鑰視圖或在每次交易驗證過程中。跨鏈證明是實現這個功能的關鍵，需要對其進行深度優化，可能的方案包括零知識證明（ZK-SNARK）、等待Verkle證明或自定義KZG解決方案。

從長遠看，我們需要實現聚合協議，通過生成聚合證明來打包所有用戶提交的操作，以此來降低成本。這可能需要將其集成到ERC-4337生態系統中，可能需要對ERC-4337進行一些修改。同時，為了減少從L2內部讀取L1狀態的延遲，L2應被優化。

錢包不只可以放在L2上，也可以放在與以太坊連接程度較低的系統上，如L3或只同意包含以太坊狀態根的獨立鏈。然而，密鑰庫應放在L1或高安全性的ZK-rollupL2上。盡管這樣會增加復雜性，但從長期來看，可能在L2上設置密鑰庫才是成本更低的方案。在這個過程中，我們也需要致力于提供保護隱私的解決方案，并確保我們的方案可以與隱私保護方案兼容。[2023/6/21 21:50:47]

優勢：完美的兼容性

ZK-EVM 的目標在于，能夠像目前以太坊驗證區塊那樣 —— 或者至少，驗證執行層上面的區塊（因此，雖然信標鏈的共識邏輯沒有囊括進來，但是所有執行的交易、智能合約和賬戶邏輯都包含在內）。

第一類的 ZK-EVM 正是我們最終所需要的，能讓以太坊 L1 本身更具有可擴展性。長期來看，在第二類和第三類的 ZK-EVM 中試驗得出的對以太坊的修改，可能會被合理引入至以太坊上，但是這種重新架構本身具有復雜性。

Celestia：Quantum Gravity Bridge初期版本已上線Blockspace Race測試網:5月12日消息，模塊化區塊鏈網絡Celestia發推表示，Quantum Gravity Bridge的初期版本已于本周在Blockspace Race測試網上線，相應的合約已部署在以太坊Sepolia測試網上。

Quantum Gravity Bridge是一個從Celestia到以太坊的數據可用性（DA）橋接。Celestia使用Celestium作為可擴展的鏈下數據可用性 （DA） 解決方案為以太坊Rollup團隊提供服務。[2023/5/12 14:59:10]

第一類 ZK-EVM 對 Rollup 來說也是理想的，因為它們讓 Rollup 可以重復利用基礎設施。比如，以太坊執行層客戶端可以像原來那樣生成和處理 Rollup 的區塊（至少，一旦實現提款功能，它們可以重新使用該功能來支持 ETH 存入 Rollup），所以區塊瀏覽器、區塊生成等工具可以輕松重新使用。

劣勢：證明生成時間慢

以太坊原本的設計并不是 ZK 友好的，因此，以太坊協議中的許多部分都需要花費大量的計算來生成 ZK 證明。第一類 ZK-EVM 旨在完全復制以太坊的環境，因此，它無法緩解這些計算低效性問題。目前，以太坊區塊證明需要花費多個小時才能生成。這可以通過巧妙的工程（如大規模并行生成證明），或從長遠來看，通過 ZK-SNARK ASIC 來緩解低效性問題。

誰在構建第一類 ZK-EVM？

Privacy and Scaling Explorations 團隊正在努力構建第一類 ZK-EVM。

類型 2：完全 EVM 等效的 ZK-EVM

第二類 ZK-EVM 力爭成為完全 EVM 等效但也不那么以太坊等效的 ZK-EVM。也就是說，“從內部來看”，他們完全就像以太坊一樣，但是在外部與以太坊有一些區別，尤其是區塊結構和狀態樹等數據結構。

歐洲電競組織Team Vitality與Tezos達成技術合作伙伴關系:金色財經報道，歐洲電子競技和游戲組織Team Vitality宣布與Tezos達成為期三年的技術合作伙伴關系。雙方將共同努力，為其社區提供與明星玩家互動的新方式。Team Vitality將與Tezos生態系統合作，教育粉絲了解區塊鏈作為游戲體驗的一部分的好處，并促進該技術的進步。[2022/1/7 8:30:53]

它的目標在于，與現有的應用完全兼容，但它會對以太坊做一些較小的修改，讓開發更容易，也讓證明生成得更快。

優勢：在虛擬機層面完全等效

第二類 ZK-EVM 會改變存儲著如以太坊狀態的數據結構。幸運的是，因為 EVM 本身就不能直接訪問這些數據結構，所以對原本在以太坊上運行的應用程序沒什么影響，它們仍能在第二類的 ZK-EVM rollup 上運行。你可能無法像原來那樣使用以太坊執行層客戶端，但你可以通過一些修改來使用客戶端，并且依舊能使用 EVM 調試工具和大部分其他開發者基礎設施。

還存在少數例外情況。當驗證以太坊歷史區塊的默克爾樹證明來驗證歷史交易、收據或狀態的聲明（比如，橋接有時候也會這么做）時，應用程序出現了不兼容。如果 ZK-EVM 用不同的哈希函數來替換 Keccak，那就會損壞這些證明。而且，我經常建議不要這樣構建應用程序，因為未來的以太坊更新（如 Verkle tree）甚至會影響以太坊上的應用。更好的選擇是以太坊自己添加不會過時的 (future-proof) 歷史訪問預編譯。

劣勢：已經改進過了但還是證明時間太慢

第二類 ZK-EVM 能比第一類提供更快的證明生成時間，它主要通過移除部分以太坊堆棧，這部分堆棧依賴于具有不必要復雜性和 ZK 不友好的加密學。特別是，這些堆棧可能會更改以太坊的 Keccak 和基于 RPL 的 Merkle patricia tree，也許還會更改區塊和收據結構。第二類 ZK-EVM 則是會使用不同的哈希函數，如 Poseidon。自然而然地，它會修改狀態樹以儲存哈希碼和 Keccak，不需要驗證哈希以處理 EXTCODEHASH 和 EXTCODECOPY 操作碼。

VitalikButerin提議使用Flashbots系統實現“賬戶抽象”:3月11日消息，以太坊聯合創始人 Vitalik Buterin 在研究機構 Flashbots 的 GitHub 倉庫中提議利用 Flashbots 作為“賬戶抽象”的一種實現方式。“賬戶抽象”是以太坊社區中討論的改進提案之一，以實現交易不需要從私鑰控制的 EOA 賬戶發起，而是可以直接從智能合約發起，具體的用例包括智能合約錢包、Tornado.Cash 這類隱私保護工具等。Vitalik Buterin 認為 Flashbots 可以解決這個問題，通過搭建一個插件將其變成智能合約錢包的中繼器以實現。他表示該方案不需要對以太坊底層協議進行很多改動。

Flashbots是由五位區塊鏈行業人士發起成立的開放研究機構，旨在針對以太坊及各智能合約公鏈所面對的 MEV 問題進行研究，并實施解決方案。[2021/3/11 18:35:51]

這些修改極大地改善了證明生成的時間，但它們沒有解決所有問題。這類 ZK-EVM 繼承了 EVM 本身帶來的低效性和 ZK 不友好問題，所以像原本那樣基于 EVM 生成證明的低效情況依然存在。內存就是最簡單的例子：因為  MLOAD 可以讀取任何 32 字節，包括“無序的”代碼段（其開頭和結尾都不是 32 的倍數）， MLOAD 也不能單純理解為對一段代碼的讀取；確切地說，它可能需要讀取兩個連續的代碼段和執行位操作來結合運行結果。

誰在構建第二類 ZK-EVM？

Scroll 的 ZK-EVM 項目正在構建第二類 ZK-EVM，Polygon Hermez 也是。即使如此，還沒有項目真的成為第二類 ZK-EVM；尤其是很多更加復雜的預編譯還沒實現。所以，目前來說，這兩個項目應該說屬于第三類 ZK-EVM。

類型 2.5：EVM 等效，除了 gas 開銷

聲音 | Vitalik Buterin：可伸縮性、隱私性和可用性是以太坊的三大發展重點:據Invest In Blockchain消息，以太坊聯合創始人Vitalik Buterin在與Abra首席執行官Bill Barhydt交流時分享了以太坊的三大發展重點：可伸縮性、隱私性以及可用性。其表示，以太坊網絡需要每秒處理100,000筆交易才能成為未來可行的平臺。此外，Vitalik Buterin還表達自己對比特幣作為一種價值儲存手段將如何發揮作用的看法，其認為如果比特幣的意圖是充當一種貨幣，那么轉向“權益證明”（Proof-of-Stake）會更好。[2019/3/21]

在最糟糕的情況下，有一種能夠極大地改善證明生成時間慢的方式是，大大提高那些難以在 EVM 中生成 ZK 證明的執行所花的 gas 開銷。這些執行可能涉及預編譯、KECCAK 操作碼，還可能涉及調用合約的特定模式、訪問內存/存儲或是回滾。

更改 gas 開銷可能會降低開發者工具的兼容性，損壞一些應用，但總體上，它的風險比“更深入地”變更 EVM 來說更少。開發者需要注意，不要消耗超出一個區塊所容納的 gas 上限，也永遠都不要用硬編碼 gas 數來進行調用（這已經是長期以來對開發者的標準建議了）。

另一種管理資源限制的方式是，只要對每個操作能被調用的次數設定硬限制就好了。這在電路中的實現很簡單，但是對 EVM 的安全假設就不太好了。我更愿意將這種方法稱作第三類 ZK-EVM，而不是類型 2.5。

類型 3：幾乎是 EVM 等效的

第三類 ZK-EVM 幾乎是 EVM 等效的，但需要對完全等效性做一些犧牲，以進一步改善證明生成時間，并促進 EVM 更易于開發。

優勢：易于構建，證明生成時間更快

第三類 ZK-EVM 也許會取消一些格外難以在 ZK-EVM 實現中實現的功能。預編譯通常會是這類功能中最難實現的；此外，這類 ZK-EVM 有時也在處理合約代碼、內存和堆棧方面有些許不同。

劣勢：兼容性更差

第三類 ZK-EVM 的目標是與大部分應用程序兼容，它只需要對剩下的應用進行極少的改寫。即使是這樣，也需要對一些應用進行改寫，因為這些應用會使用第三類 ZK-EVM 已經取消的預編譯，或是因為它們對邊緣情況有著微妙依賴性，而 VM 會以不同的方式處理。

誰來構建第三類 ZK-EVM？

Scroll 和 Polygon 現在的形式都屬于第三類 ZK-EVM，盡管他們預計會隨著時間改善兼容性。Polygon 的設計很獨特，他們用著自己的內部語言 zkASM 驗證 ZK，并且他們會使用 zkASM 的實現來轉譯 ZK-EVM 代碼。雖然其實現細節是這樣的，但我還是愿意把它稱為真正的第三類 ZK-EVM。它依舊能夠驗證 EVM 代碼，只是用著一些不同的內部邏輯罷了。

現在，還沒有 ZK-EVM 團隊想要成為第三類 ZK-EVM；該類型僅僅是完成預編譯添加這一復雜工作和項目能夠轉為類型 2.5 之前的過渡階段。然而，通過添加新的 ZK-SNARK 友好的預編譯，為開發者提供證明生成時間短、gas 開銷低的功能，第一類和第二類 ZK-EVM 在未來可能會自發成為第三類 ZK-EVM。

類型 4：高級語言（high-level-language）等效

第四類 ZK-EVM 系統的工作原理是，采用高級語言編寫智能合約源碼（如 Solidity、Vyper，或一些由兩者編譯而成的中間語言（intermediate）），并將這些源碼編譯為一些明確設計成 ZK-SNARK 友好的其他語言。

優勢：極快的證明生成時間

不將 EVM 的每個執行步驟的所有環節生成 ZK 證明，而是直接開始證明高級語言編寫的代碼，這樣你可以避免掉很多開銷。

在本文，雖然我只用了一句話來描述這種優勢（對比以下兼容性相關的劣勢要點列表來說），但這句話不應該被解讀為價值判斷！從高級語言直接編譯真的可以極大地減少開銷，并通過讓證明過程變得容易而推動去中心化。

一個用 Vyper 或 Solidity 編寫的“正常”應用程序能夠被編譯出來，并且它“可以運行”，但在很多重要情況下，很多應用會變得不“正常”：

第四類 ZK-EVM 的系統中的合約地址與 EVM 中的可能不一樣，因為 CREATE2 合約地址取決于具體的字節碼。這破壞了依賴于尚未部署的“反事實合約”的應用、ERC-4337 錢包、EIP-2470 單例和許多其他應用程序。

手動編寫的 EVM 字節碼更難投入使用。很多應用程序為了效率，會使用手動編寫部分 EVM 字節碼。盡管有很多種方式可以實現對這類有限制的 EVM 字節碼的支持，可以在無需完全成為第三類 ZK-EVM 的情況下將這些用例應用起來，但第四類 ZK-EVM 的系統可能不會支持這種手動編寫的字節碼。

很多調試基礎設施無法繼續生存，因為這種基礎設施都基于 EVM 字節碼運行。盡管如此，但我們可以通過“傳統”高級語言或中間語言更輕松地訪問調試基礎設施，以減輕這種劣勢（比如 LLVM）。

開發者應該留心這些問題。

誰在構建第四類 ZK-EVM？

ZKSync 系統就是第四類 ZK-EVM，雖然它可能會隨著時間提高 EVM 字節碼的兼容性。Nethermind 的 Warp 項目正在構建從 Solidity 語言轉譯為 StarkWare Cairo 語言的編譯器，這個編譯器將會把 StarkNet 變成真正的第四類 ZK-EVM 系統。

各個 ZK-EVM 類型的未來

并不是說這些類型比其它類型“更好”或“更差”。相反，相較之下他們各有不同：從類型 1 至類型 4，編號較低的 ZK-EVM 類型和現有的基礎設施更加兼容，但運行得更慢；而編號較高的 ZK-EVM 類型則和現有的基礎設施不那么兼容，但運行得更快。總之，對所有 ZK-EVM 類型的探索有益于該領域的健康發展。

另外，ZK-EVM 項目可以隨著時間的推移，輕松地從編號高的 ZK-EVM 開始，然后轉為編號低的類型（反之亦然）。例如：

ZK-EVM 可以在一開始作為第三類 ZK-EVM 投入使用，不去加入一些特別難以生成 ZK 證明的功能。之后，他們可以隨著時間的推移而加入那些功能，繼而轉變為第二類。

一開始作為第二類別的 ZK-EVM，通過在完全兼容以太坊的模式下運行，或使用在修改后能更快生成證明的狀態樹，這類 ZK-EVM 可以在之后變成第二類和第一類 ZK-EVM 的混合類型。Scroll 就正在考慮向這個方向發展。

一些一開始屬于第四類系統的 ZK-EVM 項目，可以通過之后添加 EVM 代碼處理的功能，繼而隨著時間變成第三類 ZK-EVM（盡管開發者還是會被鼓勵直接從高級語言編譯，以此減少費用和證明生成的時間）。

如果以太坊自身為了變得更加 ZK 友好而采用一些修改，那么第二類和第三類可以成為第一類 ZK-EVM。

第一類或第二類 ZK-EVM 可以通過增加驗證 ZK-SNARK 友好語言代碼的預編譯，變成第三類 ZK-EVM。這為開發者在以太坊兼容性和運行速度之間提供了一個選擇。這可以算是第三類 ZK-EVM，因為它會破壞完美的 EVM 等效，但出于實際意圖和目的，它可能還會具有很多第一類和第二類 ZK-EVM 的優勢。它不好的地方可能是，一些開發者工具無法理解 ZK-EVM 的自編譯，雖然這點也可以修復：開發者工具可以通過支持包括 EVM 代碼等效的預編譯實現在內的配置格式，以此增加通用的預編譯支持。

就個人而言，通過結合 ZK-EVM 中的改進與讓以太坊變得更加 ZK-SNARK 友好的改進，我希望這些項目全部慢慢變成第一類 ZK-EVM。在這樣的未來里，我們也會有多種 ZK-EVM 實現，可以用于 ZK rollup，也能用來驗證以太坊鏈本身。理論上，以太坊沒有必要標準化單個 ZK-EVM 的實現來供 L1 使用；不同客戶端可以使用不同的證明，我們才能繼續從代碼冗余中獲益。

不論如何，我們還需要一些時間來迎接這種未來。同時，我們也會在擴容以太坊和開發基于以太坊 ZK rollup 的不同賽道上看到大量創新。

金色財經

CertiK中文社區

深潮TechFlow

Yam

文章匯

硅星人

Sui World

比推BitpushNews

DeFi之道

CT中文

達瓴智庫

Tags：以太坊ROLROLLVIT以太坊幣最新價格6月走勢分析RolodexTROLLGravityCoin

Bitcoin