XRP账本批量修正案：为何2026年9月29日是节点运营商的硬性截止日期

2026年9月29日：XRP Ledger 批量更新（BatchV1_1）协议升级详解

2026年9月29日 UTC时间14:06:41，XRP Ledger 将迎来一次协议升级，此次升级携带的内部名称为“BatchV1_1”。如果您将 XRP 存放在交易所或托管钱包中，您无需采取任何行动。但如果您是独立节点运营商，或基于自有节点提供服务，这一天是硬性截止日期；在此日期之后，您的服务器将从网络中脱落。

本文旨在解释该更新的具体变更内容、日期的由来、如何自行检查状态以及该日期所附带的注意事项。本文中的所有数据均源自已验证的分类账本及协议文档，而非官方公告。

什么是 XRP Ledger 的更新（Amendment），为何不需要关机日期

更新（Amendment）是指对 XRP Ledger 协议规则进行的更改，由网络的受信任验证者投票决定，而非由某家公司安排日程。这与经典的硬分叉不同，后者通常有宣布的区块高度和日历条目。在这里，没有人为设定的日历记录，只有网络是否满足条件的判定。

背后的规则写在协议文档中，且非常简短：一项更新需要获得超过 80% 的受信任验证者的批准，并且这种批准必须连续保持两周。只有满足这两个条件，更新才会激活。如果在两周内任何时候批准率低于阈值，即使只是短暂瞬间，倒计时也会从头开始。

对于读者而言，这意味着两点：第一，此类日期是可以验证的，因为它存在于分类账本中，而非新闻稿里；第二，在两周倒计时结束前，该日期并非不可移动。这两点是当前讨论日期的核心所在。

BatchV1_1 批量更新的技术细节

批量（Batch）是一种新的交易类型，它将多个单独的交易捆绑成一个包进行统一处理。根据协议参考文档，一个包包含至少两个、最多八个内部交易，这些交易也可以来自不同的账户。在此之前，XRP Ledger 要求用户单独提交每一步操作，并祈祷每一步都能成功执行。

其实际收益在于确定性。如今，如果用户依次提交两步操作（例如先批准，后兑换），会面临第一步成功而第二步失败的风险。批量包填补了这一空白，因为网络知晓处理规则并强制执行它。

如果我的 XRP 存放在交易所，我需要做什么吗？

不需要。这是最常见的情况，也是影响最小的一种。如果您的 XRP 存放在交易平台或托管钱包中，基础设施由提供商运行，升级的责任也在于他们。您无需转移资产、卖出或更改地址。因协议日期而匆忙转移余额主要会产生手续费，并在必要时引发不必要的税务事件。

尽管如此，这是一个冷静盘点的好时机，但这与日期无关。您是否清楚哪些提供商持有您余额的哪部分？那里的提现费用是多少？提供商是否在欧盟受到监管？无论协议日期如何，这些都是更重要的问题。

如果我在自托管模式下持有 XRP，该检查什么

即使在自托管情况下，通常也很简单。硬件钱包存储您的私钥并使用它签署交易；通常情况下，它通过钱包提供商的服务器连接到网络。密钥本身不会受到更新的影响，因为更新改变的是链的规则，而不是您的地址或访问权限。

您可以做的是保持用于连接钱包的软件处于最新状态，并在日期之前检查一次您的助记词是否存放在您认为安全的地方。这是基本的卫生措施，且在9月29日之前这样做是正确的。如果您还在犹豫选择哪种设备，我们的硬件钱包比较指南会有所帮助。

更新阻塞：9月29日过时 xrpld 节点会发生什么

更新阻塞（Amendment-blocked）是指服务器因不了解已激活的协议规则而进入的状态。协议文档明确描述了后果：被阻塞的服务器无法再验证分类账本，无法再提交或处理交易，无法参与共识，也无法对未来更新进行投票。

决定性的一句话就在旁边：服务器的投票配置对此没有任何影响。无论您是设置 xrpld 反对该更新还是赞成该更新，在激活后，两者都会被阻塞。导致服务器被阻塞的原因是缺少理解新规则的代码。无法违背已激活的多数决。

服务器在此过程中不会崩溃，也不会抛出明显的错误信息。它仍在响应，但不再提供来自运行中链的有效数据。这正是该状态对后台查询自有节点的服务构成危险的原因：应用程序看起来健康，并提供停止更新的数据状态。

2026年9月29日这一日期从何而来，是如何得出的

该日期是经过计算的，既非推导也非估算。已验证的分类账本中包含一个跟踪每项更新状态的对象。其中有一个名为 Majorities 的字段，对于达到阈值的每项更新，该字段记录了两周倒计时的起始时间点。

本编辑团队于 2026年9月18日 UTC时间约00:35 通过公共 XRP Ledger 节点（分类账索引 107058182，HTTP 200 响应）查询了该对象。Majorities 字段仅包含一条记录：标识符为 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 的更新，其 CloseTime 值为 842796401。

XRP Ledger 从2000年1月1日开始计算时间。转换该值可得 2026年9月15日 14:06:41 UTC 为周期开始时间。两周后的 2026年9月29日 14:06:41 UTC 即为截止日期。通过同一节点的 feature 查询交叉核对，返回了相同标识符的名称 BatchV1_1，以及值 enabled: false 和 supported: true。因此，网络已知晓该更新并支持它，但尚未激活。

如何自行检查更新的狀態

您不需要拥有自己的节点。公共 XRP Ledger 端点可以通过单次请求回答此问题。熟悉命令行的人可以将上述标识符发送到公共节点并发出 feature 请求，然后从答案中读取三个字段：

enabled：如果读数为 false，则更新尚未激活。一旦值变为 true，即表示激活已完成。supported：如果读数为 true，则您查询的节点软件已经知晓该规则。如果读数为 false，则该节点将在激活时被阻塞。majority：两周倒计时运行的时间戳。如果该字段再次消失，说明多数票滑落，倒计时已重置。

正是因为第三点，您应该在日期临近时再次查看状态，而不是记下日期后就置之不理。对于自有节点，路径相同，但有一个重要区别：将 feature 查询发送给您的服务器，而不是别人的。只有您自己节点的回复才能告诉您关于您自身节点的情况。

哪个软件版本带来了新规则

XRP Ledger 的服务器软件称为 xrpld，作为开源软件发布。最新版本是 3.4.0，发布于2026年9月17日；此前是2026年8月6日的 3.3.0（两个日期均来自官方源代码存档的发布日期，检索时间为2026年9月18日）。

从文章中复制版本号仍然是较弱的方法。可靠的答案来自您自己的服务器通过 supported 字段：它回答了正在运行的软件是否真正知晓该规则的问题。您认为自己运行的是哪个版本并不重要。如果那里显示 false，只有更新能解决问题，且必须在9月29日之前完成。

为何该日期附带注意事项

两周倒计时持续的条件是批准率保持在80%以上。如果跌破该阈值，计数器将重置，9月29日也将失效。这不是理论上的注脚，而是程序内置的安全机制。它让验证者在最后一刻仍有机会，如果在此期间出现问题，可以叫停更改。

对于您的规划，由此得出一个简单的立场：将9月29日视为准备工作的截止日期，并将其到来视为未定。如果倒计时重置，更新节点的任何人不会失去任何东西。但如果有人因为日期可能取消而推迟更新，结果相反，系统将脱离链条。

批量包的四种模式及其在日常使用中的含义

提交批量包时会赋予其一种模式，该模式决定了网络如何处理故障。协议参考命名了四种模式：

AllOrNothing（全有或全无）：包中的每一笔交易都必须成功。如果有一笔失败，整个包失败。这适用于只有在完整执行才有意义的序列。OnlyOne（仅一个）：只要第一笔交易成功，其余交易将被跳过。允许提交备选方案，其中只应生效一个。UntilFailure（直到失败）：交易按顺序运行，直到一笔失败；之后的所有交易都被丢弃。这适合相互依赖的序列。Independent（独立）：所有交易彼此独立处理，无论个别交易是否失败。这是纯粹的捆绑，无链式连接。

作为持有者，您很少亲自设置这些模式。差异在应用程序使用时变得明显：在将多个步骤收集到一个确认中的钱包界面中，以及在交易应用中，半执行的序列一直是迄今为止最棘手的情况。

服务提供商、钱包提供商和支付处理器现在应澄清的事项

任何通过自有基础设施而非外部提供商访问 XRP Ledger 的人都受到影响。这包括支付服务、交易应用、具有自有数据源的会计工具，以及提供商运行节点的钱包。在该日期之前，需要回答以下三个问题：

数据源是针对自有节点还是外部端点？如果是外部端点，责任在于其运营商，您应在彼处询问，而非自行行动。您的自有节点报告 BatchV1_1 的 supported 值为 true 吗？如果不是，则需要更新，留出测试和维护窗口的常规时间。停止移动的数据状态会在您的监控中显示出来吗？被阻塞的节点仍在响应。仅检查可达性的监控无法察觉此事。只有监控最后已验证分类账与当前时间之间差距的人，才能立即发现异常。

经验表明，第三个问题是关键所在。伪装成正常运行的中断往往被发现得较晚，而在此期间，记账和显示继续使用旧数据工作。

该日期在此前的更新流程中处于什么位置

该程序在 XRP Ledger 上是例行公事，每年运行多次。最近一次，在2026年9月9日，我们描述了前一项更新的激活过程；任何希望从头阅读整个过程的人，可以在我们关于钱包、节点和持仓检查点的文章中找到相关指引。机制相同，只是这次涉及具体的日期和开放条件。

对于整个网络的定位，观察在其上构建的内容比任何单一的协议步骤都更具指示意义。2026年2月的一个例子是法国兴业银行（Société Générale）的欧元稳定币，它在 XRP Ledger 上发行。这类应用正是绑定交易包需求产生的原因：任何自动化支付序列的人都不希望出现半执行的链条。

XRP Ledger 批量更新：总结要点

如果您的 XRP 存放在提供商处，什么都不用做。至多利用该日期冷静检查提供商是否仍适合您。如果您持有自己的硬币，请检查访问权限和恢复方式，而非协议本身。您的密钥不受更新影响。如果您运行自有节点，请在9月29日之前发送 feature 查询。如果 supported: false，请更新软件。

本文的主要来源：XRP Ledger 官方文档中的更新程序描述和批量交易的协议参考。（截至2026年9月18日。本文不构成投资建议。价格和费用结构会发生变化；购买前请与提供商核实条款。）