Robinhood Chain 因 Blob 拥堵宕机 14 分钟,Arbitrum(ARB):网络无停机

Arbitrum指出以太坊Blob拥堵

Robinhood Chain——由券商Robinhood基于Arbitrum (ARB) Orbit构建的以太坊Layer 2网络——其区块生产一度暂停超过14分钟。周四,Arbitrum(ARB)团队迅速出面安抚用户。据Arbitrum团队说明,此次中断源于向以太坊提交交易批次数据出现延迟,当时市场波动加剧,L1的blob市场十分拥堵。所谓blob,是以太坊上用于承载数据的空间,rollup借助它以低成本实现数据可用性;一旦对该空间的需求激增,Layer 2链的批次提交就可能滞后——即便这些链自身的排序仍在继续。Arbitrum明确表示,问题并不在Robinhood Chain自身的基础设施,而是以太坊市场状况所致。关键是,团队强调延迟仅涉及批次发布:用户直接提交的交易并未被延迟,用其说法,网络在整个事件期间“无宕机”运行。目前该链已恢复正常运转。这份澄清来得颇为敏感——Robinhood Chain上线仅约两个月,扩张速度却异常惊人:8月其总锁仓量(TVL)攀升至约5.4亿美元,日手续费收入一度超过以太坊本链,此前我们报道过这一行情,与Arbitrum技术上一笔创纪录的375万美元日手续费密切相关。在这样的吞吐量下,哪怕是后端提交延迟,几分钟内就会被用户直接感知,这正是blob市场放缓在外界看来宛如全面宕机的原因。Arbitrum的声明为这场混乱画上了句号:排序与用户交易处理仍在继续,底层Arbitrum技术栈——最近一次由Elara升级刷新,将Stylus合约容量提升至96KB——并非瓶颈。

区块尖端停滞在190,926附近

链上记录显示,这次暂停从外部看有多严重。9月4日台北时间晚上9点前不久,社区开始流传宕机报告,用户涌向社交平台称交易卡在待处理状态,DEX和钱包界面长时间无响应。当时发布的停摆状态警报指出,Robinhood Chain已完全停止产出新区块,官方区块浏览器也印证了这一点:链尖端在区块190,926附近冻结了数分钟——对一条通常约每0.1秒出一个区块的网络来说,这极为罕见。更让用户恼火的是,Robinhood Chain官方状态页在此前七天内持续显示“正常运行/100%在线时长”,没有任何事故通告,交易者只能通过区块浏览器而非运营方来核实问题。截至最新发稿,Robinhood本身尚未发布正式声明,且此次中断似乎仅限于Layer 2层面:该券商的股票与加密货币App并未报告大范围故障。社区分析师将可能的根源指向中心化排序器——即Arbitrum (ARB) Orbit链上由单一运营方收集、排序并打包交易的组件。一轮meme币交易狂潮将交易量与活跃地址数推至历史新高,gas费从几美分跃升至数美元;在这种负载下,排序器一旦卡死,整条链随之冻结,用户无处绕行。此类停摆很少会销毁已结算资产,但待处理交易可能需要在区块恢复后重新发送或加速——用户也被建议避免反复重发,以免打乱nonce顺序。希望实时跟踪行情的读者,可通过Gate查看现货与合约的实时价格。

@bwenews · X 帖子

报告停摆的状态警报.

在 X 上查看

排序器风险重回台面

后续链上分析让全貌更加清晰:在报告停摆的时间窗口内,Robinhood Chain实际上仍在产出包含正常用户交易的区块,“14分钟停摆”的说法很可能是区块浏览器和监控平台未能及时刷新数据所致的假象。Arbitrum的补充说明还提到,部分依赖该链实时数据流的基础设施供应商——可能包括浏览器、分析平台、RPC服务商和交易监控工具——出现了短暂性能下降,但未点名任何具体供应商。向以太坊的批次提交确实存在两处空档,合计约14分钟,独立分析认为blob费用或许只能解释其中一处,完整的技术根因仍有待事故报告确认。目前尚未发现任何资产损失、交易回滚或智能合约攻击。

（截至 18:42 UTC） (截至UTC时间18:42)在COINOTAG看来,这两件事——14分钟的批次提交延迟与冻结的排序器——指向同一个结构性事实:Orbit链继承了Arbitrum的高效,却各自运行排序器,而这一运营方始终是单点故障,再多的blob市场调优也无法消除。最硬核的证据就是链上记录本身:浏览器在区块190,926处的停滞独立印证了停摆,而Arbitrum (ARB)的澄清则将损害范围限定在结算延迟。ARB此前曾单日大涨31%,重回市值前100的山寨币行列;随着事件在市场中发酵,其现货价格过去24小时下跌约4.7%,Arbitrum生态接下来将面临一个关键观察点:Orbit运营方会以多快的速度分散其排序安排。