Base表示相同的排序器漏洞導致了6月25日和26日的停機。

Base 解釋了為何其主網在兩天內兩次停止生產區塊

摘要

• Base 的最新事後分析顯示，同一個排序器錯誤導致主網在連續兩天內兩次停機。
• 資金保持安全，但交易隊列因 Base 暫時停止生產新的 L2 區塊而溢出。
• 團隊計劃在停機後加強模糊測試、負載測試、監控和恢復工具。

這個由 Coinbase 支持的以太坊二層網路表示，兩次停機均由排序器區塊構建邏輯中的同一個錯誤導致。

第一次停機於 6 月 25 日開始，持續約 116 分鐘。第二次於 6 月 26 日開始，持續約 20 分鐘。Base 表示資金在兩次事件中均保持安全。

排序器錯誤停止區塊生產

在官方事後分析中，Base 表示一筆無效交易在執行期間按預期失敗。問題出現在失敗之後，當時陳舊的日誌狀態仍留在區塊構建器內。

6 月 25 日和 26 日，Base 主網經歷了兩次區塊生產停機，均由區塊構建器邏輯中的同一個底層錯誤導致。

我們已識別並修復了根本原因，並將事後分析作為反饋傳達給 OP 鏈。

所有資金都是安全的… pic.twitter.com/eArnK12AgZ

— Base Build (@buildonbase) 2026 年 6 月 27 日

該陳舊狀態包含受失敗交易影響的帳戶和存儲槽。當下一筆有效交易到來時，系統使用了錯誤的日誌狀態，並不正確地收取 gas。

這創建了一個帶有無效狀態轉換的區塊。其他節點無法接受該區塊，因此鏈停止生產新的 L2 區塊。

“鏈的完整性未受損害，Base 上的所有資金都是安全的，”Base 表示。

團隊補充說，在緩解措施後區塊生產安全恢復。

停機期間交易排隊

在停機期間，用戶無法讓新交易上鏈。Base 表示，交易在 mempool 中排隊，同時鏈等待區塊生產恢復。

交易池後來增長到超過其存儲能力。結果，在停機窗口期間，新的 eth_sendRawTransaction 請求返回錯誤。

停機也影響了排序器和驗證者的進度。Base 表示，這些節點在排序恢復之前無法越過無效區塊。

正如先前報導，Base 於 6 月 25 日首次標記了不健康的區塊生產，之後工程師隔離了一個與無效區塊相關的共識問題。

補丁修復了陳舊狀態問題

Base 表示通過應用排序器補丁修復了主要錯誤。該補丁確保在失敗交易後，執行期間的日誌狀態正確更新。

團隊還在恢復過程中發現了第二個問題。Base 表示緩解措施花費更長時間，因為引擎重置功能中的競態條件阻止了排序器在重啟後追上進度。

這第二個問題有助於解釋為何事件在第二天再次發生。Base 表示該問題影響排序器而非驗證節點，但仍減緩了恢復速度。

Base 狀態頁面顯示排序於 6 月 25 日恢復。它還告知生態系統節點運營商，如果他們的節點仍卡住，請重啟 Base 節點。

計劃進行測試和恢復變更

Base 表示將加強協議模糊測試和負載測試。這些方法有助於團隊發現可能暴露隱藏錯誤的奇怪交易模式。

團隊還計劃更好的監控和運營檢查。它表示這些變更應能幫助工程師更早檢測類似問題並更快回應。

Base 還希望為 base-consensus 添加優雅恢復功能。該變更將使驗證節點在類似失敗後更容易繼續同步。

此次停機發生在該網路繁忙的一週。Base 還推進了其 Beryl 升級，該升級新增 B20 代幣標準，並將標準的 Base 到以太坊提款期從七天縮短至五天。

該事件讓開發者和用戶更清楚地看到弱點所在。Base 現在已指出該錯誤、發布補丁，並列出了計劃改進的測試。