XRP账本已发布xrpld 3.2.1版本，这是一个生产环境热修复，旨在阻止在2026年7月31日给网络部分点对点基础设施造成压力的验证器清单泛洪。xrpld是参与者用于在XRPL上运行节点和验证器的参考服务器软件。该区块链未中断地继续关闭账本，确认即使在各个节点经历异常数据负载时，共识仍保持完全运行状态。

XRP Ledger Operations通过其官方X账号宣布了此次发布：

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

节点管理员被指示立即安装热修复，并在初始安装后不久进行第二次重启。更新后的构建引入了控制措施，以防止不受信任的验证器数据消耗不成比例的内存、带宽、存储和处理能力。

清单泛洪如何对XRPL节点基础设施造成压力

XRPL依赖于一系列验证器，每个运营商都通过唯一节点列表（UNL）将其指定为受信任的。只有节点UNL上的验证器才能直接参与该节点的共识决策。验证器清单将验证器的永久主身份与共识期间使用的临时签名密钥链接起来。这种架构使运营商能够定期轮换工作密钥，同时保持主凭证处于离线状态，并维持验证器既定的网络身份。

早期版本的xrpld对于节点可以接受、存储和重新广播的与未知验证器密钥关联的清单数量没有上限。由于每个节点都会将清单数据转发给其连接的节点，而不论其信任状态如何，因此过多的不受信任的数据在网络中传播并积累在本地缓存中。

该事件影响了节点层的消息传播，而不是账户余额、单笔交易或账本验证规则。这种区别对区块链架构通常具有重要意义：共识层故障可能导致链停滞，而节点层故障会降低连接性，同时不损害账本完整性。尽管XRPL继续按计划处理交易并完成账本关闭，但节点连接的压力降低了连接性，并减缓了网络中的信息分发。

版本3.2.1中的四项保护措施

版本3.2.1引入了跨越13个文件的六次提交。这些更改在超大或重复的清单流量可能给节点带来负担的四个关键点实施了控制：

1. 解码前大小拒绝。 xrpld现在会在解码过程开始之前拒绝超过预期编码大小的单个清单，从而防止过大输入触发不必要的计算工作。

2. 不受信任的批次丢弃。 节点现在会丢弃包含过多不受信任清单的传入批次。重要的是，该软件避免了自动断开发送超大批次的旧节点连接，这降低了升级期间网络碎片化的风险。

3. 节点问候限制。 该热修复限制了两个节点建立新节点连接时交换的批量清单问候。受信任的记录保持完全可用，而不受信任的闲聊在发送和接收路径上均受到限制。

4. 未知密钥存储上限。 每个节点最多只能存储100个与未知验证器密钥关联的清单。一旦达到此上限，进一步的条目将被拒绝，并且不受信任的清单不再持久化到磁盘。

必须的第二次重启和签名密钥验证

安装更新后，管理员被指示等待大约一到两分钟，并确认xrpld仍在运行。在继续下一步之前，不需要完全同步。

一旦确认更新后的服务正在运行，操作员必须再次重启xrpld。运营团队将这第二次重启描述为升级程序中必不可少的最后一步。

运行打包安装的管理员还应验证Ripple当前的软件签名密钥。Ripple在2026年2月轮换了用于签署xrpld包的GPG密钥，这意味着尚未信任替换密钥的系统可能无法接收自动升级。

该热修复未引入任何网络修正案，也没有改变任何交易处理规则。相反，它在每个阶段（解码、重新广播、缓存或永久存储之前）对不受信任的节点数据建立了严格的边界。通过限制清单大小、批次卷、连接问候和未知密钥存储，XRP账本已经关闭了7月31日泛洪期间使用的四条利用路径。该事件表明，即使共识继续正常运行，节点层滥用仍会使各个服务器承受压力，这也是其他区块链网络通过强化节点协议已经解决的一类漏洞。

预计完整的事件事后分析将向社区分享。