Base 网络在 48 小时内两次停止出块，累计宕机 136 分钟

一个“脏”状态引发的连锁故障

根据 Base 官方的事后分析，问题的根源出在 排序器的区块构建逻辑 上。 具体来说，当一笔交易在执行过程中失败后，系统没有正确地清理“日志状态”（journal state），即记录账户和存储槽位变动的内部账本。 这个未清理的、被称作“脏”（stale / dirty）的状态被保留了下来。 当后续的合法交易被执行时，这个“脏”状态导致了异常的 Gas 计算，最终生成一个 无效的状态转换区块。

这个无效的区块触发了共识失败：排序器在产生第 47,806,542 号 区块后，就再也无法生成新的有效区块，导致整个网络停止出块。 节点运营者无法继续正常同步，直到问题得到解决。

两次宕机时间线

6月26日的第二次宕机被描述为同类型出块故障在第一次事件后不久再次发生，但第二次网络恢复得更快。

在这两次宕机期间，新区块无法生成，导致正常的链上交易处理中断。然而，官方报告指出，用户的资金在这两次事件中均未受到威胁。

已部署的修复方案

Base 工程团队已对排序器进行了补丁修复，确保在交易执行失败后，日志状态能够得到正确更新。 该修复可以在公开的 GitHub Pull Request（#3806）中追踪到。

补丁部署后，网络恢复正常运行。但 Base 建议 验证节点运营者重启或重新同步他们的节点，以恢复同步状态。 团队指出，两次宕机均源于同一个 Bug，而另一个相关问题（PR #3805）则导致次日事故再次发生。

为了优先稳定网络，Base 决定将原定的 Beryl 主网升级 和 B20 代币标准激活 延后一天。

单一排序器架构：一个更深层的隐忧

此次连续宕机事件，重新点燃了业内对 Base 单一排序器设计 安全性与可靠性的讨论。这也是许多乐观汇总（Optimistic Rollup）的常见架构，但其明显的单点故障风险在此次事件中暴露无遗。

事后分析及行业报道提出的主要担忧包括：

• 单点故障：排序器级别的区块构建逻辑 Bug，足以让整个 Base 网络的出块陷入停滞，冻结所有新区块的生成。
• 人工恢复：网络恢复需要验证节点运营者手动重启或重新同步节点，而非由网络系统自动完成自我修复。
• 可靠性风险：连续两天的故障，让人们对这个快速扩展的 L2 生态系统的可靠性打上问号，尤其是在高活跃期或计划升级期间。
• 改进计划：Base 表示将加强测试流程，包括引入 模糊测试（Fuzz Tests）、负载测试、更完善的监控以及更优的恢复工具，以降低此类事件再次发生的概率。

该事件表明，即便是最大的以太坊 L2 网络，也可能因为一个单一排序器中的状态管理极端情况而被击垮。自动化的故障转移和恢复系统在整个 Rollup 生态中，仍是一个有待完善的前沿议题。