XRPL 紧急安全补丁绕过常规投票机制引发去中心化争议

XRPL 开发者表示，他们被迫以一种绕过网络通常的修正案投票的方式部署紧急安全补丁。这一举措是在发现一个可能导致攻击者铸造超出账本固定供应量的可花费 XRP 的漏洞后采取的。该修复程序于 9 月 25 日发布，并在本周早些时候披露了漏洞赏金后对安装它的运营商立即生效。

在周日发布于 X（原推特）的一篇文章中，XRPL 开发者认为，如果等待标准的两周验证者投票，将使漏洞暴露数周之久——这给了潜在的攻击者测试和武器化该漏洞的时间。然而，这种加速方法重新引发了关于 XRPL 真正去中心化程度以及运营商是否应将协同升级视为集中控制的证据的辩论。

核心要点

• 9 月 25 日的紧急补丁解决了 XRPL 支付引擎中的整数溢出问题，在人为构造的条件下，这可能创造出超过固定供应量的可花费 XRP。
• XRPL 开发者称，他们跳过了正常的两周修正案投票，因为如果遵循标准流程，该漏洞将在公开信息泄露后的数周内被公众知晓。
• XRPL 基金会及贡献者表示，紧急决定是由多方共同做出的，同时强调验证者和节点运营商仍可选择运行何种软件。
• 批评人士对加速发布后的 XRPL 去中心化程度提出质疑；至少有一位独立验证者运营商驳斥了“协调等于集中控制”的说法。

为何紧急补丁跳过验证者投票

根据 XRPL 开发者的说法，网络的正常修正案流程会延迟补救措施，从而足以显著增加风险。他们指出，标准修正案在生效前就会变得可见，这意味着一旦细节公开，攻击者可能会利用额外时间来开发漏洞利用工具。

他们在 X 帖子中将 9 月 25 日的发布描述为有意绕过采用协议更改的常规程序。开发者表示，任何安装了该修复程序的服务器都会立即生效，这是自十多年前引入修正案系统以来首次故意规避该流程。

针对去中心化的担忧，XRPL 基金会解释说，没有任何单一实体可以单方面决定匆忙推进变更。在基金会的叙述中，绕过正常修正案路径的决定是由基金会、RippleX、核心开发人员和验证者在评估漏洞严重性后集体做出的。

基金会还强调，协议更改仍然依赖于修正案机制。他们指出，版本 3.4.1 仅在获得超过 80% 验证者支持的标准修正案投票两周后才成为必需，而跳过该流程仅适用于此次紧急修复。

“协同”升级后去中心化辩论再起

这种加速方法招致了尖锐的批评，有人认为 XRP Ledger 的治理模式及其向公众沟通的方式可能与去中心化的主张不符。

Cyber Capital 创始人 Justin Bons 表示，将 XRP 作为去中心化资产向零售投资者营销构成“赤裸裸的欺诈”，部分原因是据报道 9 月 25 日的发布仅提供了二进制文件，源代码暂时 withheld（扣留），并且运营商受到压力要求升级。

XRPL 的支持者对此进行了反驳，反对其隐含意义：即生态系统内实体的协同行动必然表明集中控制。XRPL 基金会辩称，协同不等于控制，重申验证者和节点运营商保留对其运行软件的自主权。

独立验证者运营商 XRP Kuwait 也拒绝了协同更新信号着集中控制的说法。在其声明中，它认为多个独立运营商可以评估安全局势，相互沟通，并达成共享响应，而无需放弃独立性。

争议的核心张力显而易见：紧急安全措施可能需要快速、协同的行为，但这种速度从外部看来可能表现为治理集中。XRPL 的开发人员和基金会似乎认为这是一种必要的安全选择，而批评者则认为这表明实践中的去中心化比宣传中更为有限。

漏洞性质及利用方式解析

根漏洞披露报告将错误追溯至 2015 年，并将其定性为 XRP Ledger 支付引擎中的整数溢出。

XRPL 以最大值为固定的 64 位整数存储余额。该缺陷被描述为当总和超过该最大值时发生：计算没有安全失败，而是回绕到一个较小的值。

报告中概述的攻击方法依赖于刻意构造的条件。攻击者可以设置数百个具有特殊定价的报价单，每个报价单请求大量 XRP。创建这些报价单后，攻击者将发送一笔消耗它们的单一付款。

在这些人为构造的条件下，引擎会为每个报价单所有者全额贷记金额，但仅向买方收取微小的回绕总额。差额随后表现为新创建的、可花费的 XRP。

至关重要的是，披露材料称该攻击需要刻意构造报价单，无法由普通交易活动触发。参与补救工作的开发人员还表示，他们没有发现任何公共网络上已被利用该问题的证据。

运营商和用户接下来应关注什么

虽然 immediate 问题是 XRPL 的紧急响应是否必要且处理得当，但更长期的问题是如何解读未来的治理决策——尤其是在安全紧迫性与标准修正案时间线发生冲突时。读者应关注有关紧急流程的进一步澄清，包括透明度如何与风险取得平衡，以及未来的修复是否继续遵循类似的剧本。