XRP账本即将迎来新的支付更新

区块链文库报道：

核心要点

在检查时，Batch V1.1 已获得 27 位支持者的认可。该提案需要获得为期两周的 80% 支持率才能激活。一个批次（Batch）可以包含八个关联的交易。全部或无（All-or-nothing）模式可避免部分完成的情况。首个 Batch 版本从未激活。

XRP Ledger 的 Batch V1.1 修正案进展

根据 XRPScan 追踪的数据，XRP Ledger 的 Batch V1.1 修正案在检查时已获得 35 位验证者中的 27 位支持。该修正案正接近激活所需的 80% 门槛。若获通过，它将允许应用程序将多达八个相关的交易归组为一个 Batch 操作。其实际目的是使多步骤支付和交易流程更加稳健。应用程序可以将一系列必须同时发生的指令链接起来，而不是将它们视为可能因中途失败而导致流程不完整的事件。

需要两周的 80% 支持率

在被追踪的 35 位验证者中，达到 80% 阈值需要 28 位验证者支持。这将启动激活期；随后，支持率需连续保持两周稳定，Batch V1.1 才能成为 XRP Ledger 的规则。这两周的时间给予了验证者审查修正案并确认支持率稳定的机会。代码可以包含在服务器软件中而不改变主网行为，但验证者必须先表明他们已准备好按照相同的规则运行它。

批次如何防止半完成的支付

Batch V1.1 允许最多八个关联的交易一起提交。账本将在同一个账本关闭周期内检查和记录所选指令，而不是要求每个步骤单独提交和确认。以市场销售为例：买方发送付款，卖方转移资产，市场收取费用。在 Batch 的全部或无模式下，所有必需的指令要么全部成功，要么整个批次失败。买方不会陷入已经付款却未收到资产的局面。

全部或无模式的相关性

当支付的每个部分都必须共同成功时，全部或无模式是相关的选择。

Batch V1.1 概览

• 最多八个关联交易：一个 Batch 可以包含多达八个连接的指令。
• 全部或无保护：每个必需的指令共同完成，否则账本拒绝整个批次。
• 涉及多个账户：批次可以协调涉及多个参与者的指令。
• 不会自动改变的方面：Batch 不会改变账本关闭速度，也不要求每个钱包和市场都支持它。

V1.1 取代了之前被叫停的 Batch 修正案

原始的 Batch 修正案在检查批次内交易的授权方式上存在缺陷。安全研究人员在二月发现该问题，当时该功能仍在等待激活。建议验证者在它到达主网之前撤回支持，因此该缺陷从未影响用户资金。漏洞披露详情记录了这一响应，并将早期的 Batch 实施标记为不受支持。Batch V1.1 用移除已识别逻辑问题的新实现替换了旧版本。RippleX 表示，修订后的版本在进入当前投票程序之前，还经过了额外的代码审查、测试和外部安全评估。

随着修订后的代码现在接近所需的支持水平，Batch 比几个仍在等待验证者批准的 XRPL 功能走得更远。

Batch 比 XRPL 计划的借贷系统更接近通过

Batch 的投票可以与另外两个正在通过修正案过程的 XRP Ledger 变更一起查看。fixCleanup3_3_0 提案侧重于影响金库、自动化做市商和许可交易的维护和安全问题。它改进了现有的交易路径，而不是创建新的面向消费者的支付工具。而计划的机构信贷系统则相对滞后。它需要单资产金库（Single Asset Vaults）和借贷协议（Lending Protocol）都获得足够的验证者支持；仅批准其中一个无法形成可用的借贷市场。

Batch 的作用范围较窄。它为应用程序提供了一种协调 XRP Ledger 上现有交易（包括支付、转账和费用）的方法。其 27 位支持验证者使 Batch 比原生借贷所需的两个修正案更接近激活阈值，尽管活跃的修正案仍仅为应用程序集成提供工具。

激活将使 Batch 对开发者可用

如果 Batch V1.1 完成激活过程，钱包、市场和其他服务将决定是否将其添加到产品中。钱包用户可能只有在应用程序能够一次性完成支付和资产转移，而不是在一步失败后要求重试时，才会注意到这一变化。潜在的早期集成包括那些已经为一个客户请求组合多个动作的服务。Batch 将使这些服务能够定义哪些指令必须在操作被视为完成之前完成。

Batch 使复杂的支付流程更稳健

Batch V1.1 本身不会改变日常的 XRP 转账，因为它的价值更为具体：应用程序可以链接多个必需的指令，避免将部分完成的支付或交易视为已完成。如果修正案完成其激活期，开发者可以开始将 Batch 添加到实时的 XRP Ledger 服务中。

本文仅提供信息目的，不构成财务或投资建议。验证者支持和修正案状态可能会发生变化。