验证者支持跌至26/35,XRP账本漏洞修复推迟至11月4日

验证者支持一度跌至26/35

XRP账本最新一轮漏洞修复被推迟到了11月,距离原定上线不足两天,原因只是验证者支持在两小时内出现了一次下滑。这项名为fixCleanup3_4_0的修正案原计划于10月23日星期五09:34(UTC)生效,如今这一时点已经作废,新的倒计时把上线时间推到11月4日14:46(UTC)。修改账本规则需要35个受信任验证者中超过80%投出赞成票,即至少29票。10月21日星期三12:54(UTC)的检查点上,35票中只有26票赞成,XRPL Dashboard实时记录下了这一读数。三名验证者在两小时内先后撤回支持,仅此一步就足以让接近跑满14天的批准计时器归零。到14:46(UTC),赞成票回升至29票,一个新的14天窗口随之开启。目前支持率为31/35,高出门槛两票,XRPLWin追踪页已将11月4日列为激活日期。至少自10月19日星期一起,这项修复一直只有最低限度的票数,因此这一次重启,它带着第一次所没有的余量。对XRP而言,这次挫折属于流程层面而非结构性问题:没有资金面临风险,没有任何交易被回滚,网络也继续按现行规则运行。损失的只是时间,以及一个节点运营商早已按计划围绕它做准备的星期五上午切换窗口。投票是持续进行的,而不是一次性表决,这正是单个检查点分量如此之重的原因。两周的强制周期意味着任何一次归零之后,最早也要整整两周才能上线,10月23日变成11月4日就是这么来的。XRP价格在整个事件中只是次要问题,修正案记录显示的是一次时间安排上的滑坡,而非市场事件。

14天修正案门槛的运行机制

这套机制没有留下任何容错空间。网络大约每15分钟轮询一次修正案支持情况,票数必须在连续14天里的每一次检查中都保持达标;哪怕只错过一次、无论多短暂,计时器就归零。门槛被刻意设计得严苛:它让节点运营商有时间在规则变更生效前升级自己的服务器,也防止一个短暂的多数派强行推动变更。票数同样从不冻结,35个受信任验证者中的任何一个都可以在检查点上把赞成票在修正案之间移动,票数之所以能在两小时内跌到26又爬回来,靠的正是这一点。fixCleanup3_4_0偏偏在计时器只剩不到48小时的时候掉了链子。

补丁本身是一次覆盖面不小的安全清理。它封堵了一个围绕代币创建的漏洞,并调整账本处理金库与借贷计算的方式。这类计算决定抵押品如何被对待、何时适用清算,与建立在现实世界资产之上的信贷市场所依赖的属同一类逻辑。建立在这些金库规则之上的更广义借贷体系,尚未获得足够验证者支持来启动自己的14天倒计时,因此其时间线不受本周归零的影响。

对节点运营商来说,实际效果是现状再延续两周。除非支持率再次崩塌,服务器会按现行规则一直运行到11月4日,原本排在星期五上午的升级工作整体后移。归零改变的是运营商的动手时间,而不是代码生效后做什么。门槛纪律虽然不近人情,但每一个靠验证者共识完成升级的山寨币都要跨过同一道坎,XRP账本的流程也完全按白纸黑字公开走完了每一步,精确到时间戳。周三的归零因此把账本的借贷雄心留在原地,等待属于它自己的29票门槛。

余量仅两票,规则未添任何新保险

我们的判断是:这次险些翻车关乎修正案设计,而非资产本身。一个只通过验证者共识变更规则的网络,也就是这种治理方式作为web3核心纪律的所在,必须接受一项修复可以停在离终点一票之遥的地方仍然失败。事后没有任何新的程序性保障被加入,15分钟轮询和完整的14天时钟原样保留,唯一的保护是算术:31/35意味着即便再失去两名验证者,11月4日之前的每一次检查仍然可以达标。市场层面,XRP最近曾单日反弹增加41亿美元市值,这次归零落地时并没有明显的价格驱动因素;想把新日期与当前水平放在一起权衡的读者,可以从我们的XRP技术分析入手,而11月30日XRP看至4美元的论据在于采用进度,11月4日不过是把它重新排期而已。