XRPL 点对点层遭清单洪流冲击，热修复补丁紧急上线

核心提要：7月31日，XRPL因验证人清单洪流导致部分节点承压，官方发布xrpld 3.2.1热修复版本，通过四项关键防护机制限制异常数据传播，保障网络稳定性。

XRPL 点对点网络遭遇清单洪流冲击，运维团队迅速响应

7月31日，一场由异常验证人清单引发的数据洪流对XRP账本的部分点对点基础设施构成压力。尽管出现短暂中断，账本仍成功完成关闭流程，显示共识机制持续活跃。个别节点则面临异常数据负载，导致处理延迟。

新版xrpld 3.2.1正式发布，针对性修复洪流漏洞

针对当日暴露的问题，XRP账本已推出xrpld 3.2.1版本，有效解决清单洪流引发的资源消耗风险。该更新在不改变交易规则与账本逻辑的前提下，强化了底层通信控制。后续将向社区披露详细的技术复盘报告。

不可信清单传播机制如何被滥用

验证人清单用于关联主身份与临时签名密钥，支持密钥轮换而不影响身份认证。然而早期版本的xrpld允许无限制接收、存储并广播与未知密钥相关的清单数据，导致大量非可信信息在节点间循环传播，并在本地缓存中堆积。

此次事件影响范围集中于点对点消息层，未波及账本状态、余额或交易执行。尽管账本持续正常运转，但高负载下的连接质量下降可能延缓信息扩散速度，削弱整体网络连通性。

四重防护机制构建数据过滤屏障

为应对上述风险，3.2.1版本引入多项优化，覆盖解码前拦截、批量处理控制、连接问候限制与本地存储阈值设定，共涉及六次提交和13个文件变更。

首先，在解码阶段前即拒绝超过预设编码尺寸的单个清单，防止无效输入触发深层处理。

其次，节点会丢弃包含过多不可信清单的传入批次，同时避免强制断开旧版节点，以降低升级过程中的网络分裂风险。

第三，限制新连接建立时交换的批量清单数量，确保可信清单可正常获取，而不可信广播在收发两端均受控。

最后，每个节点最多仅保留100条与未知验证人密钥相关的清单记录，超出部分将被直接拒绝且不再写入磁盘。

部署流程强调二次重启与密钥验证

管理员在安装更新后需等待1至2分钟，确认服务稳定运行，无需等待完全同步即可进行下一步操作。

随后必须执行第二次重启，此步骤被运营团队视为升级闭环的关键环节，确保所有配置生效。

使用软件包管理的用户应核实Ripple最新的GPG签名密钥。该密钥已于2026年2月完成轮换，若系统未信任新密钥，可能无法接收自动更新。

本次热修复未改动共识逻辑或交易规则，核心目标是在数据进入解码、重播、缓存或持久化之前实施严格约束。通过控制清单大小、批量量、连接问候频率及未知密钥存储上限，成功封堵了7月31日攻击路径。虽然账本生成保持连续，但事件凸显点对点层滥用对个体节点的潜在威胁。