XRP Ledger 敦促节点升级以应对验证器清单洪水

Ripple工程总监Vijay Khanna于8月2日敦促XRP Ledger节点运营商安装xrpld 3.2.1版本，此前开发人员于7月31日观察到验证器清单洪水攻击。

该热修复限制了节点处理、存储和共享来自未知验证器身份的数据的方式。

根据XRP Ledger Operations的说法，XRP Ledger在此事件期间继续正常关闭账本。因此，现有证据表明问题在于节点资源和点对点通信的压力，而非确认的资金损失、交易篡改或账本共识失败。开发人员尚未发布与此事件相关的CVE标识符或财务损失估计。

XRPL 3.2.1限制了清单洪水攻击路径

验证器清单是加密签名的记录，将验证器的稳定主身份与其用于日常验证消息的临时密钥连接起来。当运营商轮换这些临时密钥时，他们会发布由主密钥签名的新清单，以便其他节点验证更改。

在热修复之前，节点可以接受、缓存并重新广播与它们不认识的验证器密钥关联的有效结构清单。攻击者可以利用这种行为，生成许多未知身份，并迫使对等节点花费内存、存储、带宽和处理能力来处理这些数据。公共代码记录将该缺陷描述为清单传播问题。

官方xrpld 3.2.1版本日期为7月31日，并于8月1日早间作为最新签名版本发布。它包含13个更改文件中的6个提交，其中4个提交直接限制不受信任的清单处理。

四项保护措施降低资源耗尽风险

第一项保护措施在节点完全解码之前拒绝过大的验证器清单。这减少了攻击者通过发送大于软件预期的单个对象而触发的处理工作。

第二项限制了一条网络消息中携带的不受信任清单数量。该限制适用于节点接收数据时以及为对等节点准备清单消息时。过大的批次会被丢弃，而不会自动断开未修补的对等节点，这有助于在推出期间保持升级节点和旧节点之间的连接。

第三项更改限制了节点清单缓存中持有的未知验证器身份数量。最终代码将最大值设置为100。一旦达到该容量，软件将拒绝与新的未列出密钥关联的清单，同时继续处理受信任或先前识别的验证器。

该补丁还更改了不受信任清单信息的保留和传播方式。受信任的验证器数据仍然可用，因为限制针对的是未列出的对等节点八卦，而不是来自已配置或已批准验证器的清单。这种区别允许正常的验证器密钥轮换继续，同时阻止无限制的缓存增长。

节点运营商必须完成第二次重启

Khanna建议验证器和其他基础设施运营商“尽快”升级到3.2.1版本。他的指示要求进行正常的软件更新，然后等待一到两分钟，并检查xrpld是否正在运行。运营商随后应再次重启服务。

对于在安装修复程序之前可能保留了未知清单的节点，第二次重启非常重要。更新会改变未来的处理方式，而重启修正后的服务器有助于确保旧的内存中或先前保留的数据不会继续影响操作。

运营商可能还需要确认其系统信任Ripple当前的软件包签名密钥。发布说明指出，Ripple于2月18日轮换了用于签署xrpld软件包的GPG密钥。尚未信任替换密钥的现有安装可能无法成功接收自动升级。

此更新适用于基础设施提供商，而非普通XRP持有者。用户无需因清单问题而转移XRP、更改钱包密钥或创建新账户。交易所、托管机构、钱包后端、数据提供商以及运行自己的XRPL服务器的企业应确认其节点版本和重启状态。

事后分析将确定事件的影响范围

XRP Ledger Operations表示，技术性的“事后分析将很快发布”。截至8月2日，该项目尚未发布该报告，因此发送者的身份、传输的清单数量以及受影响节点的确切资源使用情况仍未披露。

报告还应澄清开发人员首次检测到该活动的时间、是否有节点变得不可用，以及运营商采用3.2.1版本的速度。尽管账本继续关闭，但补丁采用缓慢可能使个别服务器在共享账本保持运行的情况下仍面临再次洪泛的风险。

此热修复程序在XRPL更大的3.2.0版本推出后不久发布。该版本于6月15日发布，将参考服务器从rippled更名为xrpld，并引入了要求运营商更新软件和服务配置的基础设施变更。

正如先前报道的那样，3.2.0版本最初在验证者中的传播速度快于更广泛的节点网络。清单洪泛为剩余运营商提供了超越该版本并安装热修复程序的新理由。

与此同时，在相关报道中，David Schwartz将其XRPL基础设施迁移至3.2.0版本，而开发人员正在为网络准备新的服务器命名和协议功能。早些时候，正如crypto.news报道的那样，节点运营商还面临与修正案激活相关的3.1.3版本截止日期。

接下来经过验证的更新将是承诺的事后分析和新的软件采用数据。在此之前，确认的响应仍仅限于3.2.1版本、其四项清单控制措施以及要求运营商完成升级和重启流程的请求。