验证者支持短暂下滑，XRP Ledger 错误修复延至 11 月

目录

• 你可能想知道
• 主要内容
• 重点摘要表
• 后续发展……

你可能想知道

• 为什么验证者支持短暂下滑会推迟 XRP Ledger 的错误修复？
• 这项补丁会更改什么？其状态与提议中的借贷系统有何关联？

主要内容

验证者支持短暂下滑，推迟了 XRP Ledger 最新错误修复的启用时间。这项变更原定于 Oct. 23 上线，但一段时间内支持不足，导致必要的倒计时重置。XRPLWin 列出的修订启用时间为 Nov. 4 的 14:46 UTC。

这次延迟反映出 XRP Ledger 处理规则变更的方式。验证者是独立服务器，负责就哪些交易有效，以及哪些网络更新获得支持达成共识。提议的变更要达到批准门槛，必须获得网络默认信任的 35 个验证者中超过 80% 的支持。也就是说，至少需要 29 个验证者投赞成票。

支持度并非只测量一次。验证者支持情况约每 15 分钟检查一次，而且必须连续 14 天每次检查都达到门槛。若任何一次检查的支持度低于要求，14 天的计时就会重新开始。因此，即使支持度很快恢复，短暂中断仍可能推迟启用时间。

这项名为 fixCleanup3_4_0 的补丁，在第一次启用尝试期间，支持度接近最低门槛。周一，它刚好获得 29 张赞成票，没有任何余地应对验证者不可用或停止投赞成票的情况。当时计划于 Oct. 23 的 09:34 UTC 启用。

投票数下滑后，原定时间安排发生变化。根据 XRPL Dashboard，周三 12:54 UTC 的检查时，仅有 26 个验证者被记录为支持这项修复。结果低于所需的 29 票，因此持续进行中的批准期无法继续。

到了 14:46 UTC，支持度已回升至 29 票，新的倒计时随之开始。XRPLWin 现在将这项修复列为计划于 Nov. 4 的 14:46 UTC 启用。此后，支持者已增至 35 个受信任验证者中的 31 个。提案因此比门槛多出两票，相较于第一次尝试时毫无余地，情况有所改善；不过，在整个批准期内仍必须持续符合要求。

目前可用的跟踪工具并未指出哪些验证者停止支持这项变更。只有在检查时网络收到投票，该票才会计入。因此，验证者若在不巧的时刻离线或重启，其对票数的影响可能与主动投票反对提案相同。公布的数据反映了支持程度，但无法证明支持度暂时下滑的原因。

xrpld 3.4.0 的发布说明指出，这项补丁涉及两个方面。首先，它修补了代币创建漏洞。在特定条件下，原本仅获准销毁发行者代币的账户，仍可能创建新代币。这项修正旨在防止这种意外结果，并让代币相关权限按预期运行。

其次，这项补丁调整了借贷代码判断贷款是否逾期或违约的方式。这些计算对管理固定期限及既定还款条件贷款的系统至关重要。更新逻辑有助于确保贷款状态评估一致，但错误修复计划启用，并不意味着更广泛的借贷系统已经上线。

这段借贷代码与 Ripple 自 June 起向银行和支付公司介绍的系统有关。在提议的模式中，贷款方将 XRP 或其他代币存入金库，再由经纪商将这些资产借出固定期限。这种安排连接了数字资产托管与借贷流程，因此准确计算金库和贷款数据对系统运行十分重要。

截至 Thursday，这套更广泛的借贷系统尚未上线。它必须获得足够的验证者支持，并完成另一段独立的批准倒计时，才能启用。来源指出，该借贷系统距离启动自身的启用倒计时，仍差 10 票。因此，错误修复与借贷系统应视为相关但不同的更新：补丁可能改善相关代码，但更大型的功能仍在等待所需支持。

这一连串事件说明，网络治理可能影响技术变更的时间安排。提案或许目的明确，也看似即将启用，但流程仍取决于计入批准的验证者是否持续支持。在这个案例中，票数从 29 降至 26，中断了倒计时；之后升至 31，虽然增加了当前的票数余地，仍无法免除持续符合批准要求的必要。

对于关注这项变更的用户和组织而言，关键在于区分“计划启用”与“已完成启用”。Nov. 4 是 XRPLWin 列出的修订时间，并不表示启用已经发生。在支持度未能维持完整 14 天且更新尚未生效之前，这项补丁仍处于待处理状态。公布的数据呈现验证者支持度的某个时间点，而批准机制则决定这些支持能否长期维持在足够水平。

重点摘要表

后续发展……

接下来值得关注的是，fixCleanup3_4_0 的验证者支持度能否在重新开始的批准期内持续高于要求，以及借贷系统能否获得足够票数，启动自身的倒计时。这是两个不同的里程碑：错误修复的支持度已回升至 35 票中的 31 票，而更广泛的借贷功能仍未达到其所述要求。

更广泛来看，以验证者为基础的网络或许能受益于更清晰的工具，用来呈现支持度随时间的变化，并区分有意的投票决定与暂时的服务器故障或重启。提高透明度有助于观察者理解提案为何失去票数，而不会假设每一张未收到的票都代表反对。持续探索可靠的监控方式、透明的治理流程，以及经过审慎测试的金融软件，有助于网络以兼顾问责与韧性的方式进行技术变更。

核心教训是，网络升级不仅取决于补丁的质量，也依赖负责批准的验证者持续协调。