根據 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) 都用呢個設計,但佢明顯係一個單點故障。
事後報告同業界報導提出咗幾個重點關注:
呢件事顯示咗,就算係最大嘅以太坊 L2 網絡,都可能因為一個單一排序器嘅狀態管理邊緣案例而停擺——而自動故障切換同復原系統,喺成個 rollup 生態入面仍然係有待完善嘅領域。