2026 年 6 月 25 日与 26 日，Base 主网接连发生两次区块生产中断，分别持续约 116 分钟和 20 分钟。Base 官方在事后复盘报告中确认，事件未造成链上资产损失或用户资金风险，所有资产始终处于安全可控状态。本文详细梳理故障根因、影响范围及修复进展。
故障根因：序列器状态管理 Bug
两次中断的根源指向序列器（sequencer）区块构建逻辑中的一处缺陷。Base 采用的 OP Stack 架构中，序列器负责将 L2 交易打包并提交至 L1。在 6 月 25 日的案例中，一笔交易执行失败后，系统未能正确清理历史 journal 状态，导致后续合法交易在执行时 gas 计算产生异常。这种异常使得序列器生成了无效状态转移区块，进而触发整条 L2 网络停止出块。官方指出，该问题本质上是序列器状态管理中未覆盖的边缘情况。
中断期间网络表现与影响
在两次停机期间，Base 主网出现了以下典型症状：区块生产完全停止、交易无法被打包上链、内存池（mempool）迅速拥堵。用户提交的 eth_sendRawTransaction 请求持续返回错误，网络实际处于不可用状态。虽然 L1 上的桥接合约仍然正常，但 L2 的区块生产停滞使得任何跨链操作也无法被确认。值得注意的是，由于停机发生在 UTC 时间上午（亚洲晚间），对亚洲用户影响相对较小，但部分 DApp 仍出现了服务降级。
修复过程与次日复现的间接原因
Base 开发团队迅速定位问题，并提交了补丁 PR #3806，修正了 journal 状态清理逻辑。该补丁部署后，25 日的区块生产得以恢复。然而，在序列器集群重启过程中，存在一个引擎重置的竞态条件（race condition），导致部分节点状态同步受阻。尽管主要 bug 已被修复，但重启流程的不完善使得 26 日再次出现了短暂停机。第二次停机仅持续 20 分钟，团队通过手动干预快速恢复了网络。
后续行动计划
为避免类似事件重演，Base 宣布将重点强化协议级模糊测试（fuzz testing）与压力测试能力，以更早发现异常交易路径。同时，升级监控与运维体系，并在序列器层面引入更优雅的恢复机制（graceful recovery），提升网络在类似故障中的快速自愈能力。此外，团队还计划优化重启流程，消除竞态条件隐患。此次事件再次提醒 Layer2 社区，序列器的单点故障风险与状态管理的精细化至关重要。