区块未停交易暴跌:Robinhood Chain 故障真相
核心要点
澄清Robinhood Chain故障期间区块生成未中断,实为应用层交易因数据上传延迟而大幅下降,揭示L2网络底层与上层服务的差异。
据 Woofun AI 消息,作为以太坊第二层网络的 Chain 在 9 月 4 日遭遇严重服务波动,尽管底层区块生成并未停止,但应用层交易出现断崖式下跌,这一现象彻底颠覆了外界对此次故障的初步认知。
针对此前 关于'区块生成至少中断 14 分钟'的报道,最新的全天统计数据予以了有力纠偏。 在 9 月 29 日发布的统计显示,从 UTC 时间 9 月 4 日的 0 点开始到 1440 分钟结束期间,该网络共生成了 854,255 个区块,连续区块生成时间之间的最长间隔仅为两秒。
值得注意的是,在据称故障开始的 UTC 时间 12:57 所在的那一分钟里,该网络依然产生了 592 个区块。CryptoSlate 在 9 月 5 日的文章中声称区块生成至少中断了 14 分钟,但这一说法并不正确。Glass Hull 统计出的'14 分钟中断期'其实指的是两次独立的异常情况:分别是 UTC 时间 12:29:47 至 12:38:23 以及 12:42:47 至 12:48:11 期间, 向以太坊发送交易数据的过程出现了暂停,而这两次暂停都在 12:57 之前结束,且都没有影响到区块的生成。 的运行状态记录中也显示了以太坊数据上传过程中存在类似的间歇现象。第二层网络即便其数据上传流程出现延迟,依然可以继续生成区块。
Woofun AI 整理数据显示,应用层的实际体验与底层数据存在巨大割裂。 在 9 月 23 日的分析中发现,从 UTC 时间 12:37 左右到 13:20 左右,通过那些负载较高的 Robinhood Chain 应用的正常交易数量出现了急剧下降,在这段时间内,这些应用完成的成功交易数量仅约为平时的五分之一。Walnut 认为预言机更新延迟以及智能钱包交易失败等现象,都表明有部分交易在到达区块层面之前就已经丢失了。
现有的公共链数据并未揭示出故障的具体原因。 在 UTC 时间 13:10 开始对 Robinhood Chain 主网日益加剧的延迟问题展开调查。到了 UTC 时间 16:20,该服务提供商警告称,由于正在排查排序器数据传输环节存在的问题,用户可能会面临性能下降以及交易处理失败的情况。QuickNode 的统计数据针对的是其自身的服务,而 Walnut 所统计的约 40 分钟的时间段则反映的是应用层的交易情况。
@arbitrum 在 9 月 4 日发表的声明中表示,该网络并未出现任何停机情况,用户的直接交易也没有出现延迟;同时它也指出,由于有许多服务提供商依赖该网络的数据流,因此其中一些提供商的功能确实受到了短暂的影响。该声明将用户的直接交易与服务商提供的服务区分开了;而 Walnut 的应用交易统计数据以及 QuickNode 记录的故障事件,则说明了为何这种区分对用户而言至关重要。Walnut 认为,在以太坊网络手续费急剧上升的背景下,用于批量上传数据的机制的报价被抬得过高,从而导致数据上传工作被延迟。至于那些数据上传间隔出现的原因,Glass Hull 并未给出解释。现有的公开数据表明区块生成一直处于正常状态,但应用层的交易性能却出现了下降,而至于链下故障究竟发生在排序器队列还是 RPC 层,以及这一故障如何导致数据上传延迟,这些问题目前仍悬而未决。

评论
暂无评论