Vitalik Buterin 新文：未來的「ZK-EVM」會是什麼樣子？

編譯：Luccy，BlockBeats

編按：

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

延伸閱讀

幣市 10 月行情向上機率高！摩根大通：還有「這 3 大利多」待發酵

「V 神」發文提及、賣掉 100 億枚做慈善！MOODENG 幣價一度漲近 500%

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 可以透過讓所有呼叫傳回零，並將呼叫對應到新增到區塊末尾的特權交易來實現。

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

上述設計的一個挑戰是它完全是無狀態的，這使得它在數據利用上效率較低。透過支援有狀態的壓縮，使用理想的資料壓縮，ERC20 發送可以比僅使用無狀態壓縮時更節省空間，最多可節省 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）更容易將這種負擔限制在一定時間內。