按纪元换行为：MultiversX 的激活纪元如何让协议升级不断网

MultiversX 把协议升级定义为向后兼容的变更，与硬分叉相对。这个定位决定了一整套不常见的时间工程：升级不按区块高度生效，而是按纪元生效；节点先换软件、后换行为；新旧代码在过渡窗口里必须并存。官方针对节点运营者的升级指南把这些机制讲得很完整，其中每一条都是在回答同一个问题——如何在不中断共识的前提下换掉运行中的协议。

三种升级，三种紧迫度

官方把节点版本更新分成三类。第一类要求所有节点升级：涉及带激活纪元的行为变更，不升级的节点将无法与其他节点保持一致视图，导致服务中断。第二类是可选升级，例如只是给 REST 接口加新端点或改进状态树同步时机，处理逻辑不受影响，升不升都不掉线。第三类只有验证者必须升级，改动只触发验证者路径（比如验证者评分规则、交易选择改进），观察者节点可以不动。判断升级紧迫度的第一步是认清手里这份发布属于哪类，指南建议订阅官方配置仓库的版本发布通知、加入验证者频道，并把节点软件版本监控起来——浏览器会标记落后的版本。

激活纪元：行为切换的开关

所谓激活纪元机制，是让一个新二进制同时内置新旧两套行为，旧行为一直服务到指定纪元，纪元开始后的第一个块起切换到新行为。官方文档给过一个典型时间线：主网处于某纪元时发布新二进制，其中包含将在若干纪元后激活的新元数据；所有运营者先完成升级；到激活纪元开始，新元数据才被全网认可，未升级的节点则开始产出与多数派不一致的结果、被链甩下。这个设计的效果是：在激活之前，升级与未升级的节点保持完全兼容、共识照常进行——官方同时坦率说明这并非百分之百有保证，因为与第三方生成的历史交易并行回放时存在不可预见的相互作用。

为什么不按区块高度生效

其他协议常以固定区块高度作为升级开关，MultiversX 明确不这样做。原因是纪元首块的高度无法提前预知：出块回滚会让高度漂移。但纪元长度用轮数固定，按官方文档记载，主网每个纪元一万四千四百轮、每轮六秒，合成约二十四小时，因此功能生效的时刻可以计算，生效时所在的高度不能。纪元切换也可能因纪元起始元块的延迟而后移几轮。想验证这一点，网络配置与分片状态接口会同时给出当前区块 nonce、纪元与轮号，三者连起来就能把自己所在位置换算成墙钟时间。

回放历史时的双行为账本

激活纪元机制还有一层容易被忽略的价值：向后兼容的回放。同一个二进制从头重放历史链时，对激活纪元之前的交易按旧规则处理——比如某笔在多年前纪元尝试设置新元数据的交易会被判为无效元数据——对激活纪元之后的交易按新规则处理。同一份代码在两个纪元段内给出两种确定性结果，这正是按纪元而非按代码版本管理协议的直接推论。评估一次升级风险时，值得先问三件事：它属于哪一类升级、激活纪元定在哪个边界、未升级节点会在哪个块上开始掉队。

风险提示：本文为机制与运维文档解读，不构成投资建议；纪元参数与升级流程以官方文档及公告为准。