一份新提交的缺陷报告显示，XRP Ledger v3.2.0 软件在大约 30% 节点采用这款更名后的服务器时，会在日志中记录一个验证者密钥，却实际运行另一个密钥。
要点：
- 一名节点运营者报告称，v3.2.0 会在日志中记录迁移后验证者的新密钥，但服务器实际仍在运行旧密钥。
- 该缺陷出现在 Ubuntu 22.04 上，当现有验证者令牌被添加到正在运行的 RPC 节点时会触发。
- 升级采纳率约为 30%，大多数运营者仍停留在上一版本。
XRP Ledger 缺陷暴露密钥不匹配
这一缺陷在项目 GitHub 追踪器上以 #7581 号 问题 形式提交。问题出现在运营者将现有验证者迁移到已在运行的 RPC 节点上并重启服务之后。服务日志会报告迁移后验证者的新身份，而 server_info 接口则继续返回本地 wallet.db 文件中存放的旧密钥，两者记录不再一致。
复现这一分裂现象并不困难。该运营者表示，在一台活跃节点上添加现有验证者令牌并重启服务器，就会在 Ubuntu 22.04 上触发这一问题，而这在日常迁移流程中相当常见。
延伸阅读： Anthropic 永续抛压是否在警示 Pre-IPO 加密押注？
验证者身份是网络共识的锚点
验证者身份是 XRP Ledger 就每个新账本达成共识的核心。一台节点的提案只有在其他服务器通过自己的唯一节点列表信任其密钥时才具备权重，因此过期或不匹配的身份会让审查这台机器的人感到困惑，而混乱的日志会拖慢这种信任的建立。
目前为止，这种不匹配尚未引发宕机。即便如此，它还是拉长了自本月中发布以来开发者陆续标记的缺陷清单，从同步失败到配置解析器崩溃一应俱全。
报告者已经提出修复建议，希望服务日志能够打印出服务器实际使用的密钥，或者同时展示派生密钥与活动密钥。目前尚未有维护者被指派处理该报告。更早提交的若干问题已被确认是缺陷并排队等待审查，另一些则仍在开放状态，供贡献者权衡。
采纳进度滞后，修正规则投票仍在继续
此次发布的采用速度依然缓慢。根据公开网络数据，大约 30% 的节点已经运行 3.2.0 版本，而大多数运营者仍停留在先前的 3.1.3 构建上。
该版本自 6 月 15 日开始逐步推出，当时更新将核心软件从 rippled 更名为 xrpld，并宣称可节省 30% 至 40% 的内存。此后，运营者陆续报告了同步中断、转发计算错误，以及如今在新版本上出现的密钥不匹配问题，目前尚未发布补丁。一旦验证者通过 fixCleanup3_2_0 这一清理修正规则（Ripple 已在正在进行的投票中表示支持），落后的节点还可能面临被修正规则阻断的风险。