Vitalik：探索 ZK-EVM 未來的可能性與挑戰

14 min readDec 14, 2023

Vitalik Buterin提出的ZK-EVM概念旨在減少L2項目對以太坊協議功能的重複實現，並提高其在驗證坊以太坊區塊時的效率。ZK rollups和optimistic rollups都依賴於EVM驗證，前者大而受信任的代碼庫。即使是希望與L1 EVM完全對應的ZK-EVM也需要某種形式的治理。他認為ZK-EVM與驗證第一層以太坊塊的工作相同，即使未來輕客戶端變得更強大，以太坊網路將有效構造內置的ZK-EVM。他在文章中介紹了ZK-EVM實現的關鍵屬性和內部協議的驗證和重新證明。

Vitalik Buterin 提出的 ZK-EVM 概念，旨在減少 L2項目對以太坊協議功能的重複實現，並提高其在驗證坊以太坊區塊時的效率。

撰文：Vitalik Buterin

我們希望從內置 ZK-EVM 中獲得哪些關鍵特性？

基本功能：驗證以太坊區塊。協議功能（目前尚不明確是操作碼、預編譯或其他機制）應接受至少一個前狀態根、一個塊和一個後狀態根輸入作為，並驗證後狀態根實際上是執行塊後的結果。
與以太坊的多個客戶端兼容。這意味著我們希望避免只採用一個論證系統，而是允許不同的客戶端使用不同的論證系統。這又引出以下幾點：
數據可用性要求：對於任何使用內置ZK-EVM進行證明的EVM執行，我們希望保證基礎數據的可用性，以便使用不同證明系統的證明者可以重新證明執行，並允許依賴該證明系統的客戶端驗證新生成的證明。
證明存在於 EVM 和區塊數據結構之外：內置 ZK-EVM 功能不會將 SNARK 作為 EVM 內的輸入，因為不同的客戶端會需要不同類型的 SNARK。相反，它可能類似於 blob 驗證：交易可以包括（前狀態、區塊主體、後狀態）需要說明的聲明，一個操作碼或預編譯可以訪問這些聲明的內容，客戶端意見規則將分別檢查每個聲明的數據可用性和存在說明。
可審計性。如果任何執行得到證明，我們希望基礎數據是可用的，以便在出現問題時，用戶和開發人員可以檢查它。實際上，這增加了為什麼數據可用性要求如此重要的另一個原因。
可升級性。如果某個 ZK-EVM 方案發現有 bug，我們希望能夠快速修復它。這意味著不需要硬分叉來修復。這增加了為什麼證明存在於 EVM 和區塊數據結構之外的原因。
支持幾乎所有的EVM。L2的吸引力之一是在執行層進行創新，並擴展EVM。如果給定的L2的VM與EVM唯一一點點不同，那麼如果L2仍然可以在與EVM相同的部分使用本機協議內ZK-EVM，並在不同的部分僅依賴於自己的代碼，那將是一件好事。這可以通過設計ZK-EVM功能來實現，該功能允許調用者指定位欄位或操作碼列表或地址，這些位欄位、操作碼列表或地址由外部提供的表而不是 EVM 本身處理。我們還可以在一定的編程中使 Gas 成本開放編輯。

「開放」與「封閉」的多客戶端系統

「多客戶端理念」可能是這個列表中最具特色的要求。可以選擇放棄它，專註於 ZK-SNARK 方案，這將簡化設計，但代價是成為以太坊更大的「哲學轉折點」（因為這實際上是放棄了以太坊長達的多客戶端理念），並帶來更大的風險。如果未來形態驗證技術變得更好的時候，選擇一條路可能會更好，但現在看來風險似乎有點了。

另一種選擇是封閉的多客戶端系統，在協議中已知有一組固定的證明系統。例如，我們可能會決定使用三個ZK-EVM：PSE ZK-EVM、Polygon ZK-EVM 和 Kakarot。這需要這三個中的兩個提供的證明才有效。這比單一的證明系統要好，但它使系統的功耗降低，用戶必須為每個存在的證明系統維護驗證器，並且簡單地會有政治治理過程來納入新的論證系統等。

這促使我更喜歡開放的多客戶端系統，在這個系統中，證明被放置在「區塊外部」，並由客戶端單獨驗證。個人用戶可以使用他們想要的任何客戶端來驗證區塊，至少有一個論證者為該論證系統創建論證就可以。論證系統將通過說服用戶運行他們來獲得影響力，而不是通過說服協議治理過程。但是，這種方法確實有較高的複雜性成本，正如我們將看到的那樣。

我們希望從 ZK-EVM 實現中獲得哪些關鍵屬性？

除了基本的功能正確性和安全性保證之外，最主要的屬性是速度。雖然我們可以設計在協議內的ZK-EVM重要特性，它是非同步的，在N個插槽的延遲後只返回每個聲明的答案，但如果我們能夠可靠地保證在幾套別墅內生成一個證明，那麼無論每個塊中發生的什麼都是自包含的，問題就會變得容易分裂。

雖然今天為以太坊區塊生成證明需要很多分鐘或小時，但我們知道沒有理論上的原因阻止大規模大規模化：我們總是可以將足夠的 GPU 組合起來，分別證明一個塊執行的各個部分，然後使用梯度 SNARK 論證並在一起。此外，通過 FPGA 和 ASIC 的硬體加速可以幫助進一步優化論證。然而，真正實現這一步卻是不容小覷的浩大工程挑戰。

協議內 ZK-EVM 特性的具體形式可以學習嗎？

與 EIP-4844 blob 交易類似，我們引入了新的包含 ZK-EVM 聲明的交易類型：

類 ZKEVMClaimTransaction(Container):pre_state_root: bytes32post_state_root: bytes32transaction_and_witness_blob_pointers: 列表[VersionedHash]

與 EIP-4844 一樣，在內存礦池中傳遞的對象將是交易的修改版本：

類 ZKEvmClaimNetworkTransaction(Container):pre_state_root: bytes32post_state_root: bytes32proof: bytestransaction_and_witness_blobs: 列表[Bytes[FIELD_ELEMENTS_PER_BLOB * 31]]

晚上可以轉換為前面，但反之則不行。我們還擴展了區塊側載對象（在 EIP-4844 中引入），以包含區塊中聲明的證明列表。

需要注意的是，在實踐中，我們可能希望將側載拆分為兩個單獨的側載，一個用於 blob，一個用於證明，並為多種類型的證明（以及 blob 的附加子網））設置一個單獨的子網。

在共識層，我們添加了驗證規則，即只有當客戶端看到塊中每個聲明的有效證明時，才接受該塊。證明必須是一個 ZK-SNARK，證明 transaction_and_witness_blobs 的三星是 (Block, Witness)的序列化，並且在見證上使用 pre_state_root 對執行該塊

(i) 是有效的，並且

(ii) 輸出正確的 post_state_root。可能的情況是，客戶端可以選擇等待多種類型證明的 M-of-N。

這裡需要注意的是，塊執行本身可以被簡單地視為需要與 ZKEVMClaimTransaction 對象中提供的三元組一起檢查的三元組之一（σpre,σpost,Proof）。因此，用戶的 ZK-EVM 實現可以替換其執行客戶端；執行客戶端仍將由

(i) 證明者和塊構建者以及

(ii) 關注索引和數據存儲以供本地使用的節點使用。

另外，由於這種架構將執行與驗證分開，因此可能為以太生態系統中的不同角色提供更多靈活和效率。例如，證明者可以專註於坊生成證明，而無需擔心執行的具體細節，而執行客戶端可以被優化以滿足特定用戶的需求，例如快速同步或高級索引功能。

驗證和重新證明

假設有兩個以太坊客戶端，其中一個使用PSE ZK-EVM，另一個使用Polygon ZK-EVM，這個時候，這兩個實現都已經發展到可以在5秒內證明以太坊塊執行的程度，並且對於每個證明系統，就存在足夠多的獨立志願者運行硬體來生成證明。

不幸的是，因為一般論證系統沒有被正式確立，它們無法在協議中獲得啟發；不過，我們預計與研究和開發相比，運行論證的成本將會較低，因此我們可以輕鬆地通過面向公共項目資助的機構為證明者提供資金。

假設有人發布了記號 ZKEvmClaimNetworkTransaction，但他們只發布了 PSE ZK-EVM 版本的證明。Polygon ZK-EVM 的節點證明看到了這一點，計算並重新發布該對象，附有 Polygon ZK-EVM 的證明。

這將使得最早的公平節點接受一個塊和最晚的公平節點接受相同塊之間的最大延遲從δ增加到2δ+Tprove（這裡假設Tprove<5s）。

然而，好消息是，如果我們採用單個時隙的最終性，我們幾乎可以肯定地將這個額外的延遲與 SSF 中固有的多輪喚醒延遲一起「同步」進行。例如，在這 4 個子時隙的提示中，「頭部投票」步驟可能只需要檢查基本部分的有效性，但「凍結並正確」步驟則需要存在一個證明。

擴展：支持「almost-EVMs」

ZK-EVM 功能的可取目標是支持「almost-EVMs」：具有額外功能的 EVM。這可能包括新的預編譯、新的操作碼、可以與 EVM 或完全不同的 VM 兼容（例如在 Arbitrum Stylus 中），甚至具有同步交叉通信的多個EVM。

修改一些可以以簡單的方式支持：我們可以定義一種語言，允許 ZKEVMClaimTransaction 提交後的 EVM 規則的完整描述。這可以用於以下情況：

自定義的 Gas 成本表（用戶不允許減少 Gas 成本，但他們可以增加它們）
取消某些操作碼
設置塊號（這將意味著根據硬分叉有不同的規則）
使用標誌，激活已經為 L2 標準化，但不適用於 L1 使用的整套 EVM 更改，或其他更簡單的更改

為了允許用戶以更開放的方式添加新功能，例如通過引入新的預編譯（或操作碼），我們可以在 ZKEVMlaimNetworkTransaction 的 blob 部分中添加一個包含預編譯輸入/輸出記錄的方式：

類 PrecompileInputOutputTranscript(Container):used_precompile_addresses: 列表[Address]input_commitments：列表[VersionedHash]輸出：列表[Bytes]

EVM執行將被如下。一個名為inputs的數組將被初始化為空。每當被調用used_precompile_addresses修改中的地址時，我們向inputs添加一個InputsRecord(callee_address, Gas, input_calldata)對象，並調用的RETURNDATA設置為輸出[i]最後，我們檢查used_precompile_addresses總共被調用了len(outputs)次，以及inputs_commitments是否與生成的blob對inputs的SSZ序列化的承諾的結果匹配。公開inputs_commitments的目的是為了使外部SNARK能夠證明inputs和outputs之之間的關係。

請注意輸入和輸出之間的不便宜性，輸入存儲在哈希中，而輸出存儲在必須提供的位元組中。這是因為執行需要由看到僅輸入並理解 EVM 的客戶端執行。EVM 執行已經為它們生成了，它們只需要檢查生成的輸入是否與聲明的輸入匹配，只需要進行哈希檢查。但是，必須完全為它們提供輸出，因此必須具備數據可用性。

另一個有用的功能可能是允許「特權交易」從任意發送方賬戶進行調用。這些交易可以在兩個交易之間運行，或者在另一個（可能也是特權）交易中，同時調用預編譯。可以用於允許非EVM調用回EVM機制。

該設計可以修改以支持新的或修改的操作碼，除了新的或修改的預編譯。即使只有預編譯，該設計也非常強大。例如：

通過設置used_precompile_addresses以包含在狀態中的其賬戶對象中設置了某個標誌的一組常規賬戶地址的列表，並生成證明其正確構建的SNARK可以，支持像Arbitrum Stylus一樣的功能，其中合約可以在EVM或 WASM（或其他 VM）中編寫了其代碼。特權交易可用於允許 WASM 賬戶回調 EVM。

通過添加外部檢查，確保多個 EVM 執行的輸入/輸出記錄和特權交易以正確的方式匹配，可以證明通過同步通道相互通信的多個 EVM 的毛系統。

類型為 4 的 ZK-EVM 可以通過具有多種實現來兼容：一個將 Solidity 或另一種更高級別的語言直接轉換為 SNARK 友好 VM 的實現，另一個將其編譯為 EVM 代碼並在規定的 ZK- EVM 中執行的實現。第二個（首先比較慢的）實現只能在故障證明者請求交易要求存在錯誤的情況下運行，如果他們能夠提供兩種處理不同的交易，則可以收集賞金。

通過使所有調用返回零放置調用映射到添加到塊消耗的佔用交易，可以實現純非同步VM。

擴展：支持狀態證明者

其次設計的挑戰是它完全是無狀態的，這使得它在數據效率上表現不佳。使用理想的數據壓縮，相對於僅使用無狀態壓縮，有狀態壓縮可以使ERC20在空間利用上更高效，最多可以提高3倍。

除此之外，有狀態的 EVM 不需要提供證人數據。在這兩種情況下，原則是相同的：當我們已經知道數據可用時，因為它是由 EVM 的先前執行輸入或產生的數據時，要求數據可用是一種浪費。

如果我們希望使ZK-EVM具有狀態功能，則有兩種選擇：

要求σpre或為空，或者數據可用的預先聲明的鍵和值列表，或者是某個先前執行的σpost。

為由塊生成的收據R添加一個blob承諾到(σpre, σpost, Proof)元組。ZKEVMClaimTransaction中可以引用並在其執行過程中訪問任何先前生成或使用的blob承諾，包括表示塊、證人、收據或甚至恆定 EIP-4844 blob 事務的承諾（可能有一些時間限制，可以通過一系列指令進行引用：「在塊 + 證人數據的位置 j 處插入承諾 i 的位元組 N…N+k-1」）

（1）基本意思是：隨著確認無狀態的EVM驗證，我們將確認EVM子鏈。

（2）本質上是創建了最小的內置有狀態壓縮演算法，該演算法利用先前使用或生成的blob作為字典。這兩者都對證明者節點承擔了負擔，只對證明者節點承擔了負擔，以存儲更多的信息；

在情況（2）中，對這種負擔進行時間的限制更容易，而在情況（1）中則較難。

封閉多證明者系統和離鏈數據的論點

封閉多論證者系統，其中在M-of-N結構中有固定數量的論證系統，避免了上述很多複雜性。尤其是，封閉多論證者系統無需擔心確保數據存在於鏈上。另外，封閉多論證者系統證明者系統將允許 ZK-EVM 證明鏈下執行；這與 EVM Plasma 解決方案兼容。

然而，封閉式多論證者制度增加了治理複雜性並帶來了可審計性，這些是需要權衡的，而這些優勢相對應付出高昂的代價。

如果我們內置 ZK-EVM 把它作為協議特性，那麼 L2項目的持續作用是什麼？

目前由 L2 團隊自行實施的 EVM 驗證功能將由協議處理，但 L2項目仍將負責許多重要功能：

快速預確認：單時隙最終性可能使L1時隙變慢，而L2已經通過其自身的安全性為用戶提供了由預確認支持的服務，延遲遠遠低於一個時隙。這個服務將繼續完全由L2負責。
MEV 緩解策略：這可能包括加密的內存礦池、基於聲望的順序選擇等功能，而這些是 L1 不易實施的。
針對 EVM 的擴展：第二層項目可以引入針對 EVM 的重要擴展，方便用戶提供顯著的價值。其中包括「幾乎完全 EVM」和不同的方法，例如 Arbitrum Stylus 的 WASM 支持和 SNARK 編程語言的 Cairo 語言。
面向用戶和開發者的便利性：第二層團隊在吸引用戶和項目進入其生態系統，並讓他們感到受歡迎方面做了很多努力；通過他們在其網路內部捕獲MEV並擁有塞費來獲得報酬。種關係將繼續存在下去。