維塔利克新文章：ZK-EVM 的未來和挑戰

原標題：「供奉的ZK-EVM」會是什麼樣子？

原作者：維塔利克

原創合輯：Luccy， BlockBeats

*編者按：12月13日，ETH Place的聯合創始人Vitalik Buterin發表了一篇文章，深入研究了“ZK-EVM”（零知識乙太坊虛擬機）的可能實現，並討論了不同版本的ZK-EVM的設計。 *

*Vitalik的ZK-EVM概念旨在減少第2層專案對乙太坊協定功能的重複，並提高其驗證第1層乙太坊區塊的效率。 文章指出，當前的第 2 層 EVM 協定（如樂觀匯總和 ZK 匯總）依賴於 EVM 驗證機制，但這也意味著它們必須信任大型代碼庫。 一旦代碼庫中存在漏洞，這些虛擬機就可能面臨受到攻擊的風險。 *

*此外，他提到了對“幾乎 EVM”的支援，它允許 L2 VM 在協定中使用 ZK-EVM，與 EVM 只有微小的區別，同時還為 EVM 的某些自定義提供了靈活性。 *

ETH上的第 2 層 EVM 協定（包括操作匯總和 ZK 匯總）依賴於 EVM 驗證。 但是，這要求他們信任大型代碼庫，如果該代碼庫存在漏洞，則這些虛擬機有被駭客入侵的風險。 此外，即使是希望完全等同於 L1 EVM 的 ZK-EVM，也需要某種形式的治理來將 L1 EVM 的更改複製到自己的 EVM 實現中。

這種情況並不理想，因為這些專案正在複製 ETH Fang 協定中已經存在的功能，並且 ETH Fang 治理已經負責升級和修復錯誤： ZK-EVM 基本上與驗證 L1 ETH塊的工作相同！ 此外，在未來幾年內，我們預計輕用戶端將變得越來越強大，並且很快就會使用 ZK-SNARKs 全面驗證 L1 ETH Fang 執行。 此時，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，僅依賴於自己的代碼用於 EVM 的相同部分，而自己的代碼用於不同的部分，那就太好了。 這可以通過設計 ZK-EVM 功能來實現，該功能允許調用方指定一些操作碼、位址或位字段，這些操作碼、位址或位字段由外部提供的表處理，而不是由 EVM 本身處理。 我們還可以在有限的範圍內使天然氣成本開放給定製。

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

“多用戶端概念”可能是此列表中斷言最多的要求。 可以選擇放棄這個想法，專注於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 聲明：

與 EIP-4844 類似，記憶體池中傳遞的物件將是事務的修改版本：

後者可以轉換為前者，但不能相反。 我們還擴展了塊 sidecar 物件（在 EIP-4844 中引入），以包含塊中所做的證明清單。

請注意，在實踐中，我們可能希望將挎斗拆分為兩個單獨的挎斗，一個用於 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用戶端，其中一個使用 PSE ZK-EVM，另一個使用 Polygon ZK-EVM。 假設此時，兩種實現都已經發展到可以在5秒內證明ETH塊執行的程度，並且對於每個證明系統，都有足夠的獨立志願者運行硬體來生成證明。

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

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

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

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

擴展：支援“幾乎EVM”

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

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

· 自訂燃氣成本表（使用者不允許使用者降低燃氣成本，但可以增加）

· 關閉某些操作碼

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

· 設置一個標誌，用於啟動已標準化為 L2 使用而不是 L1 使用的全套 EVM 更改或其他更簡單的更改

為了允許使用者通過以更開放的方式引入新的預編譯（或操作碼）來添加新功能，我們可以將包含預編譯輸入/輸出腳本的內容添加到 ZKEVMClaimNetworkTransaction 的 blob 的一部分：

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

請注意輸入和輸出之間的不對稱性，其中輸入存儲在哈希中，輸出存儲在必須提供的位元組中。 這是因為執行需要由只看到輸入並理解 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 事務的 blob 承諾，這些承諾可能有一些時間限制，都可以在 ZKEVMClaimTransaction 中引用並在其執行期間訪問（可能通過一系列指令：“在區塊 + 見證數據的位置 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 自身安全性支援的“預確認”，延遲比一個插槽低得多。 這項服務將繼續是純粹的L2責任。

MEV 緩解策略：這可能包括加密記憶體池、基於信譽的順序選擇以及 L1 不願實現的其他功能。

EVM 的擴展：L2 專案可以合併對 EVM 的大量擴展，以為其使用者提供重要價值。 這包括“幾乎EVM”和根本不同的方法，如Arbitrum Stylus的WASM支援和SNARK友好的開羅語言。

為使用者和開發人員提供便利：L2 團隊做了很多工作來吸引使用者和專案加入他們的生態系統，讓他們感到受歡迎，並且他們通過在網路內獲得 MEV 和擁塞費來獲得補償。 這種關係將繼續存在。

連結到原始文章