XRPL 修复了主网前的关键缺陷，但客户端应用程序仍然面临风险
核心要点
- XRPL 验证器将修复后的 BatchV1_1 置于条件路径上，如果支持率保持在 80% 以上，则将于 9 月 29 日激活。
- 有效负载将签名绑定到外部帐户、其序列号或票证、选定的批处理模式、每个内部交易的有序哈希值以及 BatchSigner 帐户。
- 激活后会出现有用的信号：过时的节点是否被阻止，签名
过时的节点和客户端在激活后可能会失败，而外部成功仍然可以隐藏失败的内部事务。
重写消除了一个关键的授权缺陷，并通过四种执行模式实现更安全的多事务批处理。
XRPL 验证器将修复后的 BatchV1_1 置于条件路径上，如果支持率保持在 80% 以上，则将于 9 月 29 日激活。
XRP Ledger (XRPL) 验证器已将 BatchV1_1 放在条件路径上，以便于 9 月 29 日 UTC 时间 14:06:41 激活，从而将安全性未遂事件转变为对网络修改过程及其周边软件的实时测试。
9 月 22 日，xrpldashboard 显示 35 个可信验证者中有 30 个支持该修正案，高于其显示的 28 票阈值。大多数于 9 月 15 日首次出现在账本上。
根据XRPL的修改规则，支持率必须在两周内保持在80%以上。如果跌至 80% 或更低，多数期限就会结束，因此激活日期仍然是有条件的。
9 月 29 日是首次生产测试，测试 XRPL 的验证器流程、参考实现和客户端生态系统是否将危险的预主网缺陷转换为可用的原子交易基础设施。
验证器防火墙在主网之前运行
最初的批次修正从未在 XRP Ledger 主网上激活。今年 2 月，研究人员在该修正案仍处于投票阶段时发现了一个严重的授权缺陷，建议验证者否决该修正案。
XRPL Labs 的官方漏洞披露指出，没有资金面临风险。
该缺陷存在于检查授权批次的帐户的循环中。如果代码遇到新创建帐户的签名者，其密钥与该帐户匹配，则会立即返回成功，而不是继续处理其余签名者。
攻击者可以首先放置该有效签名者，然后添加一个伪造的条目，声称授权受害者帐户。如果修正案生效，未经检查的受害者交易可以在没有受害者密钥的情况下执行。
XRPL 的回应分为两个阶段。版本 3.1.1 将原始 Batch 和 fixBatchInnerSigs 修订标记为不受支持，从而阻止其激活。 BatchV1_1 后来用重写的授权路径和额外的防御措施替换了它们。
该事件是在软件发布和协议激活之间的边界发生的故障。
XRPL 基金会的最终 XLS-56 规范现在需要一个多账户批次来包含一组精确、完整的 BatchSigners，除了其正常签名授权外部交易的账户之外，内部交易通常需要这些 BatchSigners 的授权。
缺失、多余、重复或顺序错误的条目会导致拒绝。
每个 BatchSigner 还签署了多个松散的内部交易集合。有效负载将签名绑定到外部帐户、其序列号或票证、选定的批处理模式、每个内部交易的有序哈希值以及 BatchSigner 帐户。
多重签名条目还绑定每个嵌套签名者帐户。这可以防止有效签名被提升到不同的外部交易或重新分配给另一个参与者。
合并的参考实现增加了围绕该设计的强制执行，包括签名者排序和唯一性检查、交易计数界限、拒绝直接提交的内部交易以及对账本重放的保护。
总之，这些更改解决了所公开的过早成功错误以及格式错误或重播的批数据可能跨越授权边界的相邻方式。
一个批次包含两到八个内部事务。每笔内部交易都没有签名或费用，并且有标记，因此无法单独提交。外部批次恰好选择四种模式之一：
ALLORNOTHING：每个内部事务都必须成功，否则它们的任何状态更改都不会提交。
每个内部事务都必须成功，否则它们的任何状态更改都不会提交。 ONLYONE：第一个成功的内部交易是唯一应用的。
第一个成功的内部交易是唯一应用的。 UNTILFAILURE：事务按顺序应用，直到其中一个失败。
事务按顺序应用，直到其中一个失败。独立：无论其他事务的结果如何，都会尝试每个内部事务。
BatchV1_1 可以支持原子全有或全无的流程，但并非每个批次都是狭义上的原子。开发人员还可以将其用于有序后备或独立捆绑包。
激活将风险转移到实施
最直接的集成陷阱是，即使一个或多个内部事务失败，外部 Batch 也可能返回 tesSUCCESS。客户端必须检查每个内部事务的元数据和结果代码以确定发生了什么。
这种区别在 ALLORNOTHING 模式之外很重要，在这种模式下，部分或独立执行是有意的。
BatchV1_1 支持于 8 月 6 日在 xrpld 3.3.0 中发布。一旦激活修正，不理解新规则的服务器将被修正阻止。在升级之前，它无法再可靠地验证账本或参与共识。
催化剂是什么在推动加密货币发展。为什么这很重要。了解 CryptoSlate 的重要故事以及接下来要看的内容。发布于 Substack 电子邮件地址 每周 7 天免费订阅。随时取消订阅。哎呀，看来有问题了。请再试一次。检查您的收件箱。您的注册请求已发送。如果需要确认，请按照 Substack 发送的电子邮件进行操作。如果没有看到，请查看垃圾邮件或促销活动。
针对 xrpl.js 提交的问题记录了 5.0.0 版本使用旧的有效负载构建了 Batch 签名，省略了外部帐户、序列和参与者绑定。启用 BatchV1_1 的节点使用 temBAD_SIGNATURE 拒绝了这些签名。
xrpl.js 发布历史记录了版本 5.1.0 中的兼容支持。
组件就绪点 3.3.0 中提供的过时 xrpld BatchV1_1 支持存在风险 激活后，不兼容的服务器可能会被阻止修改 xrpl.js 版本 5.1.0 添加了修订后的签名格式 版本 5.0.0 可以生成被 BatchV1_1 节点拒绝的签名 钱包 显示每个内部操作和所选模式 用户可能会在不了解其完整效果的情况下批准捆绑包 浏览器和索引器 保留外部和内部事务之间的关系 接口可以错误报告或分散批次结果
钱包和索引器行反映了详细 XLS-56 规则中的集成指南。该协议可以拒绝格式错误的签名，但它不能强迫钱包清楚地解释复杂的捆绑包或浏览器在上下文中呈现每个内部结果。
该规范还将抢先交易标记为仍在调查中的领域。更强的授权可以防止一方伪造另一个账户的批准，但它并不能消除将多个面向市场的行动打包到一个有序提交中所产生的所有风险。
9月29日将证明什么
如果多数票成立，激活将表明 XRPL 的验证程序进程可以阻止危险的修改，将操作员路由到禁用版本，然后通过相同的治理机制移动修复后的替代版本。
它还将开始现实世界的测试，测试服务器、签名库、钱包和数据基础设施是否同意新的交易格式及其结果。
它并不能证明应用程序已经采用了BatchV1_1，用户想要该功能，或者网络交易需求将会增加。修正案投票和软件发布确定了协议的可用性，但它们没有提供额外购买 XRP 的证据。