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 。他們不會更改以太坊系統的任何部分來讓它更容易生成證明:不會替換哈希、狀態樹、交易樹、預編譯或是共識中的其他邏輯,不管這些部分多麼次要。

優勢:完美的兼容性

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

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

第一類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。也就是說,“從內部來看”,他們完全就像以太坊一樣,但是在外部與以太坊有一些區別,尤其是區塊結構和狀態樹等數據結構。

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

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

第二類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 操作碼。

這些修改極大地改善了證明生成的時間,但它們沒有解決所有問題。這類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 開銷

在最糟糕的情況下,有一種能夠極大地改善證明生成時間慢的方式是,大大提高那些難以在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 的不同賽道上看到大量創新。

Total
0
Shares
Related Posts