运行 XRP Ledger 的节点运营者被要求迅速行动。Ripple 工程总监 Vijay Khanna 于 8 月 2 日敦促基础设施提供商完成到 xrpld 3.2.1 版本的XRP Ledger 节点升级，此前开发者在 7 月 31 日发现有验证者清单（manifest）洪泛攻击冲击网络。账本在整个事件期间一直持续产出区块，但这次事件暴露出一个资源耗尽弱点，Ripple 现已通过一个有针对性的热修复来弥补这一问题。
Summary
要点概述
- 7 月 31 日发生的验证者清单洪泛攻击，促使 Ripple 于 8 月 1 日发布 xrpld 3.2.1 作为紧急热修复版本。
- 在整个事件期间，XRP Ledger 一直正常关闭账本，没有出现已确认的资金损失、交易被篡改或共识失败。
- 四项新的防护措施现在对清单大小、消息批量大小、未知验证者密钥的缓存增长以及不受信任数据的出站共享进行了限制。
- 运营者必须完成升级，确认 xrpld 正在运行，然后第二次重启，以清除补丁前遗留的任何清单。
- Ripple 已于 2 月 18 日轮换其软件包签名 GPG 密钥，因此运营者必须信任新密钥，更新才能正确安装。
是什么触发了这次 XRP Ledger 节点升级
这次洪泛攻击集中在验证者清单上——这些是加密签名记录，用于将验证者的永久主身份与其用于日常验证流量的临时密钥关联起来。当验证者轮换该临时密钥时，它会广播一个由其主密钥签名的新清单，以便网络中的对等节点可以验证这一变更的合法性。
在修复之前，只要数据结构上有效，节点就会接受、缓存并转发与其从未见过的验证者密钥相关联的清单。这就产生了一个漏洞：有人可以生成大量未知身份，迫使每个连接的节点仅仅为了处理这些噪音就消耗内存、存储、带宽和算力。与该事件相关的公开代码记录将其描述为一种清单传播缺陷，而不是任何账户或密钥被攻破。
尽管节点资源承受了压力，XRP Ledger Operations 报告称，网络在整个期间一直正常关闭账本。这一区别很重要：洪泛攻击给基础设施带来了压力，但从未发展到破坏共识或损坏交易历史的程度。
xrpld 3.2.1 热修复的内部细节
Ripple 的应对措施日期为 7 月 31 日，并于 8 月 1 日清晨以签名发布的形式公开，其中包含 6 个提交，修改了 13 个文件，其中有 4 个直接限制节点如何处理来自未识别验证者的清单。它们共同构成了四道防线，旨在防止同类洪泛攻击再次耗尽节点资源。
第一项措施是在节点尚未完成解码之前就拒绝超大清单，从入口处切断对异常大型对象的处理成本。第二项措施限制单个网络消息中可携带的不受信任清单数量，无论节点是在接收数据还是在为对等节点准备数据；超大批次会被丢弃，但不会自动断开连接，这使得在升级部署期间，已打补丁和未打补丁的节点仍能继续通信。
第三项变更限制了节点清单缓存中可容纳的未知验证者身份数量，最终代码将该上限设为 100。一旦缓存被填满，新的未列出密钥将被拒之门外，而受信任和先前已识别的验证者则可继续不间断运行。第四项调整改变了不受信任清单数据在网络中的传播方式，收紧对未列出对等节点“八卦”信息的出站共享，同时保持与已配置或已批准验证者相关的数据不受影响。这种平衡是有意为之：正常的验证者密钥轮换仍然有效，但来自陌生方的无限制缓存增长则不再可能。
节点运营者现在需要做什么
Khanna 的指导很直接，但必须按顺序执行。运营者应安装标准更新，等待一到两分钟，确认 xrpld 确实在运行，然后第二次重启该服务。
第二次重启并非走形式。运营者节点在打补丁前吸收并存储的任何清单，仍可能驻留在内存或磁盘中。安装 3.2.1 会改变软件今后处理新清单的方式，但只有一次全新的重启才能清除节点在仍处于易受攻击状态时获取的数据。跳过这一步，可能会在代码本身已修复的情况下，仍然遗留陈旧且不受信任的清单。
还有第二个值得注意的细节：软件包信任。Ripple 已于 2 月 18 日轮换用于签署 xrpld 软件包的 GPG 密钥，而尚未信任该替换密钥的安装环境，可能无法自动拉取更新。任何管理 XRPL 基础设施的人都应在假定升级会顺利应用之前，检查其签名密钥配置。
需要强调的是，这次XRP Ledger 节点升级完全针对基础设施，而非个人持币者。交易所、托管机构、钱包后端、数据提供商以及任何运行自有 XRPL 服务器的企业，都需要确认其节点版本和重启状态。普通 XRP 持有者无需因本次问题而转移资金、更换钱包密钥或开设新账户——修复完全发生在服务器层面。
为何“没有损失”仍然重要
目前尚未就此次洪泛攻击发布任何 CVE 标识符或财务损失估算，现有证据指向的是节点资源和点对点流量承压，而非任何已确认的盗窃、交易篡改或共识崩溃。对于一个结算价值达数十亿的网络而言，这是一个真正令人宽慰的结果，但并不意味着这次事件没有成本。不触及资金的资源耗尽攻击，仍然可能降低服务质量、拖慢基础设施提供商的运行速度，并在补丁滞后时为后续攻击创造机会。
这正是目前公共记录中仍然缺失的部分。XRP Ledger Operations 表示将发布技术事后分析报告，但截至 8 月 2 日，该报告尚未公开。在报告发布之前，发动洪泛攻击者的身份、实际涉及的清单数量，以及网络中节点运营者采纳 3.2.1 的速度，仍然是悬而未决的问题。预计该报告还将澄清开发者首次发现异常流量的时间点，以及是否有任何单个节点变得不可达，尽管共享账本本身从未停止产出区块。
这并不是该网络今年第一次被迫进行软件迁移。3.2.1 热修复紧随 6 月 15 日更大规模的 3.2.0 部署之后，后者将参考服务器从 rippled 更名为 xrpld，并要求进行一轮配置更新——同一版本也促使 XRPL 基础设施运营者 David Schwartz 提前迁移其部署，以适应新的命名和协议变更。节点运营者还必须满足与一次修正规则激活相关的更早 3.1.3 截止日期。综合来看，这一模式表明 XRPL 的基础设施层正被要求跟上日益紧凑的更新节奏，而在任何单次发布上落后的运营者，都有可能将网络其他地方已修复的漏洞继续带在身上。
常见问题
是什么导致需要进行这次 XRP Ledger 节点升级？
7 月 31 日发生了一次验证者清单洪泛攻击，导致节点资源耗尽，因此需要通过 xrpld 3.2.1 热修复来缓解这一问题。
清单洪泛是否在 XRP Ledger 上造成资金损失或共识失败？
根据 XRP Ledger Operations 的说法，在洪泛期间未观察到任何已确认的财务损失、交易被篡改或账本共识失败。
xrpld 3.2.1 引入的主要防护措施有哪些？
该更新限制了清单大小、消息批量大小、未知密钥缓存增长（上限为 100 条），以及不受信任清单的出站共享。
谁需要升级到 xrpld 3.2.1，以及操作步骤是什么？
运行 XRPL 节点的基础设施提供商——包括交易所、托管机构和钱包运营方——必须完成升级，验证软件正在运行，然后执行第二次重启，以清除任何已持久化的清单。
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”是什么导致需要进行这次 XRP Ledger 节点升级？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”7 月 31 日发生了一次验证者清单洪泛攻击，导致节点资源耗尽，因此需要通过 xrpld 3.2.1 热修复来缓解这一问题。”}},{“@type”:”Question”,”name”:”清单洪泛是否在 XRP Ledger 上造成资金损失或共识失败？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”根据 XRP Ledger Operations 的说法，在洪泛期间未观察到任何已确认的财务损失、交易被篡改或账本共识失败。”}},{“@type”:”Question”,”name”:”xrpld 3.2.1 引入的主要防护措施有哪些？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”该更新限制了清单大小、消息批量大小、未知密钥缓存增长（上限为 100 条），以及不受信任清单的出站共享。”}},{“@type”:”Question”,”name”:”谁需要升级到 xrpld 3.2.1，以及操作步骤是什么？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”运行 XRPL 节点的基础设施提供商——包括交易所、托管机构和钱包运营方——必须完成升级，验证软件正在运行，然后执行第二次重启，以清除任何已持久化的清单。”}}]}
本文由人工智能协助生成，并由编辑团队审核。
