XRP Ledger 运营者必须在 9 月 29 日截止日期前升级至 xrpld 3.3.0

截至 9 月 29 日（星期一）仍未运行 xrpld 3.3.0 的每台 XRP Ledger 服务器，都将在 Batch 修正案于约 14:06 UTC 激活时被切断与网络的连接。本月，该修正案以约 82.86% 的支持率超过了 XRP Ledger 验证者 80% 的支持阈值，触发了为期两周的强制倒计时，并于 9 月 29 日结束。Batch 启用后，任何运行旧版本的验证者、交易所或企业，其服务器都会被该修正案阻断——在升级前无法处理已验证账本，也无法参与共识。该截止日期影响自行运行 XRP Ledger 软件的运营方，包括验证者、交易所、托管机构、支付服务提供商以及直接读取账本的 API 服务。持有 XRP 的用户，以及在运行最新节点的交易所上进行交易的用户不受影响。周四，XRP 交易价格约为 1.47 美元，当日下跌约 2%，但本周上涨约 13%。

周一被修正案阻断的服务器将停止验证

Batch 激活后，任何无法识别该修正案的服务器都无法再就每个新账本的内容与网络其他部分达成一致。服务器会停止应用交易、停止验证，并退出共识，直到运营方安装兼容版本。XRP Ledger 官方文档指出，没有兼容版本的服务器无法正确处理已验证账本。

被修正案阻断的验证者将停止为共识作出贡献。运行被阻断节点的交易所或托管机构可能会看到充值和提现停滞，因为其账本视图已经冻结。从被阻断服务器读取数据的 API 提供商和区块浏览器会开始返回过时数据。恢复服务需要升级到 xrpld 3.3.0，并等待服务器重新同步。

82.86% 的验证者支持率确定 9 月 29 日截止日期

时间安排源自 XRP Ledger 的修正案激活规则。修正案通过验证者投票激活；一旦某项修正案连续两周获得至少 80% 的受信任验证者支持，就会在下一个标志账本自动启用。在链上实时投票中，BatchV1_1 以约 82.86% 的支持率超过了该门槛，启动了为期 14 天的倒计时，并于 9 月 29 日约 14:06 UTC 结束。

截止日期在到来前仍可能发生变化。如果验证者支持率在两周结束前跌回 80% 以下，倒计时将重置，激活时间也会推迟。截至本周，支持率稳定高于该门槛。3.3.0 版本共包含六项新修正案，其中五项仍在争取验证者支持，而 Batch 已经获得了足够的支持。

Batch 将八笔交易捆绑并以原子方式执行

Batch 允许用户将最多八笔交易捆绑起来，并根据选定的规则一同执行，其中包括全有或全无模式，即交易组中的每笔交易要么全部成功，要么一笔都不执行。这种原子性使兑换和支付等多步骤操作能够作为一个整体完成结算，而不会面临只执行一部分的风险。

版本号反映了一次失败的尝试。最初的 Batch 修正案在出现严重漏洞后被禁用，随后 RippleX 以 BatchV1_1 的形式重新提交了修正后的代码，而 xrpld 3.3.0 搭载的正是该版本。Ripple 表示，资产管理机构正准备在该功能上线后使用批量结算，而同一 3.3.0 版本周期还为 XRP Ledger 借贷协议和其他机构级功能奠定了基础。

运营方可以通过对节点运行 server_info 来检查是否准备就绪；一旦服务器落后，该命令就会返回 amendment_blocked 标志。解决方法是在周一的标志账本到来前安装 xrpld 3.3.0 并重启。团队可以将备用节点指向测试网进行演练，因为该修正案已经在测试网上线。

常见问题

9 月 29 日未运行 xrpld 3.3.0 的 XRP Ledger 服务器会发生什么？

截至 9 月 29 日（星期一）约 14:06 UTC 仍未运行 xrpld 3.3.0 的服务器，将在 Batch 修正案激活时被修正案阻断。被修正案阻断的服务器会停止应用交易、停止验证并退出共识，直到运营方安装 xrpld 3.3.0 并重新同步服务器。

为什么 Batch 修正案将 9 月 29 日设为截止日期？

BatchV1_1 修正案以约 82.86% 的支持率超过了 XRP Ledger 验证者 80% 的支持阈值，根据账本的修正案激活规则触发了为期两周的强制倒计时。倒计时将于 9 月 29 日约 14:06 UTC 结束，届时该修正案将在下一个标志账本自动启用。

Batch 修正案在 XRP Ledger 上有什么作用？

Batch 允许用户将最多八笔交易捆绑起来，并根据选定的规则一同执行，其中包括全有或全无模式，即交易组中的每笔交易要么全部成功，要么一笔都不执行。这种原子执行允许兑换和支付等多步骤操作作为一个整体完成结算，而不会面临只执行一部分的风险。