验证人支持重置,XRP 账本 Batch 升级推迟至10月9日

Batch倒计时重置,最早激活时间推至10月9日

XRP账本的旗舰升级Batch在激活时间表上至少损失了十天。允许用户将最多8笔交易打包为单一原子操作的修正案BatchV1_1,自9月15日起一直朝着9月29日的激活日倒计时,但验证节点支持率一度跌破维持计时所需的门槛。按照该账本的修正案规则,一项协议变更必须在连续两周内获得超过80%受信验证节点的支持方可生效,而一旦支持率跌破该线,此前累积的等待时间即被清零,即便投票在数小时内恢复也无济于事。我们查看的XRPL修正案面板显示,截至9月25日,BatchV1_1的支持回到35个受信验证节点中的30个,最早可能的激活时间被重置为10月9日约14:46(UTC)。

Batch改变的是执行语义,而非原始吞吐量。其「要么全成、要么全不成」的选项意味着,购买代币化资产的买方可以将付款与资产交割合并为一次操作完成,交易的任何一方都无法单独完成——这一结构直指代币化资产结算与付款对交付(PvD)风险。该功能其实已是第二次尝试:最初的Batch实现因开发者发现一个关键的签名校验缺陷,在主网激活前被撤回,修正后的版本于8月随运行该账本的软件xrpld 3.3.0一同发布。RippleX工程负责人Ayo Akinyele曾表示,一些项目已经在围绕Batch进行开发,激活将使这些工作更接近生产环境,不过他并未点名合作方或给出上线日期。这次支持率下滑似乎只持续了很短时间,但规则没有留下任何余地:支持率迅速恢复,日历却没有。

委托授权升级同样顺延

另一项修正案也在同一套时钟上被顺延。PermissionDelegationV1_1允许账户所有者授权另一账户执行特定的获准任务,而无需交出控制其资金的签名密钥。该修正案于9月23日失去合格支持,一天后重新达标。这次重置将其最早激活时间从10月5日推迟至10月8日约21:25(UTC)——这意味着,只要支持率保持稳定,该账本两项待生效修正案将在约24小时内先后落地。我们查阅的面板记录显示,两项修正案遵循同一模式:支持率丢失、一天内恢复,而全部日历代价都体现在激活日期上,代码本身并未改动。

委托机制对机构的意义最为直接。作为一条专为支付而构建的layer-1网络,其上的代币发行方可以将支付执行与合规检查分配给不同的运营账户,而无需暴露守护金库的主密钥——这正是传统金融中审计师所期待的职责分离。与Batch结合后,委托授权为实现角色分离的原子化结算流程打开了大门:一个账户被授权交付资产,另一个账户被授权释放付款,每一动作要么同时执行、要么同时失败。验证节点——即核验交易并对网络变更投票的运营方——实际上在一周之内同时为两项修正案踩下了刹车。这并非技术故障,而是该账本刻意保守的激活机制按设计运转:共识支持一旦出现任何波动,就重新开启两周的观察窗口,而不是在支持减弱的情况下强行推进变更。对市场参与者而言,实际影响是10月中旬出现一个被压缩的时间窗口,两项治理变更可能接连生效,各自重塑这条网络的结算与账户授权方式——而这条网络的活动正日益成为XRP生态的锚。希望实时跟踪行情的读者,可以在Binance查看现货与期货的实时价格。

10月8日与10月9日是关键日期

伴随Batch推迟,还有一条独立的新进展:XRP账本核心团队发布了xrpld 3.4.1,这是一个针对安全敏感问题的紧急版本。该更新打包了与Batch交易相关的fixBatchV1_2修正案,服务器运营方被敦促尽快升级——如果该修复随10月9日的Batch窗口一起激活,仍在运行旧版本的服务器可能失去与网络的同步。此版本并不改变XRP的供应量或使用规则,但在10月中旬这一时段,它在维持共识支持稳定之外,又给节点运营方增加了一项待办。眼下关注的焦点是,验证节点支持率能否在上述日期之前持续保持在80%的门槛之上。

（截至 01:01 UTC） (截至UTC时间01:01)我们的判断是:双重重置与其说是挫折,不如说证明了该账本的治理机制用速度换取可预测性,对XRP价格的直接影响应当有限。两项修正案均已随xrpld 3.3.0发布,节点运营方除保持支持稳定外无需额外操作。如果共识保持稳固,10月8日和10月9日就是值得紧盯的日期——批量交易加委托授权,将推动网络更接近代币化资产与PayFi工作流所需要的原子化、角色分离式结算。延期期间机构需求仍在延续,XRP ETF资金流入近期由Bitwise领跑,单日买入达991万美元;同时30天数据显示,XRPL上的AI代理正将结算偏好转向Ripple USD——这提醒我们,无论升级日期如何变动,这条账本的支付叙事仍在持续演进。