讀懂 Bedrock：Optimism 落子佈局 Rollup 生態的第一步

原文標題：《Bedrock Explainer》

撰文：Optimism 官方

編譯：Frank，Foresight News

Bedrock 是 OP Stack 有史以來第一個正式版本的名稱，作為一組免費和開源的模組化組件，它旨在為 Optimism 的發展提供動力。

改進總結

Bedrock 在其前身的基礎上進行了改進，主要包含：

• 使用經過優化的批量交易壓縮以及將以太坊作為數據可用性層，從而降低交易費用；
• 通過更好地處理 L1 重組，縮短了將 L1 交易打包到 rollups 中的延遲；
• 通過代碼重用來啟用模組化證明系統；
• 通過消除設計負債來提高節點性能。

更低的費用

Bedrock 使用了經過優化的數據壓縮策略，以最大限度地降低數據成本。我們目前正在對這一變化的影響進行基準測試，但我們預計它將大幅降低費用。

Bedrock 還消除了向 L1 提交數據時與 EVM 執行相關的所有 Gas 成本，與之前版本的協議相比，這將額外減少 10% 的費用。

更短的存款入賬時間

Bedrock 在節點軟件中引入了對 L1 重組的支持，這大大減少了用戶等待存款入賬所需的時間。

該協議的早期版本最多可能需要 10 分鐘來確認存款入賬，而使用 Bedrock 後，我們預計存款會在 3 分鐘內確認入賬。

改進的模組化證明

Bedrock 從 OP Stack 中抽象出了證明系統，以便 rollup 可以使用故障證明或有效性證明（例如 zk-SNARK）來證明在 rollup 上輸入後的正確執行，這種抽象也將允許使用 Cannon 來證明系統中的故障。

改進的節點性能

通過在單個 rollup「區塊」中執行多筆交易，而不是之前版本中「每個區塊一筆交易」的模型，節點軟件性能因此得到了顯著提高。

這使得 Merkle Trie 更新的成本能在多筆交易中進行分攤，在當前的交易量下，這會使狀態數據的增長幅度每年減少大約 15GB。

通過消除之前版本的協議中的技術負債，節點性能也得到進一步提高，這包括不再需要一個單獨的「數據傳輸層」節點來為 L1 編制索引，並更新節點軟件以有效地查詢來自 L1 的交易數據。

改進的以太坊等效性

Bedrock 從一開始就被設計成盡可能與以太坊「一致」，先前版本協議中與以太坊的多項偏差已被消除，包括：

• 「每個區塊一筆交易」的模型；
• 自定義操作碼以獲取 L1 的區塊信息；
• 在 JSON-RPC API 中分離 L1/L2 費用字段；
• ETH 餘額的自定義 ERC20 表示形式。

Bedrock 還增加了對 EIP-1559、區塊鏈重組和 L1 上存在的其他以太坊功能的支持。

設計原則

Bedrock 被構建為模組化和可升級的設計，同時可以重用以太坊的現有代碼，並盡可能達成 100% 以太坊等效的目標。

模組化

通過使用定義良好的接口和版本控制方案，Bedrock 可以輕鬆地更換 OP 堆棧中的不同組件，並添加新功能。

這就允許其借助一個靈活的架構，適應以太坊生態系統的未來發展，例如：

• rollup 節點與執行客戶端分離；
• 模組化防故障設計。

代碼重用

Bedrock 儘可能地使用現有的以太坊架構和基礎設施，這種方法使 OP Stack 能夠從以太坊主網使用的經過實戰測試的代碼庫中繼承安全性和林迪效應（Lindy effect）優勢。

您會在整個設計中找到這樣的示例，包括：

• 最少修改的執行客戶端；
• EVM 合約而不是預編譯的客戶端代碼。

以太坊等效性

Bedrock 旨在最大程度地兼容現有的以太坊開發人員體驗，但由於 L1 和 rollup 之間的根本差異，也存在一些例外情況：費用模型的不同、更快的出塊時間（2 秒 vs 12 秒）以及包含 L1 存款交易的特殊交易類型。

這些例外情況包括：

• 旨在證明最小修改的以太坊執行客戶端的故障證明；
• 以太坊執行客戶端的代碼重用，以供 L2 網絡中的節點和排序器使用。

協議

Rollups 建立在數據可用性的基礎上（通常是像以太坊這樣的 L1 區塊鏈），在最常見的配置中，rollup 協議從兩個主要信息來源派生出「規範的 L2 鏈」：

• 交易數據由定序器（Sequencer）發布到 L1；
• 存款交易由賬戶和智能合約提交到 L1 上的橋接合約。

以下是該協議的基本組成部分：

• 通過直接與 L1 上的智能合約交互，將存款寫入「規範的 L2 鏈」；
• 提款是寫入「規範的 L2 鏈」，並隱式觸發與 L1 上智能合約和賬戶的交互；
• Batches 是與 rollup 上的 batches 相對應的數據寫入；
• 區塊推導是如何解釋 L1 上的數據讀取以理解「規範的 L2 鏈」；
• 證明系統定義了 L1 上發布的輸出根的最終性，以便它們可以被執行（例如執行提款）。

存款

存款是 L1 上的一筆交易，並將包含在 rollup 中。根據定義，存款被保證包含在「規範的 L2 鏈」中，作為防止審查或控制 L2 的一種手段。

從 L1 傳遞的任意消息

存款交易是作為存款的一部分進行的 rollup 交易。通過 Bedrock，存款是完全通用的以太坊交易，例如以太坊上的賬戶或智能合約可以創建「存款」合約。

Bedrock 定義了一個在 L1 上可用的存款合約：它是一個智能合約，L1 賬戶和智能合約可以與之交互以寫入 L2。L2 上的存款交易是從該存款合約發出的交易中派生出來的，其中包括預期參數，例如 from、to 和 data。

有關詳細信息，請參閱存款合約協議規範部分。

在 L1 上購買有擔保的 L2 Gas

Bedrock 還明確了 Gas 燃燒機制和存款費用市場，存款交易在 L2 上花費的 Gas 是通過 Gas 燃燒在 L1 上購買的。

這種 Gas 具體是在費用市場上購買的，並且在單個 L1 區塊中提供給所有存款交易的 Gas 總量有一個硬性上限，該機制用於防止拒絕服務攻擊（DoS），這種攻擊可能發生在將交易從 L1 寫入 L2 時，因為這些交易在 L2 上耗費大量 Gas，但在 L1 上卻很便宜。

提供給存款交易的 Gas 有時被稱為「有擔保的 Gas」（Guaranteed Gas）。Guaranteed Gas 的獨特之處在於它是通過在 L1 上燃燒 Gas 來支付的，因此是不可退還的。

且每單位有擔保的 L2 Gas 所要求的必須燃燒的 L1 Gas 總量，取決於 EIP-1559 式收費機制報告的 L2 Gas 價格。此外，用戶根據計算費用機制更新所花費的 L1 Gas 數量獲得動態 Gas 津貼。

如需更深入的解釋，請閱讀存款部分的協議規範。

提款

提款是在 L2 上發起並由在 L1 上執行的交易完成的跨層交易。值得注意的是，L2 賬戶可以使用提款來調用 L1 合約，或將 ETH 從 L2 賬戶轉移到 L1 賬戶。

提款是通過在 L2 上調用 Message Passer 預部署合約啟動的，該合約在其存儲中記錄了消息的重要屬性，然後通過調用 OptimismPortal 合約在 L1 上完成提款，以證明包含此提款消息。

這樣，提款和存款就不一樣了：提款交易必須使用 L1 上的智能合約來完成，而不是依賴於區塊派生出來的信息。

分兩步的提款過程

提款證明驗證錯誤是過去幾年許多跨鏈橋黑客攻擊事件的根本原因。Bedrock 版本在先前版本的提款過程中引入了一個額外的步驟，旨在為這些類型的錯誤提供額外的防禦設計。

在分兩步的提款過程中，每次提款必須在最終退出前 7 天提交與提款對應的 Merkle 證明，這種新的安全機制給了監控工具整整 7 天的時間來查找和檢測無效的提款證明。

在此期間如果發現提款證明無效，就可以在資金丟失之前部署智能合約修復，這大大降低了跨鏈橋妥協的風險。

有關詳細信息，請參閱提款協議規範部分。

批次交易（Batches）

在 Bedrock 中，為 L1 和 L2 之間的消息傳遞定義了一種有線格式（即 L2 從 L1 派生區塊，L2 將交易寫入 L1），這種有線格式的設計目的是將寫入 L1 的成本和軟件複雜性降到最低。

優化數據壓縮

為了優化數據壓縮， L2 交易列表（被稱為 sequencer batches）被組織到對象組（稱為 channel）中，每個 channel 的最大規模能夠在可配置參數中定義，最初將設置為 9.5 M，這些 channel 預計將使用壓縮功能進行壓縮並提交給 L1。

batch 並行提交

為了並行化來自向 L1 提交壓縮 channel 數據的定序器消息，channel 被進一步分解為「channel frames」，這些「channel frames」是可以適合單個 L1 交易的壓縮 channel 數據塊。

假設「channel frames」是相互獨立的，並且順序是已知的，那麼由定序器發送到 L1 的以太坊交易可以並行發送，從而最大限度地降低了定序器軟件的複雜性，並允許填充 L1 上所有可用的數據空間。

最小化以太坊 Gas

Bedrock 刪除了 L1 系統在稱為「batcher transactions」的交易中向 L1 提交 channel 數據所使用的所有執行 Gas。之前發生在 L1 智能合約上的所有驗證邏輯都被移動到了區塊派生邏輯中。相反，「batcher transactions」被發送到以太坊上的單個 EOA 地址，稱為「batch inbox address」。

Batches 仍需接受有效性檢查（即它們必須正確編碼），batche 中的單個交易也是如此（例如簽名必須有效），無效 batches 和有效 batches 中的無效單個交易被視為被丟棄並且與系統無關。

注意：以太坊將很快升級包含 EIP-4844 的新版本，它引入了一個單獨的數據寫入費用市場，並增加了以太坊協議願意存儲的數據量上限，這一變化有望進一步降低與將數據發布到 L1 相關的成本。

如需更深入的解釋，請閱讀有線格式規範。

區塊派生

在 Bedrock 中，該協議的設計旨在保證 L1 上存款的時間與「規範 L2 鏈」的區塊派生有關。這樣做是通過定序器、存款和 L1 區塊屬性將數據寫入 L1 的純函數。

為了實現這一點，該協議定義了保證存款入賬、處理 L1 和 L2 時間戳以及處理 channel 中的排序窗口以確保正確排序的策略。

保證存款入賬

區塊派生協議的目標是這樣進行定義的：

每個「L2 區塊間隔」過去後，必須有一個 L2 區塊，且 L2 區塊的時間戳與 L1 的時間戳保持同步（即確保存款包含在邏輯時間順序中）。

在 Bedrock 中，引入了「sequencing epoch」的概念：它是由一系列 L1 區塊派生出來的 L2 區塊的範圍，每個 epoch 由一個「epoch number」標識，該「epoch number」等於排序窗口中第一個 L1 區塊的區塊序號。受一些限制，epoch 的大小可以有所不同。

batch 派生 channel 將與「epoch number」相關聯的 L1 區塊的時間戳視為確定 L2 上交易順序的錨點。該協議保證一個 epoch 的第一個 L2 區塊永遠不會落後於所匹配 epoch 的 L1 區塊的時間戳。一個 epoch 的第一個區塊必須包含 L1 上的存款，以保證存款將被處理。

請注意，在 Bedrock 版本中，L2 上的區塊間隔目標配置為 2 秒。

處理 L1 和 L2 時間戳

Bedrock 試圖解決將 L2 上時間戳與存入交易中存在的 L1 上時間戳進行協調的問題。

它通過允許一個很短的時間窗口來進行排序，以便在 epoch 之間的 L2 交易上自由應用時間戳來實現這一點。

排序窗口（sequencing window）是 L1 區塊的序列，從中可以導出 epoch。一個排序窗口中，其第一個 L1 區塊的編號 N 包含 epoch 的「batcher transactions」。

排序窗口包含區塊，其中取決於排序窗口的大小：一個固定的 rollup 級別配置參數必須至少為 2，增加它會為定序器提供了更多關於存款的 L2 交易排序機會，降低它為定序器提交「batcher transactions」引入的更嚴格時間窗口。這是在創造 MEV 機會和增加軟件複雜性之間的權衡。

稱為「最大定序器漂移」（max sequencer drift）的協議常量控制一個區塊在其 epoch 內可以具有的最大時間戳，有了這種漂移，定序器就可以在連接到 L1 出現臨時問題時保持活躍。

區塊派生管道

「規範的 L2 鏈」可以從頭開始處理，方法是從 L2 創世狀態開始，將 L2 鏈起始設置為第一個 epoch，然後處理所有排序窗口，以便根據以下簡化的順序確定定序器 batches 和存款的正確順序管道：

故障證明

在定序器處理一個或多個 L2 區塊後，從這些區塊中執行交易計算得出的輸出將需要用 L1 寫入，以實現 L2 到 L1 消息傳遞的無信任執行，例如提款等。

在 Bedrock 中，輸出以樹形結構的形式進行哈希處理，從而最大限度地降低了證明輸出捕獲的任何數據片段的成本。提議者定期向 L1 提交作為整個「規範 L2 鏈」的 Merkle 根的輸出根。

OP Stack 的未來升級應該包括一個故障證明變體的規範，其中包含綁定，以激勵提議者提出正確的輸出根。

有關完整詳細信息，請閱讀 L2 輸出根提案部分的協議規範。

執行

在 Bedrock 中，OP Stack 通過鏡像以太坊執行層和共識層之間的分離，在很大程度上不得不依賴於以太坊指定的技術關注點分離。

所以 Bedrock 以同樣的方式引入了執行客戶端和 rollup 節點的分離。

執行客戶端

執行客戶端是定序器和其他類型的節點操作員運行以確定「規範 L2 鏈」狀態的系統。它還執行其他功能，例如處理入站交易和點對點通信，以及處理系統狀態以處理針對它的查詢。

借助 Bedrock，OP Stack 旨在重用以太坊自己的執行客戶端規範及其許多執行操作。在此版本中，Bedrock 展示了對以太坊客戶端 go-ethereum 的極其有限的修改，其差異小於 2000 行代碼。

存在差異的根本原因有兩個：處理存款交易和收取交易費用。

處理存款交易

為了在 rollup 中表示已存入的交易，引入了一種額外的交易類型。執行客戶端實現這個新的交易類型是根據 EIP-2718 類型的交易標準。

收取交易費用

Rollups 從根本上說還有兩種與交易相關的費用：

一個是定序器費用。使用與以太坊相同的 Gas 表和相同的 EIP-1559 算法計算操作定序器的成本，這些費用用於操作排序器的協議，並根據網絡擁堵情況隨時波動。

另一個數據可用性費用。數據可用性成本與將批次處理交易寫入 L1 相關，這些費用旨在支付定序器向 L1 提交批次交易所需支付的費用。

在 Bedrock 中，費用的數據可用性部分是根據稱為 GasPriceOracle 的 rollup 系統智能合約中的信息確定的，該智能合約在區塊派生過程中，是根據從每個 epoch 開始時插入的 L1 區塊屬性中檢索到的 Gas 價格信息進行更新。

Bedrock 指定在使用 JSON-RPC 時將這兩種費用加到一個字段中。

rollup 節點

與以太坊不同，Bedrock 沒有 PoS 共識。相反，「規範的 L2 鏈」的共識是由區塊派生定義的。OP Stack 的執行客戶端與一個新組件通信，該組件實現了稱為 rollup 節點的區塊派生，該節點使用與以太坊完全相同的引擎 API 與執行客戶端通信。

rollup 節點是一個無狀態組件，負責通過讀取 L1 上的數據和存款來推導系統的狀態。在 Bedrock 中，rollup 節點可用於對來自用戶或其他匯總節點的傳入交易進行排序，或者通過單獨依賴 L1 來驗證在 L1 上發布的已確認交易。

rollup 節點的多種用途概述如下：

驗證「規範的 L2 鏈」

運行 rollup 節點的最簡單模式是只遵循「規範的 L2 鏈」。在這種模式下，rollup 節點沒有對等節點，嚴格用於從 L1 讀取數據並根據區塊派生協議規則對數據進行解釋。

這種節點的一個目的是根據協議定義驗證由其他節點共享或發布在 L1 上的任何輸出根是否正確。此外，打算將輸出根提交給 L1 的提議者自己可以使用 optimism_outputAtBlock 生成他們需要的輸出根，並返回對應於 L2 輸出根的 32 字節哈希值。

為此，節點應該只需要跟隨「最終確定」（finalized）的區塊頭。術語「finalized」指的是以太坊 PoS 共識（即規範的且幾乎不可逆的），而「最終確定」的 L2 區塊頭是僅從「最終確定」的 L1 區塊派生的「規範 L2 鏈」的區塊頭。

參與 L2 網絡

使用 rollup 節點的最常見方法是參與其他 rollup 節點的網絡、跟蹤 L2 的進程和狀態。在這種模式下，rollup 節點同時讀取數據和它從 L1 觀察到的存款，將其解釋為區塊，並接受來自其他 rollup 節點網絡中的用戶和對等方的入站交易。

參與網絡的節點可以使用它們正在同步的 L2 的安全和不安全區塊頭。

• 安全的 L2 區塊頭表示可以構建的 rollup，其中每個區塊（包括頭部）都可以完全從參考 L1 鏈中導出，在 L1 必須「最終確定」之前（即重組可能仍然發生在 L1 上）；
• 不安全的 L2 區塊頭包括尚未從 L1 派生的不安全區塊。這些區塊要麼來自將 rollup 節點作為定序器操作，要麼來自不安全的同步與定序器。這也稱為「最新」區塊頭。在出現分歧的情況下，總是選擇安全的 L2 區塊頭而不是不安全的 L2 區塊頭。當出現分歧時，該鏈的不安全部分將重組；

在大多數情況下，對於終端用戶應用程序，L2 網絡中的 rollup 節點將引用不安全的 L2 區塊頭。

交易排序

使用 rollup 節點的第三種方法是對交易進行排序。在這種模式下，rollup 節點將在不安全的 L2 區塊頭之上創建新區塊。目前，每個 OP Stack 網絡只有一個定序器。

定序器還負責將批次交易發布到 L1，以便網絡中的其他節點從中同步。

Batcher

定序器的作用是生產批次交易，為此，排序器可以運行 rollup 節點並具有單獨的進程，這些進程通過從它們運行的​​受信任的 rollup 節點讀取來執行批處理。

這保證了 OP Stack 的一個附加組件，稱為批次交易處理程序，它從 rollup 節點讀取交易數據並將其解釋為要寫入 L1 的批處理交易，batcher 組件負責讀取由定序器運行的 rollup 節點的不安全 L2 區塊頭，創建 batcher 交易，並將它們寫入 L1。

標準橋接合約

Bedrock 還包括一對用於最常見類型存款的橋接合約，稱為標準橋接合約。這些合約封裝了存款和提款合約，為 ETH 和 ERC-20 代幣的存款和提款提供簡單的接口。

這些橋接合約的設計是在跨鏈橋的一側為本地代幣，另一側包含一個可以管理鑄造和銷毀的封裝代幣，橋接原生代幣涉及將原生代幣鎖定在合約中，然後在跨鏈橋的另一側鑄造等量的封裝代幣。

有關詳細信息，請參閱標準跨鏈橋協議規範部分。

Cannon

雖然在 Cannon 中實現了防故障構建和驗證，但故障證明遊戲規範和將輸出根挑戰者集成到 rollup 節點中是後續規範里程碑的一部分。

延伸閱讀

協議規範

協議規範定義了 OP Stack 的技術細節，它是協議內部運作的最新事實來源。

Bedrock 差異

要深入了解 Bedrock 與先前版本之間的差異，請參閱「Bedrock 有何不同」。