jakiro
作者：以太坊研究員 Justin Drake，ethresearch；編譯：陶朱，比特鏈視界
這篇文章的功勞要歸功於更廣泛的以太坊研發社區。關鍵貢獻源自 2017 年，多年來設計有了重大的增量解鎖。最近的 zkVM 工程突破引發了徹底的設計空間探索。本文只是盡最大努力嘗試為一個可能終於到來的大創意拼湊出一個連貫的設計。
摘要
我們提出了一種優雅而強大的 EXECUTE 預編譯，將原生 L1 EVM 執行引擎暴露給應用層。原生執行匯總（簡稱「原生匯總」）是一種使用 EXECUTE 來驗證批量用戶交易的 EVM 狀態轉換的匯總。可以將原生匯總視為「可編程執行分片」，將預編譯包裝在派生函數中以處理 EVM 外的系統邏輯，例如排序、橋接、強制包含、治理。
由於 EXECUTE 預編譯由驗證器直接執行，因此它享有 (zk)EL 客戶端多樣性並提供 EVM 等效性，該等效性在構造上無錯誤，並且與通過 L1 硬分叉進行的 EVM 升級向前兼容。對於希望完全繼承以太坊安全性的 EVM 等效匯總，像 EXECUTE 預編譯這樣的 EVM 自省形式是必要的。我們將完全繼承以太坊安全性的匯總稱為「無需信任的匯總」。
EXECUTE 預編譯大大簡化了 EVM 等效匯總的開發，因為無需複雜的基礎設施（例如防欺詐遊戲、SNARK 電路、安全委員會）即可進行 EVM 模擬和維護。使用 EXECUTE，只需幾行 Solidity 代碼，使用簡單的派生函數即可部署最小的原生匯總和基於匯總，從而無需對排序、強制包含或治理進行特殊處理。
最重要的是， 原生匯總可以享受實時結算，而無需擔心實時證明，從而大大簡化了同步可組合性。
本文分為兩部分，首先介紹擬議的預編譯，最後討論原生匯總。
第 1 部分 — EXECUTE 預編譯
結構
EXECUTE 預編譯接受輸入 pre_state_root、post_state_root、trace 和 gas_used。若且唯若滿足以下條件時，它才返回 true：
-
trace 是格式良好的執行跟蹤（例如 L2 交易列表和相應的狀態訪問證明）
-
trace 的無狀態執行從 pre_state_root 開始，在 post_state_root 結束
-
trace 的無狀態執行恰好消耗 gas_used gas
有一種 EIP-1559 式機制，用於計量和定價 L1 區塊中所有 EXECUTE 調用所消耗的累計 gas。具體來說，有一個累計 gas 限制 EXECUTE_CUMULATIVE_GAS_LIMIT，以及一個累計 gas 目標 EXECUTE_CUMULATIVE_GAS_TARGET。（當 L1 EVM 可由驗證者無狀態執行時，累計限制和目標可以與 L1 EIP-1559 機制合併。）
調用預編譯需要花費固定數量的 L1 gas、EXECUTE_GAS_COST，加上 gas_used * gas_price，其中 gas_price（以 ETH/gas 計價）由 EIP-1559 式機制設置。即使預編譯返回 false，也會提取全額預付款。
跟蹤必須指向來自調用數據、blob、狀態或內存的可用以太坊數據。
重新執行
如果 EXECUTE_CUMULATIVE_GAS_LIMIT 足夠小，驗證器可以簡單地重新執行跟蹤以強制執行 EXECUTE 調用的正確性。基於重新執行的預編譯的初始部署可以作為墊腳石，類似於原始 danksharding 的簡單重新下載 blob 到完整 danksharding。請注意，簡單的重新執行不會給驗證器帶來狀態增長或帶寬開銷，並且任何執行開銷都可以在 CPU 核心之間並行化。
驗證器必須持有跟蹤的明確副本以進行重新執行，從而防止使用通過 DAS 採樣（而不是下載）的 blob 數據的指針。請注意，樂觀的本機匯總可能仍會以 blob 的形式發布匯總數據，僅在欺詐證明遊戲中回退到調用數據。還要注意的是，樂觀的原生匯總可以具有遠遠超過 EXECUTE_CUMULATIVE_GAS_LIMIT 的 gas 限制，因為 EXECUTE 預編譯只需要在小型 EVM 段上調用一次即可解決欺詐證明挑戰。
作為歷史記錄，2017 年 Vitalik 提出了類似的「EVM inside EVM」預編譯 ，稱為 EXECTX。
通過 SNARK 執行
要解鎖較大的 EXECUTE_CUMULATIVE_GAS_LIMIT，自然會讓驗證者選擇性地驗證 SNARK 證明。從現在開始，我們假設一個時隙延遲執行，其中無效塊（或無效交易）被視為無操作。（有關延遲執行的更多信息，請參閱此 ethresearch 帖子、此 EIP 和 Francesco 的此設計 。）一個時隙延遲執行會產生幾秒鐘（整個時隙）用於證明。它們還避免激勵 MEV 驅動的證明競賽，這將引入集中化向量。
請注意，即使 EXECUTE 由 SNARK 強制執行，也沒有明確的證明系統或電路被納入共識。（請注意，EXECUTE 預編譯不會將任何明確的證明作為輸入。）相反，每個質押操作員都可以自由選擇他們最喜歡的 zkEL 驗證器客戶端，類似於今天主觀選擇 EL 客戶端的方式。下一節「鏈下證明」將解釋此設計決策的好處。
從現在開始，我們假設執行提議者在具有交替執行和共識時隙的證明者-提議者分離 (APS) 的背景下是成熟的。為了激勵理性的執行提議者及時生成證明（在 1 個時隙內），我們要求證明者僅在執行塊 n 的證明可用時才證明執行塊 n+1。（我們建議在 p2p 層將塊 n+1 與塊 n 的 EXECUTE 證明捆綁在一起。）跳過證明的執行提議者可能會錯過他們的時隙，導致錯過費用和 MEV。我們進一步對錯過的執行時隙施加固定懲罰，將其設置得足夠高（例如 1 ETH）以始終超過證明的成本。
請注意，在 APS 的背景下，共識塊的生成不會因錯過的執行時隙而受阻。然而，及時生成證明對於輕客戶端來說很重要，這樣他們就可以在鏈端輕鬆讀取狀態，而無需無狀態重新執行。為了確保及時為輕客戶端生成證明，即使在下一個執行提議者錯過其時隙的特殊情況下，我們也依賴於利他少數證明者假設。單個利他證明者足以在 1 個時隙內生成證明。為了避免不必要的冗餘證明，大多數利他證明者可以等待待命，並且僅在 1 個時隙內沒有證明到達時才啟動，從而充當最多 2 個時隙延遲的故障安全措施。
請注意，EXECUTE_CUMULATIVE_GAS_LIMIT 需要設置得足夠低，以使利他少數證明者假設可信（以及使執行提議不會不切實際地複雜化）。保守的策略可以是設置 EXECUTE_CUMULATIVE_GAS_LIMIT，以便筆記本電腦（例如高端 MacBook Pro）可以訪問單時隙證明。更務實和積極的政策可能是瞄準一小部分 GPU，並且一旦它們充分商品化，最終可能會瞄準 SNARK ASIC 證明器。
鏈下證明
重申一下，我們建議不要將 zkEL EXECUTE 證明放在鏈上，而是在鏈下共享。不保存證明是一個好主意，由 Vitalik 首次提出，它有幾個優點：
-
多樣性： 驗證者可以自由地從他們信任的開發團隊中選擇證明驗證器（包括證明系統和電路），類似於驗證者選擇他們信任的 EL 客戶端的方式。這通過多樣性提供了穩健性。zkEL 驗證器客戶端（以及一些客戶端的基礎 zkVM）是複雜的加密軟體。任何一個客戶端中的錯誤都不應該導致以太坊崩潰。
-
中立性： 擁有 zkEL 驗證器客戶端市場允許共識層不選擇技術贏家。例如，zkVM 市場競爭激烈，選擇獲勝供應商（如 Risc0、Succinct 或許多其他供應商）可能不會被視為中立。
-
簡單性： 共識層不需要包含特定的 SNARK 驗證器，從而大大簡化了共識層的規範。只需包含狀態訪問證明的格式，而不是特定的證明驗證器實現細節。
-
靈活性： 如果發現錯誤或優化，受影響的驗證者可以更新他們的客戶端，而無需硬分叉。
擁有鏈下證明確實會帶來一些可控的複雜情況：
-
證明負載和 p2p 碎片化： 由於沒有單一的規範證明，因此需要生成多個證明（每個 zkEL 客戶端至少一個）。每個 zkEL 客戶端定製（例如將一個 RISC-V zkVM 換成另一個）都需要不同的證明。同樣，每個 zkEL 版本升級都需要不同的證明。這將導致證明負載增加。如果每個證明類型都有單獨的八卦渠道，它還會進一步碎片化 p2p 網絡。
-
少數 zkEL： 很難激勵少數 zkEL 生成證明。理性執行提議者可能只會生成足夠的證明，以達到絕大多數證明者，而不會錯過他們的時段。為了解決這個問題，可以從社會上鼓勵質押運營商並行運行多個 zkEL 客戶端，類似於今天的 Vouch 運營商。運行 k-of-n 設置還有提高安全性的額外好處，特別是可以防止健全性漏洞，這種漏洞允許攻擊者為任意 EXECUTE 調用製作證明（這種情況對於傳統的 EL 客戶端來說並不常見）。
鏈下證明還會降低實時結算 L2 的效率：
-
無替代 DA： 由於 EXECUTE 的跟蹤輸入需要提供給 L1 驗證者，因此實時結算的 L2（即立即更新其規範狀態根的 L2）必須消耗 L1 DA，即匯總。請注意，通過欺詐證明遊戲延遲結算的樂觀 L2 沒有此限制，即可以是有效值。
-
狀態訪問開銷： 由於跟蹤必須是無狀態可執行的，因此它必須包括讀取或寫入的狀態 trie 葉子，這比典型的 L2 塊引入了少量 DA 開銷。請注意，樂觀 L2 沒有此限制，因為僅在欺詐證明挑戰中才需要狀態 trie 葉子，挑戰者可以重新計算 trie 葉子。
-
無狀態差異： 由於給定跟蹤，證明應該是無需許可的，因此無法進行匯總狀態差異。但是，如果相應的專門證明被納入共識，則可以壓縮無狀態訪問證明或 EVM 交易籤名。
RISC-V 原生執行
鑑於當今事實上向 RISC-V zkVM 的趨同，可能有機會將 RISC-V 狀態轉換本地暴露給 EVM（類似於 Arbitrum Stylus 環境中的 WASM）並保持 SNARK 友好性。
第 2 部分 — 原生 Rollup
命名
我們首先討論原生 Rollup 的命名，以解決幾個容易引起混淆的問題：
-
替代名稱： 原生匯總以前被稱為 enshrined 匯總。（術語「規範匯總」也曾在 Polynya 12 中短暫使用過。）術語「enshrined」後來被放棄，取而代之的是「原生」，以表明現有的 EVM 等效匯總可以選擇升級為原生。「原生」這個名字是 Dan Robinson 和一位希望保持匿名的 Lido 貢獻者於 2022 年 11 月獨立提出的。
-
基於匯總： 基於匯總和原生匯總是正交概念：「基於」與 L1 排序有關，而「原生」與 L1 執行有關。同時基於和原生的匯總被異想天開地稱為「超音速匯總」。
-
執行分片： 執行分片（即 L1 EVM 鏈的 enshrined 副本）是一個與原生匯總相關的不同但相關的概念，比原生匯總早幾年。 （執行分片之前是以太坊 2.0 路線圖的「第 2 階段」。）與原生 rollup 不同，執行分片不可編程，即沒有自定義治理、自定義排序、自定義 gas 代幣等選項。執行分片通常也以固定數量實例化（例如 64 或 1,024 個分片）。不幸的是，Martin Köppelmann 在 2024 年 Devcon 上關於執行分片的演講中使用了「原生 L2」一詞 7。
好處
Native Rollups 有幾個好處，我們將在下面詳細介紹：
-
簡單性： 原生 rollup VM 的大部分複雜性都可以通過預編譯來封裝。如今，與 EVM 相當的 optimism 和 zk-rollup 有數千行代碼用於其欺詐證明遊戲或 SNARK 驗證器，這些代碼可以壓縮為一行代碼。原生 rollup 也不需要輔助基礎設施，如證明網絡、瞭望塔和安全委員會。
-
安全性： 構建無錯誤的 EVM 欺詐證明遊戲或 SNARK 驗證器是一項非常困難的工程任務，可能需要深度形式驗證。如今，每個 optimism 和 zk EVM rollup 在其 EVM 狀態轉換函數中都很可能存在嚴重漏洞。為了防範漏洞，集中排序通常被用作控制對抗性區塊生產的拐杖。原生執行預編譯允許安全部署無需許可的排序。完全繼承 L1 安全性的無需信任的 rollup 還完全繼承了 L1 資產可互換性。
-
EVM 等效性： 如今，rollup 與 L1 EVM 規則保持同步的唯一方法是讓治理（通常是安全委員會和/或治理代幣）鏡像 L1 EVM 升級。（EVM 更新仍然通過大約每年一次的硬分叉定期進行。）治理不僅是一種攻擊媒介，嚴格來說，它背離了 L1 EVM，並阻止任何 rollup 實現真正的長期 EVM 等效性。另一方面，原生 rollup 可以與 L1 同步升級，無需治理。
-
SNARK gas 成本： 在鏈上驗證 SNARK 的成本很高。因此，許多 zk-rollup 很少結算以儘量降低成本。由於 SNARK 未在鏈上驗證，因此可以使用 EXECUTE 預編譯來降低驗證成本。如果使用 SNARK 遞歸對一個塊中多個調用的 EXECUTE 證明進行批處理，則 EXECUTE_GAS_COST 可以設置得相對較低。
-
同步可組合性： 如今，與 L1 的同步可組合性需要同槽實時證明。對於 zk rollups 來說，實現超低延遲證明（例如 100 毫秒左右）是一項特別具有挑戰性的工程任務。使用單槽延遲狀態根，可以將本機執行預編譯的證明延遲放寬到一個完整槽。
