XRPL 修正案票数波动，10 月 9 日上线仍存变数

据 Woofun AI 消息， 网络备受关注的 BatchV1_1 修正案在经历短暂的投票重置后，其支持率再度回升至达标水平，使得 10 月 9 日成为目前预估的主网功能启动日期。

然而，这一时间节点并非不可更改的既定事实，而是基于当前验证者投票动态得出的暂定估算值。由于 XRPL 的治理机制要求修正案必须在完整的授权周期内持续获得足够支持，任何中途的票数波动都可能导致启动时间的再次推迟，因此 10 月 9 日这一日期仍笼罩在不确定性之中，最终能否如期生效尚待观察。

从投票动态的时间线来看，BatchV1_1 修正案的进程充满了波折。早在 9 月 15 日，该修正案便已获得 30 个验证者的支持，按照原定时间表，其主网启动时间应落在 9 月 29 日左右。

然而，这一进程在 9 月 25 日遭遇中断，原有的赞成票被集体撤销，随后又在当天晚些时候重新形成。这一撤销重投的操作直接导致启动时间向后推迟了约 10 天。截至 9 月 26 日世界标准时间 04:43，Woofun AI 整理数据显示，在被监测的 35 个可信验证者中，已有 30 个投出了赞成票。

这一数值不仅恢复了之前的支持水平，更关键的是开启了新的授权周期。尽管 XRPL 控制面板能够标识出先前赞成票被撤销以及新赞成票出现的相关 Ledger 节点，但并未说明临时变更的具体原因，也未透露个别验证者的决策依据。可以确定的是，那次重新设置本身就具有关键意义：即便后续赞成票数再次回到相同水平，修正案也必须在整个授权周期内持续获得支持才能生效，而非仅仅达到某个瞬时阈值。

深入解析 XRPL 的授权机制，可以发现其规则比通常认知的'80% 支持率'更为严格。实际上，修正案需要获得超过 80% 的可信验证者支持。在控制面板所监测的 35 个验证者中，28 票恰好对应 80% 的比例；而 BatchV1_1 修正案则需要 29 票赞成才能确立或维持其多数支持地位。目前的 30 票相当于约 85.7%，比所需的 29 票多出 1 票，这为当前的倒计时提供了一定的缓冲空间。

如果赞成票数从 30 降为 29，当前的倒计时依然有效；但如果降至 28 票，则需要在相应的 Ledger 节点上再次进行重新设置，从而重置整个授权周期。XRPL 的修正案审批流程会定期——通常每 15 分钟一次——检查各相关 Ledger 节点的投票情况。一旦某项修正案在两周内持续获得 80% 以上的支持，它就会永久性地应用于后续的 Ledger 版本。

值得注意的是， 此前曾解释过 BatchV1_1 如何实现各类支付指令之间的协同处理，而这次重新设置并未引发与该功能相关的问题。目前需要确定的则是，经过修正后的修正案是否能够完成所有必要的验证流程，从而让相关交易规则在主网上正式生效。只有当修正案被纳入服务器软件之后，它才有资格接受验证者的投票；而主网上的实际变化则要等到网络正式启用该修正案之后才会出现。正因如此，控制面板上显示的日期应被视为治理进程的实时估算值，而非产品发布的正式公告。BatchV1_1 其实是早期某个 Batch 修正案的改进版，由于研究人员发现了其中的授权漏洞，那个早期版本在主网启动之前就被撤回了。由于该版本从未真正投入运行，所以也就没有给主网用户带来任何风险。XRPL 的漏洞披露报告指出，新版修正案对签名和授权验证机制进行了调整，并在重新提交投票前经过了进一步审查。