Vitalik：討論各種「內置ZK-EVM」版本類型和設計挑戰

詞：維塔利克·布特林

編譯：1912212.eth，遠見新聞

基於ETH的第 2 層 EVM 協定（包括樂觀匯總和 ZK 匯總）依賴於 EVM 驗證。 但是，這要求他們信任龐大的代碼庫，如果該代碼庫中存在錯誤，這些虛擬機就有被駭客入侵的風險。 此外，這意味著即使是希望完全等同於 L1 EVM 的 ZK-EVM，也需要某種形式的治理才能將對 L1 EVM 的更改複製到自己的 EVM 實踐中。

這種情況並不理想，因為這些專案正在複製 ETH Workshop 協定中已經存在的功能，並且 ETH Governance 已經負責升級和修復錯誤： ZK-EVM 本質上與驗證第 1 層ETH Workshop 塊的工作相同！此外，在未來幾年，我們預計輕用戶端將變得越來越強大，並很快達到使用 ZK-SNARK 來完全驗證第 1 層 EVM 執行的地步。 此時，ETH網路將有效地構建內置的ZK-EVM。 那麼，問題來了：為什麼不讓 ZK-EVM 本身也適合匯總呢？

在本文中，我們將介紹一些可以實現的“內置 ZK-EVM”版本，並討論權衡和設計挑戰，以及不朝著特定方向發展的原因。 實現協定功能的好處應該與將事情留給生態系統並保持底層協定簡單的好處相權衡。

我們希望從內置的 ZK-EVM 中獲得哪些關鍵功能？

*基本功能：驗證ETH塊。 協定函數（目前還不清楚是操作碼、預編譯還是其他機制）應該接受至少一個狀態前根、一個塊和一個狀態后根作為輸入，並驗證狀態后根實際上是塊執行的結果。 *相容ETH廣場的多個用戶端。 這意味著我們希望避免只使用一個證明系統，而是允許不同的用戶端使用不同的證明系統。 這導致了以下幾點：

• 數據可用性要求：對於使用內置 ZK-EVM 進行證明的任何 EVM 執行，我們希望保證基礎數據的可用性，以便使用不同證明系統的證明者可以重新證明執行，並允許依賴該證明系統的客戶驗證新生成的證明。
• 證明存在於 EVM 和塊數據結構之外：內置的 ZK-EVM 功能不會將 SNARK 作為 EVM 中的輸入，因為不同的用戶端將期望不同類型的 SNARK。 相反，它可能類似於 blob 驗證：事務可以包含需要證明的（狀態前、塊體、狀態后）聲明，其內容可由操作碼或預編譯器訪問，用戶端共識規則將單獨檢查每個聲明的數據可用性和存在證明。
• 可審計性。 如果任何執行被證明，我們希望基礎數據可用，以便在出現問題時，使用者和開發人員可以檢查它。 事實上，這增加了數據可用性要求如此重要的另一個原因。
• 可升級性。 如果發現 ZK-EVM 解決方案存在錯誤，我們希望能夠快速修復它。 這意味著不需要硬分叉來修復。 這增加了為什麼證明存在於 EVM 和塊數據結構之外。
• 支援幾乎所有的EVM。 L2 的吸引力之一是在執行層進行創新並擴展 EVM。 如果給定 L2 的 VM 與 EVM 只有一點點不同，那麼如果 L2 仍然可以在與 EVM 相同的部分中在本機協定中使用 ZK-EVM，並且只依賴於不同部分中自己的代碼，那就太好了。 這可以通過設計 ZK-EVM 函數來實現，該函數允許調用方指定由外部提供的表而不是 EVM 本身處理的位字段或操作碼清單或位址。 我們還可以在一定程度上使gas成本開放進行編輯。

“開放”和“封閉”多客戶端系統

“多客戶理念”可能是此清單中最主觀的要求。 可以選擇放棄它並專注於ZK-SNARK方案，這將簡化設計，但代價是成為ETH研討會更大的“哲學轉捩點”（因為它實際上放棄了ETH研討會長期以來的多用戶端理念）並引入更大的風險。 未來，當形式驗證技術變得更好時，選擇這條路可能會更好，但現在看來風險太大了。

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

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

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

除了基本的功能正確性和安全性保證外，最重要的屬性是速度。 雖然我們可以在協議中設計 ZK-EVM 功能，它是異步的，並且僅在延遲 N 個插槽後返回每個聲明的答案，但如果我們可以可靠地保證在幾秒鐘內生成證明，無論每個塊中發生什麼都是獨立的，問題就會變得容易得多。

雖然今天為ETH塊生成證明需要幾分鐘或幾小時，但我們知道理論上沒有理由阻止大規模並行化：我們總是可以組合足夠的 GPU 來單獨證明塊執行的各個部分，然後使用遞歸 SNARK 將證明放在一起。 此外，通過FPGA和ASIC實現的硬體加速有助於進一步優化證明。 然而，達到這一點是一個巨大的工程挑戰，不容小覷。

ZK-EVM 功能在協定中會是什麼樣子？

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

請務必注意，在實踐中，我們可能希望將旁載入拆分為兩個單獨的旁載入，一個用於 Blob，一個用於證明，併為每種類型的證明設置單獨的子網（以及用於 Blob 的其他子網）。

在共識層，我們添加了一個驗證規則，僅當用戶端看到區塊中每個聲明的有效證明時，該規則才接受區塊。 證明必須是 ZK-SNARK，證明事務_and_witness_blobs 的串聯是（塊，見證）對的序列化，並且該塊在見證伺服器上以 pre_state_root 執行

（i） 有效，並且

（ii） 輸出正確的帖子_state_root。 可能，客戶可以選擇等待多種類型的M-of-N證明。

這裡需要注意的是，塊執行本身可以簡單地被認為是需要檢查的三元組之一，以及 ZKEVMClaimTransaction 物件（σpre、σpost、Proof）中提供的三元組。 因此，使用者的 ZK-EVM 實現可以替換其執行用戶端;執行用戶端仍將被執行

（i） 證明人和區塊建造者以及：

以及 （ii） 關心索引和存儲數據以供本地使用的節點。

此外，由於此體系結構將執行與驗證分開，因此可以為ETH生態系統中的不同角色提供更大的靈活性和效率。 例如，證明者可以專注於生成證明，而不必擔心執行的細節，而執行用戶端可以優化以滿足特定使用者的需求，例如快速同步或高級索引功能。

驗證和重新證明

假設有兩個ETH用戶端，一個使用 PSE ZK-EVM，另一個使用 Polygon ZK-EVM，此時，兩種實現都已經發展到可以在不到 5 秒的時間內證明ETH塊的執行，並且對於每個證明系統，都有足夠的獨立志願者運行硬體來生成證明。

不幸的是，由於單個證明系統沒有正式化，因此無法在協定中激勵它們，但是，我們預計與研發相比，運行證明的成本將更低，因此我們可以輕鬆地通過資助公共產品的機構為證明者提供資金。

假設有人發佈了 ZKEvmClaimNetworkTransaction，但他們只發佈了 PSE ZK-EVM 版本的證明。 多邊形 ZK-EVM 的證明節點看到這一點，計算並重新發佈物件，以及多邊形 ZK-EVM 的證明。

這將增加接受區塊的最早誠實節點和接受相同區塊的最新誠實節點之間的總最大延遲，從 δ 到 2δ+Tprove （假設此處為 Tprove<5s）。

然而，好消息是，如果我們採用單插槽最終性，我們幾乎可以肯定可以“管道”這種額外的延遲以及SSF固有的多輪共識延遲。 例如，在這個 4 槽提案中，“頭部投票”步驟可能只需要檢查基本塊的有效性，但“凍結和確認”步驟需要存在證明。

擴展：支援“幾乎 EVM”

ZK-EVM 功能的理想目標是支援“幾乎 EVM”：具有附加功能的 EVM。 這可能包括新的預編譯、新的操作碼、可以是 EVM 或完全不同的 VM 的合約（例如在 Arbitrum Stylus 中），甚至是具有同步交叉通信的多個並行 EVM。

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

1.自定義燃氣成本表（使用者不允許降低燃氣成本，但可以增加） 2.禁用某些操作碼 3.設置區塊號（這意味著根據硬分叉有不同的規則） 4. 設定標誌以啟動已針對 L2 標準化但未用於 L1 的全套 EVM 更改，或其他更簡單的更改

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

類預編譯輸入輸出Tran（容器）：已使用_precompile_addresses： 清單[Address][VersionedHash]輸入_commitments：清單[Bytes]輸出：清單

EVM 執行將按如下方式修改。 名為輸入的陣列將被初始化為空。 每當調用 used_precompile_addresses 中的位址時，我們將 InputsRecord（callee_address， Gas， input_calldata） 物件添加到輸入中，並將調用的 RETURNDATA 設置為輸出[i]。 最後，我們檢查 used_precompile_addresses 是否總共調用了 len（outputs） 多次，並且輸入_commitments 與生成的 blob 對輸入的 SSZ 序列化的承諾的結果相匹配。 公開輸入_commitments的目的是使外部SNARK能夠證明輸入和輸出之間的關係。

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

另一個有用的功能可能是允許從任何寄件者帳戶調用「特權事務」。 這些事務可以在另外兩個事務之間運行，也可以在另一個（可能是特權的）事務中運行，同時調用預編譯。 這可用於允許非 EVM 機制回調 EVM。

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

Arbitrum Stylus 等功能可以通過設置 used_precompile_addresses 來支援，以包含常規帳戶位址清單，並在狀態中的帳戶物件中設置特定標誌，並生成證明它們已正確構建的 SNARK，其中合約可以在 EVM 或 WASM（或其他 VM）中編寫其代碼。 特權事務可用於允許 WASM 帳戶回調 EVM。

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

類型 4 的 ZK-EVM 可以通過多個實現來工作：一個將 Solidity 或其他更高級的語言直接轉換為 SNARK 友好的 VM，另一個將其編譯為 EVM 代碼並在規定的 ZK-EVM 中執行。 只有當故障證明者發送聲稱有錯誤的交易時，第二個（也不可避免地會更慢）實現才能運行，並且如果他們能夠提供兩者處理不同的交易，則可以收取賞金。

可以通過向所有調用返回零並將調用映射到添加到塊末尾的特權事務來實現純異步 VM。

擴展：支援狀態證明

上述設計的挑戰在於它是完全無狀態的，這使得它在數據效率方面很差。 通過理想的數據壓縮，與單獨的無狀態壓縮相比，有狀態壓縮可以使 ERC20 發送的空間效率提高多達 3 倍。

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

如果我們想使 ZK-EVM 功能有狀態，我們有兩個選擇：

要求 σpre 為 null，或預先聲明的數據可用的鍵和值清單，或某些以前執行的 σpost。

將 blob 承諾添加到塊生成的接收 R 的（σpre、σpost、proof）元組。 任何以前生成或使用過的 blob 承諾，可以在 ZKEVMClaimTransaction 中引用並在執行期間訪問，包括表示區塊、見證人、收據甚至常規 EIP-4844 blob 事務的承諾（可能有一些時間限制，可以通過一系列指令引用：“在塊 + 見證數據的位置 j 插入提交 i 的位元組 N… N+k-1“）

（1）基本含義是：我們將建立EVM子鏈，而不是建立無狀態EVM驗證。

（2） 實質上創建了一個最小的內置有狀態壓縮演演演算法，該演演演算法使用以前使用或生成的 blob 作為字典。 這兩者都給證明者節點帶來了負擔，只有證明者節點才能存儲更多資訊;

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

封閉式多證明系統和鏈下數據的論據

封閉的多證明系統，其中在M-of-N結構中有固定數量的證明，避免了上述大部分複雜性。 特別是，封閉的多證明系統無需擔心確保數據存在於鏈上。 此外，封閉的多證明系統將允許ZK-EVM證明在鏈下執行，使其與EVM等離子體解決方案相容。

然而，封閉的多證明者系統增加了治理的複雜性並削弱了可審計性，這是一個需要權衡這些優勢的高成本。

如果我們構建 ZK-EVM 並使其成為協定功能，L2 專案的持續角色是什麼？

目前由 L2 團隊自己實現的 EVM 驗證函數將由協議處理，但 L2 專案仍將負責許多重要功能：

• 快速預確認：單插槽終結性可以減慢 L1 插槽的速度，而 L2 已經為使用者提供了具有自身安全性的預確認支援服務，延遲遠小於一個插槽。 這項服務將繼續由L2全權負責。
• MEV 緩解策略：這可能包括加密記憶體池、基於信譽的順序選擇等功能，L1 不願意實施這些功能。
• EVM 的擴展：第 2 層專案可以引入對 EVM 的重要擴展，為其使用者提供重要價值。 這包括“幾乎EVM”和完全不同的方法，例如Arbitrum Stylus的WASM支援和SNARK友好的開羅語言。 *為使用者和開發人員提供便利：Tier 2團隊投入大量精力吸引使用者和專案加入他們的生態系統，讓他們感到受歡迎;他們通過在網路中捕獲MEV和擁塞費來獲得報酬。 這種關係將繼續存在。