2024年6月25日和26日，基于OP Stack构建的L2网络Base主网先后经历了两次区块生产中断，分别持续约116分钟和20分钟。6月28日，Base官方发布了详细的事后复盘报告（Postmortem），明确指出此次事件未影响链上资产安全，用户资金始终处于可用状态。
事件概况
据Base官方披露，第一次停机发生于UTC时间6月25日13:30左右，持续约116分钟；第二次停机发生于6月26日14:10左右，持续约20分钟。两次事件均为全网范围的区块生产停止，导致用户无法提交交易。Base团队在发现问题后迅速定位并部署了修复补丁。
根因分析：序列器状态管理缺陷
复盘报告指出，故障的直接原因是序列器（sequencer）的区块构建逻辑存在缺陷。在交易执行失败后，系统未能正确清理历史journal状态，使得后续合法交易在执行时错误地重复使用了前一次失败交易的gas计算结果，从而生成了无效的状态转移区块。该无效块被广播至网络后，导致整个L2网络共识停滞、停止出块。
中断期间网络表现与用户影响
在两次中断期间，Base主网出现了以下异常表现：区块生产完全停止；交易无法被纳入区块；mempool（交易内存池）出现拥堵；用户通过eth_sendRawTransaction提交的交易请求持续返回错误提示。官方强调，尽管网络不可用，但所有已确认的链上资产均安然无恙，用户资金无需担心。
修复过程与二次停机原因
第一次中断发生后，Base工程师紧急开发了补丁PR #3806，通过修正journal状态清理逻辑解决了区块构建问题，并成功重启序列器恢复了区块生产。然而，在序列器集群的重启过程中，存在一个引擎重置的竞态条件（race condition），导致部分节点未能正确同步状态，从而在次日再次触发短暂停机。Base已针对该竞态条件另行修复。
未来改进方向
为提升网络的鲁棒性，Base宣布将采取以下三项关键措施：一是强化协议级的模糊测试（fuzz testing）与压力测试能力，力求在异常交易路径导致故障之前将其捕获；二是升级监控与运维体系，实现更快的异常检测和响应；三是引入更加优雅的恢复机制（graceful recovery），使网络在遭遇类似故障时能够自动回滚到健康状态并快速恢复生产，减少停机时间。