Vitalik：探討多種「內建ZK-EVM」版本類型及設計挑戰

撰文：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 聲明的交易類型：

需要注意的是，在實踐中，我們可能想要將側載拆分為兩個單獨的側載，一個用於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 和擁塞費用來獲得報酬。這種關係將繼續存在下去。