XRP账本批量升级重获支持票：为何10月9日仍具条件性

核心提要：XRP Ledger BatchV1_1 升级重新获得多数票支持：为何 10 月 9 日仍为条件性日期截至 9 月 26 日 UTC 时间 04:43，TheXRPL Dashboard 在追踪的 35 个可信验证器中记录了 30 张赞成票。这一计数开启了新的批准窗口，但并未完成整个流程。核心要点BatchV1_1 重

XRP Ledger BatchV1_1 升级重新获得多数票支持：为何 10 月 9 日仍为条件性日期

截至 9 月 26 日 UTC 时间 04:43，TheXRPL Dashboard 在追踪的 35 个可信验证器中记录了 30 张赞成票。这一计数开启了新的批准窗口，但并未完成整个流程。

核心要点

BatchV1_1 重新获得了 35 个验证器中的 30 个赞成票。前两周的批准倒计时已重置。目前至少需要保持 29 张赞成票。10 月 9 日是最早的可能激活日期，但该日期具有条件性。链上的激活确认标志着升级正式生效。

BatchV1_1 日期的变动历程

9 月 15 日 · 首次多数派窗口开启追踪器记录到 30 张赞成票，开始了最初的批准期。

9 月 25 日 · 倒计时重置追踪器在某个标志账本（flag ledger）上记录到多数派丢失，结束了第一个窗口。

9 月 25 日 · 新多数派窗口开启BatchV1_1 恢复至 30 张赞成票，并开始一个新的 14 天周期。

10 月 9 日 · 最早可能的激活日期该日期仅在验证器支持率保持在所需水平以上时才有效。

尽管票数恢复，日期为何重置？

BatchV1_1 于 9 月 15 日达到了 30 个支持验证器的数量。按照原定时间表，这原本将使激活时间接近 9 月 29 日。然而，多数派优势在 9 月 25 日被移除，并在当天稍后重新形成，这使得预计激活时间向后推迟了约 10 天。

仪表板标识了早期多数派被移除和新多数派被记录的标志账本位置，但未披露临时变更发生的原因，也未指明个别验证器的具体理由。确认的开发事实是倒计时的重置本身：一项修正案需要在完整的窗口期内获得不间断的支持，即使其票数后来恢复到相同水平，也必须满足这一要求。

因此，10 月 9 日是一个基于当前账本多数派记录推导出的条件性估计值。在激活之前，该日期可能会再次变动。

30 张赞成票意味着什么？

XRP Ledger 的门槛常被简化为“80% 支持”，但规则更为严格：一项修正案需要来自可信验证器的超过80% 的支持。在仪表板监控的 35 个验证器中，28 张票恰好等于 80%。BatchV1_1 需要至少 29 张赞成票才能启动或维持其多数派地位。

目前的 30 张赞成票约占 85.7%，比所需的 29 张多出一票。如果票数从 30 降至 29，倒计时将保持完整；但如果降至 28，则会在相应的标志账本处触发另一次重置。

TheXRPL 修正过程通常在每个标志账本周围（大约每 15 分钟一次）检查投票。一旦某项修正案在两周内获得超过 80% 的支持，该更改将永久应用于后续的账本版本。

服务器代码与主网规则是两个独立阶段

此前 Coindoo 曾解释过 BatchV1_1 如何协调关联支付指令。此次重置引发的并非该功能问题，而是当前的关键问题在于：修正后的修正案能否完成验证器流程，从而使这些交易规则在主网上生效。

服务器软件中的可用性使修正案有资格进行验证器投票。而主网的行为变化只有在网络启用该修正案后才会发生。这种分离意味着，仪表板的日期应被视为治理进展的实时估计，而非产品发布的公告。

此前的安全撤回为何现在至关重要？

BatchV1_1 是早期 Batch 修正案的修正继任者。由于研究人员发现授权漏洞，原始版本在激活前已被撤回。原始版本从未激活，因此该问题并未暴露主网用户资金的风险。

TheXRPL 漏洞披露指出，替代方案增加了对签名和授权检查的修改，并在返回投票前经过了进一步审查。这个全新的 14 天窗口是对该修订版实施情况的当前治理测试。

需关注的确认信号在账本上

只有当多数派优势在整个窗口期内得以保持时，10 月 9 日才具有意义。确认信号将来自账本记录的 EnableAmendment 伪交易（pseudo-transaction），此后 BatchV1_1 将成为后续账本的活跃主网规则。

在该事件出现之前，相关的更新内容是验证器多数派的连续性。仪表板提供了当前倒计时的有用视图，但账本的激活记录将决定修正后的 Batch 修正案是否真正跨越了进入 XRP Ledger 基础设施的界限。

本文仅供参考，不构成财务或投资建议。验证器支持和修正案状态可能会发生变化。