以太坊研究員：原生rollups——來自L1 執行的超能力

作者：以太坊研究員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 毫秒左右）是一項特別具有挑戰性的工程任務。使用單槽延遲狀態根，可以將本機執行預編譯的證明延遲放寬到一個完整槽。