XRPL 仪表板在 9 月 26 日 04:43 UTC 被查询时，记录到其追踪的 35 个受信任验证者中有 30 张赞成票。该票数为 BatchV1_1 修正案开启了新的批准窗口——但这本身并不意味着激活流程已完成。

要点：

• BatchV1_1 重新获得 35 张验证者选票中的 30 张。
• 此前的两周批准计时已重置。
• 现在必须保持至少 29 票。
• 10 月 9 日是最早的有条件日期。
• 账本上的激活才确认升级。

尽管票数恢复，日期仍被重置

BatchV1_1 于 9 月 15 日达到 30 个支持验证者。按原定时间表，这将使激活时间落在 9 月 29 日前后。随后多数票于 9 月 25 日被移除，并在当天晚些时候重新形成，使估计时间推迟约 10 天。

该仪表板标明了此前多数票被移除以及新多数票被记录所在的标记账本，但并未披露这一临时变化发生的原因，也未说明个别验证者的理由。已确认的变化就是重置本身：一项修正案需要在整个窗口期内保持不间断的支持，即使其票数后来恢复到相同水平也是如此。

这使 10 月 9 日成为基于账本当前多数票记录得出的有条件估计。该日期在激活之前仍可能再次变动。

30 张赞成票仅高出门槛一票

XRPL 的门槛常被简化为"80% 支持"，但规则实际上更严格：修正案需要获得超过 80% 的受信任验证者支持。在仪表板监测的 35 个验证者中，28 票恰好等于 80%。BatchV1_1 需要 29 张赞成票才能建立或保持其多数地位。

当前 30 票约等于 85.7%，比 29 票的要求仅多出一票。若从 30 票降至 29 票，倒计时将继续；若降至 28 票，则会在相关标记账本处触发另一次重置。

XRPL 修正案流程围绕标记账本检查票数，通常约每 15 分钟一次。这些标记账本充当衡量支持的周期性检查点，只有当票数保持在门槛之上时，两周计时才会推进。一旦修正案在两周内保持超过 80% 的支持，该变更将永久应用于后续账本版本。

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

Coindoo 此前解释过 BatchV1_1 如何协调关联的支付指令。该功能并非此次重置所涉及的问题。当前的问题是修正后的修正案能否完成使这些交易规则在主网生效所需的验证者流程。

在服务器软件中可用只是使修正案有资格接受验证者投票，而主网行为只有在网络启用后才会改变。正是这一分离，使得仪表板上的日期应被视为对治理进展的实时估计，而非产品发布公告。

此前的安全撤回为何现在仍然重要

BatchV1_1 是此前一个 Batch 修正案的修正后继版本；在研究人员发现授权缺陷后，该修正案在主网激活之前被撤回。原始版本从未被激活，因此该问题并未使主网用户资金面临风险。

根据 XRPL 漏洞披露，替代版本对签名和授权检查进行了更改，并在重新进入投票前接受了进一步审查。这一事件表明该流程按设计运作：在服务器软件中可用的代码，仍可在改变主网规则之前被叫停。新的 14 天窗口是对该修订实现的当前治理考验。

需要关注的确认来自账本本身

只有在整个窗口期内多数票保持不变的情况下，10 月 9 日才有意义。确认将来自账本记录的 EnableAmendment 伪交易，此后 BatchV1_1 将成为适用于后续账本的主网活跃规则。

在该事件出现之前，相关更新内容是验证者多数票的持续性。仪表板为当前倒计时提供了有用的视图，但账本的激活记录才能决定修正后的 Batch 修正案是否真正跨入 XRPL 实际运行的基础设施。

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