一份新提交的错误报告显示，在约 30% 的节点采用重命名服务器之际，XRP Ledger 的 v3.2.0 软件会在日志中记录一个验证者密钥，却在实际运行中使用另一个。
关键要点：
- 一名节点运营者报告称，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 已在持续投票中表示支持），落后升级的节点还可能面临因修正规则而被阻塞的状态。