Vitalik新文：ZK-EVM的未來與挑战

2023-12-14 12:12:09

原文標題：《What might an「enshrined ZK-EVM」look like?》

原文作者：Vitalik

原文編譯：Luccy，BlockBeats

編者按： 12 月 13 日，以太坊聯合創始人 Vitalik Buterin 發文深入探討了「ZK-EVM」（ Zero -Knowledge Ethereum Virtual Machine）的可能實現形式，並對不同版本 ZK-EVM 的設計進行探討。

Vitalik 提出的 ZK-EVM 概念，旨在減少 Layer-2 項目對 Ethereum 協議功能的重復實現，並提高其在驗證 Layer-1 Ethereum 區塊時的效率。文章指出，當前的 Layer-2 EVM 協議（如 Optimistic Rollups 和 ZK Rollups）需要依賴於 EVM 的驗證機制，但這同時意味着他們必須信任龐大的代碼庫。一旦代碼庫中存在漏洞，這些虛擬機可能面臨被攻擊的風險。

此外，他還提到了對「almost-EVM」的支持，即允許 L2 的 VM 在與 EVM 只有微小差異的情況下，仍能使用協議內的 ZK-EVM，同時也為 EVM 的部分定制化提供了靈活性。

以太坊上的 Layer-2 EVM 協議，包括 op rollup 和 ZK rollup，依賴於 EVM 驗證。然而，這要求它們信任一個龐大的代碼庫，如果該代碼庫存在漏洞，這些虛擬機面臨被黑客攻擊的風險。此外，即使是希望與 L1 EVM 完全等同的 ZK-EVM，也需要一定形式的治理，以將 L1 EVM 的更改復制到它們自己的 EVM 實現中。

這種情況並不理想，因為這些項目正在復制以太坊協議中已經存在的功能，而以太坊治理已經負責升級和修復錯誤：ZK-EVM 基本上執行與驗證 L1 以太坊區塊相同的工作！此外，未來幾年內，我們預計輕客戶端將變得越來越強大，很快就會使用 ZK-SNARKs 完全驗證 L1 以太坊執行。此時，以太坊網絡將有效地擁有一個內置的 ZK-EVM。因此，問題出現了：為什么不將該 ZK-EVM 本地化提供給 rollup 項目呢？

本文將描述幾個可能實現的「被奉為圭臬的 ZK-EVM」版本，並探討權衡和設計挑战，以及不選擇特定方向的原因。這些實現協議特性的優勢應該與留給生態系統的好處和保持基礎協議簡單的利益相權衡。

我們對被奉為圭臬的 ZK-EVM 有哪些關鍵屬性的期望？

基本功能：驗證以太坊區塊。該協議特性（目前仍未確定是操作碼、預編譯還是其他機制）應至少接受預狀態根、區塊和後狀態根作為輸入，並驗證後狀態根是否確實是在預狀態根的基礎上執行區塊的結果。

與以太坊多客戶端理念的兼容性。這意味着我們希望避免奉行單一的證明系統，而是允許不同的客戶端使用不同的證明系統。這反過來又意味着一些要點：

· 數據可用性要求：對於使用被奉為圭臬的 ZK-EVM 證明的任何 EVM 執行，我們希望能夠保證底層數據是可用的，以便使用不同證明系統的證明者可以重新證明執行，依賴該證明系統的客戶端可以驗證這些新生成的證明。

· 證明存在於 EVM 和區塊數據結構之外：ZK-EVM 特性不會直接將 SNARK 作為 EVM 內輸入，因為不同的客戶端期望不同類型的 SNARK。相反，它可能類似於 blob 驗證：交易可以包含需要證明的（預狀態、區塊主體、後狀態）語句，操作碼或預編譯可以訪問這些語句的內容，客戶端共識規則將分別檢查每個在區塊中提出的聲明的數據可用性和證明的存在。

可審計性。如果任何執行都得到證明，我們希望底層數據是可用的，以便在發生任何問題時，用戶和开發者可以檢查。在實踐中，這增加了數據可用性要求重要性的另一個原因。

可升級性。如果發現特定的 ZK-EVM 方案存在漏洞，我們希望能夠快速修復。這意味着不需要硬分叉來進行修復。這增加了證明存在於 EVM 和區塊數據結構之外的重要性的另一個原因。

支持 almost-EVM 的網絡。L2 的吸引力之一在於創新執行層的能力，並對 EVM 進行擴展。如果某個給定的 L2 的虛擬機（VM）與 EVM 僅有細微差異，那么如果 L2 仍然可以使用與 EVM 相同的原生協議內 ZK-EVM，僅對與 EVM 相同的部分依賴其自身代碼，對於不同的部分則依賴於他們自己的代碼，那將是很好的。這可以通過設計 ZK-EVM 特性的方式來實現，該特性允許調用者指定由外部提供的表處理的一些操作碼、地址或位域，而不是由 EVM 本身處理。我們還可以在有限的範圍內使燃氣成本开放定制。

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

「多客戶端理念」可能是這個列表中最有主張的要求。有放棄這一理念的選擇，集中精力研究一個 ZK-SNARK 方案，這將簡化設計，但代價是對以太坊的一個更大的「哲學轉變」（因為實際上這將是對以太坊長期多客戶端理念的放棄）和引入更大的風險。在長期未來，例如形式化驗證技術變得更好的情況下，可能更好地選擇這條道路，但目前來看，風險似乎太大。

另一種選擇是封閉的多客戶端系統，在協議內已知一組固定的證明系統。例如，我們可能決定使用三個 ZK-EVMs：PSE ZK-EVM、 Polygon ZK-EVM 和 Kakarot 。一個區塊需要攜帶這三個中的兩個的證明才能被視為有效。這比單一的證明系統要好，但它使系統變得不太適應性，因為用戶必須為每個已知的證明系統維護驗證器，必然會存在政治性的治理過程來納入新的證明系統等等。

這促使我更傾向於採用开放的多客戶端系統，其中證明被放置在「區塊之外」，並由客戶端分別驗證。個別用戶可以使用他們想要的客戶端來驗證區塊，只要至少有一個生成該證明系統證明的證明者。證明系統將通過說服用戶運行它們而獲得影響力，而不是通過說服協議治理過程。然而，這種方法確實具有更多的復雜性成本，我們將會看到。

我們希望 ZK-EVM 實現具備哪些關鍵特性？

除了基本的正確功能和安全性保證之外，最重要的特性是速度。雖然可以設計一個協議內的 ZK-EVM 特性，其是異步的，僅在經過 N 個時隙的延遲後為每個聲明返回一個答案，但如果我們可以可靠地保證在幾秒內生成證明，那么每個區塊中發生的一切都是自包含的問題將變得更容易。

盡管今天生成以太坊區塊的證明需要很多分鐘或小時，但我們知道沒有理論上的阻止大規模並行化的原因：我們總是可以組合足夠多的 GPU，分別證明區塊執行的不同部分，然後使用遞歸 SNARKs 將這些證明組合在一起。此外，通過 FPGAs 和 ASICs 的硬件加速可能有助於進一步優化證明。然而，實際達到這一點是一個重要的工程挑战，不應該被低估。

協議內的 ZK-EVM 特性可能具體是什么樣子？

類似於 EIP-4844 Blob 交易，我們引入了一種包含 ZK-EVM 聲明的新交易類型：

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

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

請注意，在實際操作中，我們可能會希望將邊車分成兩個獨立的邊車，一個用於 blob，一個用於證明，並為每種證明類型設置一個單獨的子網（還有一個額外的子網用於 blob）。

在共識層上，我們添加了一個驗證規則，即僅當客戶端看到了區塊中每個聲明的有效證明後，該區塊才會被接受。證明必須是 ZK-SNARK 證明聲明，即 transaction_and_witness_blobs 的串聯是（ Block ，Witness）對的序列化，執行塊在 pre_state_root 上使用 Witness (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<5 秒）。

然而，好消息是，如果我們採用單槽確定性，我們幾乎肯定可以將這種額外延遲與 SSF 固有的多輪共識延遲一起「流水线」處理。例如，在這個 4 子槽提案中，「頭部投票」步驟可能只需要檢查基本的區塊有效性，但「凍結和確認」步驟將需要存在一個證明。

擴展：支持「almost-EVM」

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

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

· 自定義 gas 成本表（用戶不得減少 gas 成本，但可以增加）

· 禁用某些操作碼

· 設置區塊編號（這將意味着根據硬分叉而有不同的規則）

· 設置一個激活已為 L2 使用而非 L1 使用標准化的整套 EVM 更改的標志，或其他更簡單的更改

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

EVM 執行將被修改如下。數組 inputs 將被初始化為空。每次調用 used_precompile_addresses 中的地址時，我們將 InputsRecord（callee_address、gas、input_calldata）對象附加到 inputs，並將調用的 RETURNDATA 設置為 outputs[i]。最後，我們檢查 used_precompile_addresses 總共被調用了 len(outputs) 次，並且 inputs_commitments 匹配生成的 blob commitments 到 inputs 的 SSZ 序列化的結果。暴露 inputs_commitments 的目的是為了方便外部 SNARK 證明輸入和輸出之間的關系。

請注意輸入和輸出之間的不對稱性，其中輸入被存儲在散列中，而輸出被存儲在必須提供的字節中。這是因為執行需要由僅看到輸入並理解 EVM 的客戶端完成。EVM 執行已經為它們生成了輸入，因此它們只需檢查生成的輸入是否與聲明的輸入匹配，這僅需要進行散列檢查。但是，輸出必須以完整形式提供給它們，因此必須是數據可用的。

另一個有用的功能可能是允許「特權事務」，即從任意發件人账戶發起調用的事務。這些事務可以在兩個其他事務之間運行，或者在另一個（可能也是特權的）事務中調用預編譯時運行。這可以用於允許非 EVM 機制調用回 EVM。

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

· 通過設置 used_precompile_addresses，包括在狀態中其帳戶對象中設置了某些標志的常規账戶地址列表，並制作一個 SNARK 來證明它被正確構建，您可以支持 Arbitrum Stylus 風格的功能，其中合同的代碼可以用 EVM 或 WASM（或其他 VM）編寫。特權事務可用於允許 WASM 账戶回調到 EVM。

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

· 第四類型的 ZK-EVM 可以通過擁有多個實現來運作：一個將 Solidity 或其他高級語言直接轉換為 SNARK 友好的 VM 的實現，另一個將其編譯為 EVM 代碼並在被奉為圭臬的 ZK-EVM 中執行。第二個（不可避免地較慢的）實現僅在錯誤證明者發送聲明存在錯誤的交易的情況下運行，如果他們能夠提供兩者不同處理的交易，則可以獲得獎勵。

· 一個純異步的 VM 可以通過使所有調用返回零，並將調用映射到添加到塊末尾的特權交易來實現。

擴展：支持有狀態的證明者

上述設計的一個挑战是它完全是無狀態的，這使得它在數據利用上效率較低。通過支持有狀態的壓縮，使用理想的數據壓縮，ERC 20 發送可以比僅使用無狀態壓縮時更節省空間，最多可以節省 3 倍的空間。

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

如果我們想讓 ZK-EVM 功能成為有狀態的，那么我們有兩個選擇：

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

2. 將一個由區塊生成的收據 R 的 blob 承諾添加到 (σpre,σpost, Proof) 元組中。任何先前生成或使用的 blob 承諾，包括那些表示區塊、見證、收據甚至是常規的 EIP-4844 blob 交易的承諾，可能帶有一些時間限制，都可以在 ZKEVMClaimTransaction 中被引用，並在其執行過程中被訪問（可能通過一系列指令實現：「在塊+見證數據的位置 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 自身安全支持的「預確認」，延遲遠低於一個槽。這項服務將繼續是純粹的 L2 責任。

MEV 緩解策略：這可能包括加密內存池、基於聲望的順序選擇以及 L1 不愿意實施的其他功能。

對 EVM 的擴展：L2 項目可以整合對 EVM 的實質性擴展，為其用戶提供重要價值。這既包括「幾乎-EVMs」，也包括像 Arbitrum Stylus 的 WASM 支持和 SNARK 友好的 Cairo 語言等根本不同的方法。

面向用戶和开發者的便利：L2 團隊在吸引用戶和項目進入其生態系統並使其感到受歡迎方面做了大量工作；他們通過在其網絡內獲取 MEV 和擁塞費用來獲得補償。這種關系將繼續存在。

原文鏈接