多数 Cosmos 系链升级靠治理提案预定一个停机高度，到点全体节点换二进制。Celestia 把这条路改写了：自 v3 起，网络升级不再硬编码高度，验证者在协议内举手报版本，五分之六的投票权指向同一版本后再等一周，新版本自动激活。规则由 CIP-10 定义，本文按官方运维文档和架构决策记录梳理这套信令升级的来龙去脉。
从停机高度到协议内信令
运维文档记载了一个明确的分界点：2024 年 9 月的 Lemongrass 升级（v2）仍用预编程高度，在约定的区块号激活；此后所有升级（v3 起）改用协议内信令。信令流程是：验证者提交消息表明自己已准备好运行某个新版本并偏好它；当五分之六的投票权对同一版本发出信号时，信令达到法定数；从这一刻起再等一周，升级自动生效，官方文档没有写死的区块号需要你提前猜。
为什么是”滚动”而不是”停机”
架构文档把差异说得很直白：滚动升级指节点提前装好新二进制，到某个高度自动切换共识逻辑；停机升级要求全体在同一个高度 halt、集体换软件。Celestia 的选择依赖一个前提——它的状态机是版本化的，区块头里带的应用版本号决定这笔交易按哪套逻辑验证与执行，新版二进制因此能先以旧版本身份继续跑，随时向前切换；同一份软件还要保留按旧版本重放全部历史的能力，节点才能不猜高度直接跟到链尖。官方 ADR 还把三条硬性需求列为出发点：质押池流动性高、非验证者要能轻易退出，作为多条 Rollup 共同依赖的基础设施停机必须尽量短，以及新软件必须能从头验证整条链历史。
一周窗口在防什么
五分之六门槛和一周延时各自有清晰的角色。门槛保证新版本拿到压倒性投票权背书，避免少数节点劫持升级方向；一周窗口给分布在全球、运维节奏各异的节点运营者留出实际换二进制的时间，也把”社义已定、节点没跟上”的撕裂暴露在最前面，让补救在激活前还有余地。架构文档没有回避失败模式：如果社义达成共识而验证者迟迟不装新版，网络最终只能硬分叉，那意味着换链 ID、换验证者集合，连 IBC 对端链都要走一遍治理来承认变化；反过来，即使升级块本身拿到了超过三分之二投票权的背书，只要有一个节点支持了升级却对随后的区块不出票，网络也可能停滞到足够多节点完成升级为止。信令机制缩短的是协调不确定性，消灭不了拜占庭拖延。
用户侧怎么跟进
对普通持有者，这套机制改变的是”升级预告长什么样”：不再有一个治理提案里写死的区块号，而是一个不断上涨的信令进度条和从满员时刻起算的一周倒计时。官方公告渠道是 Telegram 全网公告频道与 Discord 的主网、测试网频道。想主动核验的读者可以沿着文档给的流程倒着查：共识性变更先由 CIP 提案讨论、打包进定义升级范围的元提案，再由核心团队实现成二进制，先在 Mocha 测试网换版演练，最后才轮到主网——每一步都有公开工件可查，升级不再是某个高度突然出现的版本跳变。另外，文档明确替换二进制不会改写你已有的配置文件，缺失项按新默认值处理，跑节点的人升级后应当自己 diff 一遍配置，别把静默换默认值当成没变化。
链上状态判断则始终可以回到节点与区块浏览器。数据可用性层的升级与否，和你挂在它上面的那条 Rollup 的交易是否继续可用，是两件事，各自查各自的文档。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。