在多数公链上，升级是个麻烦问题：硬分叉要求所有人限期换软件，软分叉要费尽心思向后兼容。XRP Ledger 选了另一条路——把任何改变交易处理的改动包装成「修正案」，由验证者用出块用的同一套共识来投票：支持率超过八成且持续两周，就永久生效；没及时升级的节点会安静退出，而不是带着错误数据继续跑。本文按 XRP Ledger 官方文档拆解一条修正案从投票、生效到退场的完整生命周期。
为什么连修 bug 也要走修正案
官方文档写明，修正案是引入新特性和影响交易处理的改动的机制，连改变交易行为的问题修复也要走这条通道。每条修正案有一个由名称派生的唯一标识符，屏幕上看到的短名称只为便于阅读，同一修正案在不同服务器实现里可能被冠以不同名字。验证者依据编译进自己 xrpld 版本的已知修正案清单来决定投票对象，运营者可以随时改票；不做选择时，服务器使用源码定义的默认票，而这个默认值本身可能随版本更迭变化。
flag ledger：每 256 个账本投一次票
修正案状态并非逐块轮询，而是围绕 flag ledger 运转：每第 256 个账本是一个 flag ledger，彼此大约相隔十五分钟。按官方流程，提交共识消息的验证者会在 flag ledger 前一同递交修正案投票；服务器在 flag ledger 上解读受信验证者的票；紧随其后的账本写入 EnableAmendment 伪交易——支持超过八成挂 tfGotMajority 标记，跌回八成及以下挂 tfLostMajority 标记；修正案真正启用时则不再挂标记。从 flag ledger 的第二个账本开始，新规则正式应用于交易。
两周计时器数的是什么
修正案的启用门槛是：超过八成受信验证者的支持持续满两周。期间一旦支持率跌到八成线以下，两周的计时就重新开始；它可以在最终永久启用前反复获得又失去多数。启用是一道单向门：生效后改动永久适用于后续所有账本，想撤销必须再走一条禁用修正案。代码被移除却从未拿到足够支持的修正案，会被网络标记为已否决。
amendment blocked：不升级的节点自己退出
官方把修正案封锁称为一项安全特性。一旦某条修正案生效，缺少其代码的旧版本服务器无法再理解网络的新规则，与其猜测导致误读账本数据，它们进入 amendment blocked 状态：无法判断账本有效性、无法提交或处理交易、不参与共识、也不为未来修正案投票。值得注意的两点：封锁完全由代码决定，与你怎么配置投票无关；把服务器连到启用了不同修正案的并行网络（例如实验修正案较多的 Devnet）同样会触发封锁。解决办法只有一个——升级到新版本。Clio 数据服务器也一样，加载数据时遇到比构建所用 libxrpl 更新的字段类型会被封锁，需要换用兼容的新版 Clio。
生效两年后的退役
已生效修正案的前身代码会留在实现里一段时间，供重建历史账本、核对历史账本结果时使用，但每多一条修正案就多一条旧代码路径，修正案与旧代码的积累是长期负担。社区在 XLS-11d 里定了修正案退休流程：在主网生效满两年后，修正案可被退休；退休使它无条件成为核心协议的一部分，不再被当作修正案跟踪，激活前的代码全部删除。对跑老版本节点的技术读者来说，这意味着旧代码的维护窗口并非无限：一旦相关修正案走完退休流程，那条分支就不再有实现。
用户视角的三件事
普通用户不运行节点，也能从这套机制读出有用的信息。第一，升级压力被摊到平时：XRP Ledger 不会预告某个具体日期全网必须换软件，但长期不升级的钱包后端与节点服务会在某条修正案生效后悄然失联，表现为同步停滞而不是报错弹窗，这正是 amendment blocked 的行为特征。第二，读链上数据时把 EnableAmendment 伪交易当作规则变更的时间标记：它出现在哪本账本，新规则就从其后的账本开始适用，比任何媒体口径都可靠；想追溯某项交易行为何时改变，沿伪交易的账本高度去查即可。第三，投票状态是可以公开核对的，任何观察者都能看到某条修正案当前拿到多少支持、处于计时的哪一周，不需要相信任何单一消息源；对争议中的功能改动，观察投票轨迹本身就是最好的风险评估。还要留意一条容易被误读的细节：默认票由源码定义、可能随版本变化，同一个版本的服务器在运营者不干预时的投票倾向，与运营者的个人立场无关，分析「谁支持这条修正案」时应区分网络默认行为与主动投票。
提醒一句边界：本文按 XRP Ledger 官方文档描述协议机制，八成门槛、两周窗口、256 账本节拍等参数如有调整以官方文档当前值为准；本文不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。