清单洪流如何考验 XRPL 节点基础设施
7 月 31 日,一场验证人清单洪流对 XRP 账本的部分点对点基础设施造成了压力,随后 XRP 账本发布了 xrpld 3.2.1 版本。尽管出现中断,该区块链仍正常关闭账本,表明共识机制保持活跃,而个别服务器却面临异常数据压力。
XRP 账本 3.2.1 版本现已可用。该版本修复了 7 月 31 日(周五)观察到的清单洪流问题。在此期间,XRPL 始终正常关闭账本。后续将向社区发布详细的事后分析报告。
此前,节点能够无限制地接收、存储并重新广播……
因此,XRP 账本运营团队指示节点管理员立即安装该热修复补丁,并在安装后不久执行第二次重启。最新的生产版本新增了限制措施,旨在防止未知验证人数据消耗过多的内存、带宽、存储和处理能力。
清单洪流如何考验 XRPL 点对点基础设施
验证人清单将验证人的永久主身份与共识过程中使用的临时签名密钥关联起来。这种结构允许操作员轮换工作密钥,同时将主凭证保持离线状态,并保留验证人已建立的身份。
然而,早期版本的 xrpld 能够接受、存储并重新广播与未知验证人密钥关联的无限量清单。因此,过多的不可信数据可能在连接的节点间传播,并在本地缓存中累积。
此次事件影响的是点对点层的消息传播,而非余额、交易或账本规则。尽管 XRPL 继续处理交易并关闭账本,但压力下的点对点连接仍可能削弱连通性并减慢信息分发速度。
为解决这一暴露问题,3.2.1 版本引入了六项提交,涉及 13 个文件。这些变更共同在四个关键点施加了控制,防止过大或重复的清单流量对节点造成负担。
首先,xrpld 在解码开始之前就会拒绝那些超过预期编码大小的单个清单。因此,过大的输入无法触发不必要的处理。
其次,节点会丢弃包含过多不可信清单的传入批次。不过,软件会避免自动断开发送过大批次的旧版节点,从而降低升级期间网络分片的风险。
第三,该热修复补丁限制了节点建立新对等连接时交换的批量清单问候。可信记录仍可正常获取,而不可信广播在发送和接收路径上都受到限制。
最后,每个节点最多只能存储 100 个与未知验证人密钥关联的清单。一旦达到该阈值,额外的条目将被拒绝,并且不可信清单不再写入磁盘。
四项防护措施与所需的第二次重启
安装更新后,管理员被指示等待一到两分钟,确认 xrpld 保持运行状态。他们无需等待节点完全同步即可执行下一步操作。
一旦确认更新后的服务正在运行,操作员必须再次重启 xrpld。运营团队将这次第二次重启描述为升级过程中至关重要的最后一步。
与此同时,使用软件包安装的管理员应验证 Ripple 当前的软件签名密钥。Ripple 已于 2026 年 2 月轮换了用于签署 xrpld 软件包的 GPG 密钥。因此,尚未信任替换密钥的系统可能无法接收自动升级。
总体而言,XRP 账本的热修复补丁未引入网络修订,也未改变交易处理规则。相反,它在不可信对等数据到达解码、重新广播、缓存或永久存储之前,对其建立了严格的限制。
通过限制清单大小、批量数量、连接问候以及未知密钥存储,XRPL 已关闭了 7 月 31 日洪流期间使用的四条路径。尽管网络继续生成账本,但此次事件表明,在共识机制保持运行的同时,点对点层的滥用仍可能对个别服务器造成压力。

资金费率
资金费率热力图
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
账号安全
资讯收藏
自选币种