纪元推进失败之后：Sui 链的降级运行与恢复条件

公链对缺陷最常见的回答是停：执行结果无法保证一致时，宁可不出块。Sui 在纪元边界提供了另一种回答——如果纪元收尾的系统调用失败且没有恢复手段，链体可以转入一种被官方字段标记为 safe_mode 的降级状态继续运行。这不是营销话术里的容灾，而是框架里一个可以被任何节点读到的布尔字段。本文围绕这个字段拆三件事：它什么时候被置位、降级时链还剩下什么能力、以及怎么证明它退出了降级。

字段出自哪里

Sui 框架的 sui_system::sui_system_state_inner 模块保存系统状态，官方模块参考里 safe_mode: bool 的注释写明：当系统因为不可恢复的缺陷运行在降级模式时该值为真；它在 advance_epoch 执行失败、转而去执行 advance_epoch_safe_mode 时被置位，一旦 advance_epoch 能够成功执行就可以被重置。也就是说，降级模式的判据不靠人工投票或链下声明，而是内嵌在纪元切换这条代码路径上：正常收尾成功就是 False，收尾失败走了兜底路径就是 True。这个设计有两个容易被忽略的性质。其一，它是确定性状态：同一个纪元边界上，所有走到同一执行结果的节点必然得到同一个布尔值，不需要任何 gossip 来商量要不要降级，也就消除了降级本身成为分叉源的可能。其二，它是可查询状态：任何人只要连上一个节点或直接读链上系统状态对象，就能核对当前处于哪条路径，不必依赖某个运营商的口头保证。每个验证者都在自己的系统状态里独立记录同一个字段，读取时天然一致。

为什么降级而不是停机

纪元边界是协议里最容易埋雷的位置：验证者集合更新、奖励分配、协议版本推进、随机信标的分布式密钥生成（DKG）等一次性工作都集中在 advance_epoch 里。任何一处确定性缺陷都会让所有诚实节点在同一处摔倒，链就此卡死。兜底路径的设计动机在协议版本注释里也有痕迹：Sui 协议版本 2 的变更条目就包含在 safe mode 下推进 epoch_start_time 的处理，说明团队从一开始就考虑了降级期间时间类字段仍需前进的问题。保留出块、把纪元收尾工作推迟到修复后再补，是比全网停摆更温和的失效模式——代价是部分依赖纪元收尾的子系统在此期间拿不到新数据。

运维侧怎么盯

官方验证者告警参考把 Safe Mode during Reconfiguration 列为最高优先级告警之一，触发表达式基于 is_safe_mode 指标：按网络标签过滤，值大于 0.5 或者指标缺失都会命中，持续 5 分钟即告警。指标缺失也被视为可疑信号，这是监控手册里少见的谨慎写法——覆盖的是节点压根没能上报状态的故障面。对非验证者的观察者，替代路径是直接查询链上系统状态里的这个布尔字段，两种口径应当互相印证。

边界与常见误读

第一，降级模式不等于链被攻击，它的定义性诱因是执行路径上的缺陷；把它读成安全事件是对字段的误用。第二，降级期间并非一切如常：依赖纪元收尾产物的功能（例如新一期验证者集合与随机信标轮换）会滞后，具体的受损面应以当期协议版本的实现为准。第三，退出条件写在字段注释里——某次 advance_epoch 成功执行后该值即可复位，因此判断链恢复正常的最小证据是这个字段回到 False，而不是网络群里有人说恢复了。第四，框架文档描述的是机制，某次具体事件的时间线、根因与修复版本属于事后事实，应以项目方当期的事故报告为准，本文不做推测。链级降级机制的价值在于缩小停摆窗口，但任何降级模式下的交易确认都应比平时更保守地核对，这属于使用公链的基础纪律，与任何投资建议无关。