自选
我的自选
查看全部
市值 价格 24h%
  • 全部
  • 产业
  • Web 3.0
  • DAO
  • DeFi
  • 符文
  • 空投再质押
  • 以太坊
  • Meme
  • 比特币L2
  • 以太坊L2
  • 研报
  • 头条
  • 投资

免责声明:内容不构成买卖依据,投资有风险,入市需谨慎!

排序器漏洞致Base网络一周内两次宕机

2026-06-28 16:02:05
收藏

Coinbase的Base二层网络遭遇两次区块生产中断

Coinbase旗下的Base二层网络在上周发生了两次区块生产中断事件。该项目的工程团队将这两次问题都追溯至其排序器基础设施中的缺陷。根据周六发布的事后分析报告,区块构建过程中的一个漏洞导致执行失败后残留了“过时账本状态”——这使得网络无法继续推进,直到运营人员应用修复程序。

由于Base采用单一排序器运行,这一事件凸显了许多卷叠方案普遍存在的结构性风险:当排序器逻辑出现故障时,整个链的区块排序和向前推进都可能陷入停滞。Base在周四首次发生中断,持续116分钟,随后又发生第二次中断,持续20分钟。在这两次事件中,新的二层区块生产完全停止。

核心要点

Base的工程团队将中断事件归因于排序器的区块构建逻辑,该逻辑在交易验证失败后留下了“过时账本状态”。Base采用单一排序器运行,因此排序器层面的缺陷可能导致整个网络的区块生产陷入停顿。第二次中断因系统重置后出现的“竞态条件”而加剧,导致排序器无法及时同步。工程师表示,由于基础设施条件而非原始漏洞的原因,修复所需时间超出预期。计划中的后续措施包括更多的协议“模糊测试”和“优雅恢复”机制,以减少手动重启。

事后分析指出的问题所在

在事后分析中,Base工程团队解释称,一笔无效交易到达区块构建器并在执行过程中失败——这属于预期行为。然而,失败之后出现了一个意外的状态管理结果:排序器未能清除用于记录处理过程中访问了哪些账户和存储槽位的账本状态。该账本状态对于正确的执行记账至关重要。如果本应被清除的状态持续存在,区块构建的后续阶段可能会被迫进入不一致的路径,导致排序器和验证节点无法越过有问题的区块。在这种情况下,这正是最终导致Base链上进度停止的原因。

事后分析还指出了为什么这对Base的破坏性尤其大:该网络使用单一排序器。与将排序器职责分散到多个组件的架构不同,单一排序器成为区块生产的单点故障点。团队的分析将这一事件明确定位在排序器层面,而非更广泛的执行环境。

两次中断,同一个根本原因——以及第二种故障模式

Base主网在周四至周五期间两次停止区块生产。第一次事件持续116分钟,第二次持续20分钟。在这两次事件中,新的二层区块停止生产,排序器和验证节点无法越过无效区块继续推进,直到排序功能恢复。工程师表示,他们通过对排序器进行修补,确保在执行过程中正确更新账本状态,从而解决了中断问题。然而,他们强调,缓解问题所需的时间超出了预期。团队将延迟归因于“与原始漏洞无关的基础设施条件”,这意味着修复操作本身比底层代码修复更为复杂。

除了最初的状态清除问题外,事后分析还描述了系统重置后的一个额外复杂情况:一个“竞态条件”阻止了排序器同步。重启后出现的这个竞态条件被认为是第二次中断的驱动因素——这意味着链并非仅失效一次并恢复,而是经历了与组件重新同步方式相关的后续停滞。

排序器脆弱性对卷叠用户的影响

虽然中断从来都不是理想情况,但排序器事件对用户而言具有特殊的重要性,因为排序是卷叠协调交易的基础。中心化排序器决定交易顺序并将其打包成区块。当其区块构建逻辑或恢复流程出现故障时,用户可能会看到连锁效应:确认延迟、最终性进度停滞,以及终端用户难以预料的操作中断。

Base团队的发现也与卷叠生态系统中更广泛的模式相呼应。事后分析的叙述与早前的报道一致,即排序器或其相关故障也曾导致其他二层网络出现中断,包括Arbitrum、OP主网和zkSync Era。这些先例有助于解释为什么开发者和投资者密切关注排序器的容错能力、重启行为,以及系统在真实条件下如何处理无效交易。

对于Base而言,考虑到其“单一排序器”的设置,这一事件可能会引发对弹性和恢复机制的更严格审视。在中心化排序器设计中,如果恢复路径需要手动干预或对时序敏感,即使是小的逻辑错误也可能产生系统范围的后果。

Base计划下一步做什么

在确定直接原因并应用补丁后,Base工程团队概述了旨在降低复发概率的改进措施。事后分析中强调了两个步骤:增强的协议“模糊测试”和更好的“优雅恢复”。模糊测试通常涉及向系统输入大量随机化输入——包括畸形的或意外的情况——以发现在标准测试中可能不出现的边缘故障。在此背景下,目标是更好地对排序器逻辑进行压力测试,以便更早地发现状态处理漏洞——如不当的账本状态清除。团队描述的“优雅恢复”旨在确保验证节点在未来事件中不需要手动重启。这一点很重要,因为恢复时间会影响用户体验和操作风险:系统能够越快速、越自动地重新稳定,网络处于停滞状态的时间就越短。

Base并非首次遭遇排序器事件

这并不是Base第一次遇到与排序器相关的中断。事后分析提到早前在2024年9月发生的一起事件,区块生产停止了17分钟,以及2025年8月的另一起事件,持续了大约半小时。该网络的规模也使得这些事件更具影响力。根据L2beat的数据,Base是总锁仓价值第二大的二层网络,接近110亿美元。拥有如此规模的资金和活动量,排序器的可靠性已不仅仅是一个技术指标——它直接影响着对该链运营成熟度的认知。

随着Base的持续增长,行业将关注所承诺的改进能否转化为更快速、更顺畅的恢复以及更少的长时间停滞。即使排序器仍然保持中心化,其软件路径的容错能力——尤其是在状态管理和重置行为方面——可以在很大程度上决定中断是否会发生连锁反应。目前,Base用户和构建者应关注工程团队能否在压力条件下快速验证修补后的行为,以及计划的模糊测试和恢复升级能否降低重复故障的可能性——尤其是那些与无效交易处理和重置后同步相关的故障。

展开阅读全文
更多新闻