资产管理公司正在为 XRPL Batch 做准备。它实际上能做什么？

Ripple 表示，资产管理公司正准备使用 XRP Ledger Batch。交易类型可以使多个账本操作同时成功或失败，但紧急软件版本已将注意力从 9 月 29 日的激活预期转移到 10 月 9 日的安全修正。能力是特定的。机构采用仍然具有前景的证据也是如此。

根据其发布的规范，摘要批次可以包含 2 到 8 个内部事务。

四种模式决定是否执行全部、一个、一个前缀或任何符合条件的内部事务。

XRP Ledger 版本 3.4.1 于 9 月 25 日引入了安全敏感的批量修复。

如果验证器支持持续存在，基金会预计 fixBatchV1_2 将于 10 月 9 日启用。

成功的外部批次可以掩盖失败的内部事务，除非应用程序检查其结果。

核心承诺很简单：让相关步骤在一个账本中结算。需要交付代币并接收付款的资产管理者可能更喜欢全有或全无的交换，而不是先发送资产并希望资金到达。 RippleX 描述了为该功能做准备的资产管理公司和商业项目，如之前的机构兴趣报告所述。它没有公开指定在该账户中拥有实时主网 Batch 交易的生产资产管理公司。

上一篇：Brad Garlinghouse 强调了 Ripple 无法控制 XRP 账本的原因

Ripple 只运营 XRPL 验证器的一小部分，联合创始人 Chris Larsen 遭受的价值超过 1.5 亿美元的黑客攻击表明该公司无法逆转交易或恢复丢失的 XRP 美元。 pic.twitter.com/Pt4czYNSf1 — crypto.news (@cryptodotnews) 2026 年 9 月 27 日

状态比最初的九月下旬预期发生了变化。 XRPL 基金会发布通知称版本 3.4.1 是针对安全敏感问题的紧急更新。它添加了fixBatchV1_2，要求服务器立即升级，并表示如果绝对多数支持持续存在，预计该修正案将于10月9日启用。这是一个有条件的期望，而不是一个固定的发布承诺。

批量协调一个账本内的操作关闭

XLS-0056 规范描述了两个到八个内部事务之间的外部事务。相关账户批准收款。选定的模式控制内部操作失败时发生的情况。账本一次性处理收集的数据，避免了不相关的提交之间的差距，这种差距可能会让一个参与者只赚到一半的钱。

假设基金转让代币化债券债权并收到美元代币。两笔普通交易可以单独提交。如果第一个成功而第二个失败，交易对手就会出现操作纠纷并可能造成损失。在全有或全无模式下，两个内部操作都必须成功才能完成预期的交换。这是令人信服的机构用例，假设代币、支付工​​具、交易对手和权限已经就位。

Batch 不会创建债券、验证其链下所有权或强制银行赎回支付代币。它协调账本操作。法律结算的确定性、转让限制、托管和赎回仍取决于相关文书和机构。这种区别很重要，因为技术上的原子传输只是交付与支付的一部分。

最新消息：XRP Ledger 的 Batch 功能已通过，将于 9 月 29 日激活

此次升级已获得 29 票赞成，将允许将最多 8 个 XRPL 交易捆绑为一个，从而实现原子资产互换、捆绑 DEX 交易、NFT-for-NFT 交换和单笔交易…… pic.twitter.com/7CH34N1Yat — crypto.news (@cryptodotnews) 2026 年 9 月 15 日

单账户教程展示了更简单的情况。可以将一个帐户的多个操作打包为一种指定的模式。多账户交易会添加余额或权限受到影响的账户的签名。多帐户教程描述了协调的签名过程。

四种模式产生四种不同的便宜货

ALLORNOTHING 是干净的双边贸易。每一项必要的内部行动都必须成功，否则目标群体就无法安定下来。 ONLYONE 尝试替代方案，并在第一次成功后停止，例如不同容差的订单。 UNTILFAILURE 处理序列直至失败。 INDEPENDENT 允许同一包装器中的操作独立成功或失败。在日常意义上将所有四种模式称为原子模式将隐藏部分完成的可能性。

这些模式改变了产品设计。一笔付款转移两种资产的基金需要决定单次失败的转移是否应取消整个套餐。提交后备报价的做市商可能更喜欢 ONLYONE。分配多次付款的发行人可能会容忍独立的结果，但其运营团队必须协调哪些收款人获得了付款。该模式是一个风险决定，而不是格式选择。

八个动作的上限是另一个真正的限制。根据当前提案，试图结算 1,000 名投资者转让的管理人无法将所有 1,000 名投资者合并为一个批次。理论上最少有 125 个八动作包，这些组本身彼此之间并不是原子的。在考虑链下业务流程之前，费用、签名、账户序列管理和服务能力就成为实际约束。

早期的技术报告指出了该升级的长期开发和审核历史。该背景与时间相关，但不应与构建在其之上的每个应用程序都经过审核的说法相混淆。

外部成功代码是一个会计陷阱

该规范表示，即使内部事务失败，外部 Batch 事务也可以报告 tesSUCCESS。其外部结果包括序列和费用处理。要了解是否发生了付款或交付，软件必须检查内部交易元数据和单独的结果代码。对于任何后台将一般成功状态转化为预订资产移动的机构来说，这是一个异常具体的整合风险。

想象一下，一个交易源只读取外部结果，并向客户授予代币化证券。如果相关的内部传输未成功，则 feed 和 ledger 会出现分歧。系统需要将每个内部动作与其父级及其自身的结果相关联。该规范建议在资源管理器和索引器中使用 ParentBatchID 关系。办公桌应该测试每种模式下的失败，而不仅仅是快乐的路径。

该错误可以在普通控制下幸存下来，因为外部交易是真实的并且具有交易 ID。为相当于一项业务操作的一笔交易构建的对账系统可能会通过第一次检查。适当的控制将业务指令与模式、完整的签名包、每个内部结果以及最终的资产余额联系起来。即使网络层正确，这也是资产管理者必须执行的工作。

最新消息：资产管理公司正在为 XRP Ledger 的下一次支付升级做准备

Batch V1.1 可以将最多 8 笔交易捆绑到一次操作中，RippleX 表示在激活之前已经围绕该功能构建了商业项目。 pic.twitter.com/DmleX4GBiA — crypto.news (@cryptodotnews) 2026 年 9 月 20 日

这个算术虽然朴素但很有启发性。包含八个内部交易的最大批次是一个外部提交，但它可能需要至少八个结果检查，加上外部费用和排序检查。对于代表 1,000 个内部操作的 125 个完整包，后台需要 1,000 个操作级结果，而不是 125 个绿色状态灯。

安全修复更改了激活故事

该基金会 9 月 25 日的通知称，fixBatchV1_2 拒绝使用错误包装器的内部交易，并包含额外的安全性和稳定性修复。由于更改的安全敏感性，它暂时保留源代码，并承诺稍后发布和回顾。这限制了外部人员在披露之前检查确切补丁的能力。这是精确归因的原因，而不是推测未公开的可利用性的原因。

该通知称，如果修复在未升级的情况下启用，3.4.1 以下的服务器将被阻止修改。因此，验证者投票和节点升级对于生产访问很重要。仲裁信号支持与每个钱包、托管机构、API 提供商和会计工具都为 Batch 做好准备不同。早期的 XRPL 节点升级覆盖范围说明了先前版本中修正块的操作效果。

还有一段记者不能忽略的历史。 2 月份披露的漏洞描述了早期 Batch 设计中的一个缺陷，当没有资金的签名者首先出现时，该缺陷可能会跳过对其他签名者的授权检查。该修正案尚未生效。安全审计帐户检查了独立审查如何在生产使用之前发现问题。 9 月份的补丁涉及一个单独描述的包装器问题；这两起事件都没有证明当前的设计不安全，但都解释了为什么部署时机值得仔细审查。

机构可以获得什么以及他们仍然需要什么

付款原子交付是最有力的案例。管理者可以在同一账本上协调代币转移和支付，从而限制连续转移造成的临时风险。发行人可以在协议允许这些交易类型的情况下捆绑账户设置、授权和发行步骤。贸易公司可以使用替代执行路径。这些是能力，而不是活资产和交易的证据。

代币化资产需要发行人、转让代理或其他责任实体、合格持有人的规则、托管程序以及具有可接受赎回条款的支付工具。批次可以使链上分支在选定的规则下执行。它无法使证券在另一个司法管辖区合法有效，无法获得客户对不相关行为的同意，也无法为商业银行的外部现金提供担保。

Ripple 的案例值得最强有力的版本。账本级机制可以减少开发人员的协调工作，并消除真正的部分结算失败。 XRPL 功能概述描述了 Batch 以及其他机构功能，但每个修订都遵循其自己的流程。如果指定的管理者稍后展示真实代币化资产的实时、重复结算以及正确协调的内部结果，那么采用声明背后将有确凿的证据。

界限同样明确。准备试点的公司并不是在生产中使用 Batch 的资产管理公司。没有任何公共准备声明告诉我们数量、节省的费用、防止的和解纠纷或哪个机构承担链下义务。公告可能是真实的，但要支持这些更大的结论还为时过早。

账本投票只是第一次准备测试

fixBatchV1_2 预计将于 10 月 9 日激活，具体取决于验证器的持续支持。运营商需要运行兼容的软件。按照规范的建议，钱包必须在收集签名之前向用户显示所有内部操作和所选模式。索引器必须公开父级和子级结果。托管人需要对多账户签名进行策略检查。资产管理者需要核对和法律文件。