Base 網路 48 小時內兩度停擺：排序器臭蟲引發 136 分鐘中斷，單一排序器架構安全性受質疑

Coinbase 旗下的以太坊 Layer-2 網路 Base 在 2025 年 6 月 25 及 26 日，48 小時內接連發生兩次區塊生產中斷，共計癱瘓 136 分鐘。 官方事後報告（post-mortem）指出，兩次事件源於網路排序器（sequencer）中的同一個底層臭蟲，此事件也再度將單一排序器架構的結構性風險推上風口浪尖。

區塊建構器中的臭蟲

根據 Base 的官方報告，問題的根源出在 排序器的區塊建構邏輯 上。 當一筆交易執行失敗後，系統並未妥善清理「日誌狀態」（journal state）——也就是記錄帳戶與儲存槽位變動的內部日誌——導致留下「過時」（stale）或「骯髒」（dirty）的狀態。 後續的合法交易在執行時，因為這個髒狀態而產生異常的 Gas 計算，最終生成一個帶有 無效狀態轉換 的區塊。

這個無效區塊隨即觸發共識失敗：排序器在第 47,806,542 號區塊之後產出了一個無效區塊，導致網路無法繼續產生任何新區塊。 節點運營商在問題解決之前，也無法順利同步。

兩次中斷的時間線

事件	日期	持續時間	總停機時間（合計）
第一次	2025 年 6 月 25 日	約 116 分鐘（將近 2 小時）	約 136 分鐘
第二次	2025 年 6 月 26 日	約 20 分鐘

6 月 26 日的第二次中斷被描述為同類型的區塊生產問題，在首次事件後不久再次發生，不過網路在第二次恢復的速度較快。

在兩次中斷期間，新區塊的生產完全停擺，正常鏈上交易處理也因此中斷。然而，官方強調 用戶資金在兩次事件中均未遭受風險。

已部署的修補程式

Base 的工程團隊為排序器部署了一個修補程式，確保交易執行失敗後，日誌狀態能被正確更新。 此修補程式可在公開的 GitHub Pull Request（編號 #3806）中查閱。

修補程式部署後，網路恢復正常運作。但 Base 建議 驗證節點運營商重啟或重新同步他們的節點，以恢復同步狀態。 團隊指出，兩次中斷均源於同一個臭蟲，而第二天事件再次發生的原因，則與另一個相關問題（PR #3805）有關。

事件發生後，Base 將原本計畫的 Beryl 主網升級 及 B20 代幣標準啟動 延後一天，以確保網路穩定。

單一排序器架構：更廣泛的隱憂

連續兩天的中斷，重新點燃了市場對於 Base 單一排序器設計 的討論。這種設計在許多 Optimistic Rollup 中相當常見，但也因此引入了明顯的單點故障風險。

官方報告及業界報導提出的主要擔憂包括：

• 單點故障：排序器層級的區塊建構邏輯臭蟲，就能癱瘓 Base 整個區塊生產流程，凍結全網的新區塊產出。
• 手動復原：事件發生後，網路無法自行修復，必須仰賴驗證節點運營商手動重啟或重新同步節點才能恢復。
• 可靠性風險：連續兩日故障，對於這個快速擴張的 Layer-2 生態系的可靠性，尤其是在高活躍度或重大升級期間的表現，提出了新的疑問。
• 未來改進方向：Base 表示將加強測試，導入 模糊測試（fuzz test）、壓力測試、監控系統以及更好的復原工具，以降低類似事件重演的機率。

這次事件顯示，即便是最大的以太坊 Layer-2 網路，也可能因為單一排序器中的一個狀態管理邊際案例（edge case）而癱瘓——而整個 Rollup 生態系中，自動化故障轉移與復原系統的發展，顯然仍在進行中。