Vitalik 最新文章：探討 ZK-EVM 的未來與挑戰

ZK-EVM旨在減少 L2 專案對以太坊協定功能的重複實現，並提高其在驗證以太坊區塊時的效率。

撰文：Vitalik Buterin

編譯：1912212.eth， Foresight News

以太坊之上的二層 EVM 協定，包括 optimistic rollups 和 ZK rollups，都依賴於 EVM 驗證。然而，這要求他們信任龐大的代碼庫，如果該代碼庫中存在錯誤，這些 VM 就有被黑客攻擊的風險。此外，這意味著即使是希望與 L1 EVM 完全等效的 ZK-EVM 也需要某種形式的治理，以將 L1 EVM 的更改複製到他們自己的 EVM 實踐中。

這種情況並不理想，因為這些專案正在複製以太坊協定中已經存在的功能，而以太坊治理已經負責進行升級和修復錯誤：ZK-EVM 基本上與驗證第一層以太坊塊的工作相同！此外，在未來幾年，我們預計輕客戶端將變得越來越強大，很快就會達到使用 ZK-SNARKs 來完全驗證第一層 EVM 執行的程度。到那時，以太坊網路將有效構造內置的 ZK-EVM。因此，問題出現了：為什麼不讓 ZK-EVM 本身也適用於 rollups 呢？

本文將介紹幾種可以實現的「內置 ZK-EVM」版本，並討論權衡和設計挑戰，以及不採用特定方向的原因。實施協定特性的好處應該與將事情留給生態系統並保持基礎協定簡單的好處進行權衡。

我們希望從內置 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 聲明的交易類型：

class ZKEVMClaimTransaction(Container):pre_state_root: bytes32post_state_root: bytes32transaction_and_witness_blob_pointers: List[VersionedHash]

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

class ZKEvmClaimNetworkTransaction(Container):pre_state_root: bytes32post_state_root: bytes32proof: bytestransaction_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31]]

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

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

在共識層，我們添加了驗證規則，即只有當客戶端看到塊中每個聲明的有效證明時，才接受該塊。證明必須是一個 ZK-SNARK，證明 transaction_and_witness_blobs 的串聯是 (Block, Witness) 對的序列化，並且在 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」：具有額外功能的 EVMs。這可能包括新的預編譯，新的操作碼，合約可以用 EVM 或完全不同的 VM（例如在 Arbitrum Stylus 中），甚至具有同步交叉通信的多個並行 EVMs。

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

1. 自定義的 Gas 成本表（用戶不被允許減少 Gas 成本，但他們可以增加它們）

2. 禁用某些操作碼

3. 設置塊號（這將意味著根據硬分叉有不同的規則）

4. 設置標誌，激活已經為 L2 使用標準化但不適用於 L1 使用的整套 EVM 更改，或其他更簡單的更改

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

class PrecompileInputOutputTranscript(Container):used_precompile_addresses: List[Address]inputs_commitments: List[VersionedHash]outputs: List[Bytes]

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

請注意 inputs 和 outputs 之間的不對稱性，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 的重要擴展，為其用戶提供顯著的價值。這包括“幾乎 -EVMs”和完全不同的方法，例如 Arbitrum Stylus 的 WASM 支持和 SNARK 友好的 Cairo 語言。

• 面向用戶和開發者的便利性： 第二層團隊在吸引用戶和項目進入其生態系統並讓他們感到受歡迎方面付出了很多努力；他們通過在其網路內捕獲 MEV 和擁塞費用來獲得報酬。這種關係將繼續存在下去。