Base 網絡兩日死兩次：同一個排序器漏洞癱瘓區塊生產 136 分鐘

Coinbase 旗下嘅以太坊 Layer-2 網絡 Base，喺 2025 年 6 月 25 同 26 日短短 48 個鐘頭內發生咗兩次區塊生產中斷，成條鏈停咗總共 136 分鐘。 官方嘅事後調查報告指出，兩次事故嘅根源係同一個排序器入面嘅 bug，呢件事亦令到佢哋嘅單一排序器架構再一次成為討論焦點。

區塊建設邏輯出事

根據 Base 官方嘅事後報告，問題嘅根源係排序器嘅 區塊建設邏輯 (block-building logic) 出咗錯。 當一個交易執行失敗之後，系統冇正確清理 journal 狀態 (journal state) ——即係記錄帳戶同儲存位置變動嘅內部記錄——令到系統留低咗「過期」或者「污糟」嘅狀態。 之後當正常交易執行嗰陣，呢啲污糟狀態令到 gas 計算出錯，最終產生咗一個 狀態轉換無效 嘅區塊。

呢個無效區塊引發咗共識失敗：排序器喺產生區塊 47,806,542 之後就生咗個無效區塊出嚟，令到網絡冇辦法再產生新區塊。 節點運營商要等到問題解決咗先可以繼續正常同步。

兩次停機時間線

事件	日期	持續時間	總停機時間 (合計)
第一次	2025年6月25日	大約 116 分鐘 (差唔多兩個鐘)	大約 136 分鐘
第二次	2025年6月26日	大約 20 分鐘

6月26日第二次停機，官方話係同一類區塊生產問題喺第一次事件之後好短時間內又再出現，不過第二次復原得快啲。

喺兩次停機期間，新區塊冇辦法產生，影響咗正常嘅鏈上交易處理。不過，兩次事件中都冇用戶資金受影響。

部署咗嘅修補程式

Base 嘅工程團隊已經為排序器部署咗修補程式，確保喺交易執行失敗之後，journal 狀態會正常更新。 呢個修補程式可以喺公開嘅 GitHub pull request (#3806) 睇到。

修補程式上線之後，網絡恢復正常運作，但 Base 建議 驗證節點運營商重啟或者重新同步節點，以恢復同步狀態。 團隊指出，兩次停機都源於同一個 bug，而第二日再次出現事故係因為另一個相關嘅問題 (PR #3805)。

事件之後，Base 將原本計劃嘅 Beryl 主網升級 同 B20 代幣標準啟動 推遲咗一日，等網絡穩定返先再進行。

單一排序器架構：更大嘅隱憂

呢兩次連續嘅停機事件，再次引起對 Base 單一排序器設計 嘅討論。雖然好多樂觀卷軸 (optimistic rollup) 都用呢個設計，但佢明顯係一個單點故障。

事後報告同業界報導提出咗幾個重點關注：

• 單點故障 (single point of failure)：排序器級別嘅區塊建設邏輯 bug 就可以癱瘓 Base 成個區塊生產，令全網冇辦法產生新區塊。
• 人手復原：復原過程需要驗證節點運營商手動重啟或者重新同步節點，而唔係網絡自動修復。
• 穩定性風險：連續兩次故障，令人對呢個快速擴張嘅 L2 生態系統嘅可靠性產生疑問，特別係喺高流量或者計劃升級嘅時候。
• 計劃改善：Base 話會加強測試，包括 fuzz 測試、壓力測試、監控同更好嘅復原工具，以減低再次發生嘅機會。

呢件事顯示咗，就算係最大嘅以太坊 L2 網絡，都可能因為一個單一排序器嘅狀態管理邊緣案例而停擺——而自動故障切換同復原系統，喺成個 rollup 生態入面仍然係有待完善嘅領域。