基地称相同的定序器错误导致 6 月 25 日和 26 日中断

Base 解释了为什么其主网在两天内两次停止生产区块。 

Coinbase 支持的以太坊第 2 层网络表示，两次中断均源自其定序器区块构建逻辑中的同一错误。

第一次中断于 6 月 25 日开始，持续了约 116 分钟。第二次于6月26日开始，持续约20分钟。 Base表示，在这两起事件中，资金都是安全的。

排序器错误停止了区块生产

在其官方事后分析中，Base 表示，正如预期的那样，无效交易在执行过程中失败了。问题是在那次失败之后出现的，当时过时的日志状态仍然保留在块构建器内。

该过时状态包括失败交易所涉及的帐户和存储槽。当接下来发生有效交易时，系统使用了错误的日志状态并错误地收取了gas。

这创建了一个具有无效状态转换的块。其他节点无法接受该区块，因此该链停止产生新的 L2 区块。

“区块链的完整性没有受到损害，Base 上的所有资金都是安全的，”Base 表示。

该团队补充说，缓解后区块生产已安全恢复。

暂停期间排队的交易

在中断期间，用户无法在链上获取新交易。 Base 表示，交易在内存池中排队，而链等待区块生产恢复。

交易池后来超出了它的存储能力。因此，新的 eth_sendRawTransaction 请求在中断窗口期间返回错误。

暂停还影响了排序器和验证器的进度。 Base 表示，在排序返回之前，这些节点无法移动到无效区块之外。

正如之前报道的，在工程师隔离与无效区块相关的共识问题之前，Base 于 6 月 25 日首次标记了不健康的区块生产。

修补过时状态问题

Base 表示，它通过应用音序器补丁修复了主要错误。该补丁可确保事务失败后执行期间日志状态正确更新。

团队在恢复过程中还发现了第二个问题。 Base 表示，缓解措施需要更长的时间，因为引擎重置功能中的竞争条件导致排序器在重新启动后无法跟上。

第二个问题有助于解释为什么该事件第二天又出现。 Base 表示，该问题影响了排序器，而不是验证器节点，但它仍然减慢了恢复速度。

Base 状态页面显示排序已于 6 月 25 日恢复。它还告诉生态系统节点运营商如果仍然卡住，请重新启动 Base 节点。

计划进行测试和恢复更改

Base表示将加强协议模糊测试和负载测试。这些方法帮助团队发现可能暴露隐藏错误的奇怪事务模式。

该团队还计划更好的监控和运营检查。它表示这些变化应该可以帮助工程师更早地发现类似的问题并更快地做出响应。

Base 还希望为基础共识添加优雅的恢复。这一更改将使验证器节点在类似故障后更容易继续同步。

这次中断是在网络繁忙的一周发生的。 Base 还推进了 Beryl 升级，增加了 B20 代币标准，并将标准 Base 到以太坊的提款期限从 7 天缩短到 5 天。

该事件让开发者和用户更清楚地看到了弱点。 Base 现已命名了该错误，发布了补丁，并列出了计划改进的测试。