XRP账本fixCleanup3_4_0安全修复锁定10月23日激活

更新 18:12 UTC：截至10月17日XRPL仪表板的最新投票数据显示，该安全修正案保持原有位置：fixCleanup3_4_0获得29票支持，比当时生效的28票门槛多出一票，使10月23日09:34的激活预估维持不变。

80%票数触发两周倒计时

XRP账本已确定fixCleanup3_4_0修正案在10月23日约09:34(UTC)激活,前提是验证节点支持率保持在协议要求的80%绝对多数门槛之上。该修正案于10月9日越过这道门槛,随后进入强制性的两周倒计时。浏览器追踪数据显示,截至10月中旬,32至35个参与投票的验证节点中约有26至29个投了赞成票。日程安排上有一道保险:若在激活前支持率回落到80%或以下,倒计时即告重置,修正案必须重新不间断地获得足够票数并再等两周。这一机制的存在是为了杜绝“软共识”,因为一项在支持摇摆状态下激活的补丁可能造成网络分裂。倘若在最后两周内支持率跌破底线,安全修复将至少推迟两周;对账本运营方而言,与其在共识分裂的情况下上线变更,不如接受这样的延迟。

与引入新交易类产品的协议变更不同,这次更新修补的是现有软件的行为。补丁随Ripple 3.4.0版本一同发布,覆盖借贷基础设施、自动做市商、代币处理、托管交易以及账户权限等模块。账本上的修正案只有在形成持续的绝对多数共识后才会改变行为,因此升级时间表以验证节点投票而非发布日期来表述。日常账户余额和XRP价格都不在此次变更的影响范围之内;兼容性压力落在节点运营者身上,变更生效后他们需要更新软件才能继续跟随网络的共识机制。

PaymentBurn缺陷与借贷提案搁浅

这批修复中最尖锐的一项涉及PermissionDelegationV1_1.1。该功能于10月8日激活,允许账户所有者向另一账户授予有限权限,在不交出账户私钥的情况下代为执行特定操作。其中一项名为PaymentBurn的委托权限本应让被授权方销毁指定代币,但软件缺陷意味着在某些条件下该操作反而会凭空创造代币,效果与设计意图完全相反,且直接触及代币供应。XRPL官方文档中关于权限取值的说明已提醒节点运营者,在清理修正案上线之前不要授予这项特定权限。更新中的其他修复还包括纠正金库提款的计算方式、收紧贷款逾期判定规则,以及防止部分自动做市商交易在不返还底层资产的情况下销毁流动性代币,这一角落正是活跃于收益耕作中的流动性提供者密切关注的对象。

不过,产品本身的审批已经搁浅。拟议中的借贷协议将允许用户在账本上汇集资产并按固定条款借款;借款人未必需要提供抵押品,经纪商则在链下安排贷款条款并评估信用状况。整套系统上线需要三项独立修正案同时生效,10月15日至17日期间,两项借贷修正案各自仅有约17至19名支持者,约53%,而作为必要配套的SingleAssetVault修正案约有19至21名支持者。三者均未达到绝对多数,因此该功能没有激活日期。把XRP存放在钱包中的持有者,包括使用离线Ripple纸钱包的用户,无需采取任何操作;不过委托权限缺陷再次提醒人们密钥纪律在实践中如何失守,这正是我们此前报道中David Schwartz关于钓鱼链接骗局的警告主题。

把两组投票放在一起看,验证节点显然把优先级放在了修复而非金融产品上。10月23日将加固借贷系统赖以运行的底层轨道,但产品本身要等三项修正案各自越过同一道80%门槛后才会开启,目前没有时间表。接下来的两周是真正的考验:激活前支持率只要跌破一次底线,倒计时就会重置、安全修复随之延期;而一旦顺利通过,节点运营者便能消除自10月8日委托功能上线以来官方文档一直在警示的销毁权限风险。

截至10月17日XRPL仪表板的最新投票数据显示，该安全修正案保持原有位置：fixCleanup3_4_0获得29票支持，比当时生效的28票门槛多出一票，使10月23日09:34的激活预估维持不变。借贷类修正案则仍未达到同一门槛，LendingProtocol与LendingProtocolV1_1各为19票，SingleAssetVault为21票，均低于28票，不过票数仍可能变动。仪表板数据还阐明了单一资产要求背后的机制，描述了一种结构：存款人将资产汇集到金库中，经纪商管理贷款，而XLS-66草案在账本上处理执行与还款，信用评估和风险管理则留在链下。两条轨道各自独立推进，借贷功能没有激活时间表。