公链升级怎么排期？从 devnet、测试网到预定激活

结论先说

一条公链从”改了代码”到”全网跑新代码”，走的是一条多关卡流水线：核心开发者在开发网（devnet）反复集成与压测，随后按固定次序登陆若干测试网演练，最后约定一个精确到时隙或槽的激活点，客户端在”那一刻”全体切换规则。主网升级是预定时刻的自动切换，不是谁手动按下按钮——节点只需在此之前升级到兼容版本。以 Ethereum 为例，2025 年 12 月 3 日的 Fusaka 升级就在预定 epoch（官方公告给出确切时间与槽号）准时生效，之前它已依次通过 Hoodi、Holesky、Sepolia 三个测试网（核验来源见文末）。理解这条流水线，能回答三个常见疑问：升级要”等待”什么、为什么老客户端会在分叉块上掉线、以及普通用户到底要不要做任何事。

关卡一：devnet 与范围冻结

升级的第一站是若干临时网络：实现各升级分支的客户端一起组网，边写边测，范围（收哪些 EIP）在核心开发者会议（Ethereum 侧为 All Core Devs 系列会议）上逐项确认。范围冻结是关键治理节点：此后新增 EIP 要重走流程，防止”上车战争”拖延档期。这一步的产出是功能完整的候选版本，性能与稳定性远未达到可上主网的标准（测试网定位见测试网是什么？为什么公链需要它）。

公链升级怎么排期？从 devnet、测试网到预定激活机制示意

关卡二：测试网次序演练

候选版本随后按既定顺序登陆公共测试网。Ethereum 近年常用三网串行：先把升级发到规模与节点构成各异的测试链，暴露配置错误、同步行为与边界 bug——2025 年初 Pectra 在 Holesky 因验证者存款配置失误导致最终性停滞的事故，正是这类演练价值的注脚，也推动了后续升级引入分叉配置核验类工具。测试网之间通常间隔数周；一个测试网出问题，整个主网日期顺延。这是”升级日期一再微调”的机制原因：日期跟着演练状态走，不是行政排期。

关卡三：预定激活与版本赛跑

主网激活采用”预定分叉”（air-gapped fork 思路）：协议内写死激活的 epoch/槽号，所有兼容客户端在本地时钟到达该点时自动切换到新规则，无需任何人广播开关（分叉与软硬关系见硬分叉是什么？与软分叉、升级有何区别）。这造成一场版本赛跑：节点运营者必须在激活点前完成软件升级，否则分叉块一到，旧客户端因验证规则不同而与新 peers 断连，孤悬在无人跟随的旧规则上。官方公告因此总是附一份带版本号的客户端兼容清单（Solana 生态的对应核验逻辑见Solana客户端升级要看什么？）。若升级前发现严重缺陷，社区可临时延期或回滚测试网再测——延期代价是信誉与档期，所以决策极其保守。

关卡四：升级之后

激活不等于结束。Ethereum 的 Fusaka 展示了一个新模式：主激活之后还有配置分叉补票——Blob 参数专项分叉（BPO）分两次上调 blob 吞吐目标与上限，各自有独立 epoch 时刻（详见本栏目 BPO 专题）。升级后的监控窗口同样重要：官方通常会说明升级未引发重大网络异常的时间点，供运维者对照。给普通用户的标准答案也写在官方 FAQ 里：只要不使用自己跑节点这类场景，交易所与钱包用户一般什么都不用做，除非服务商另行通知。

怎么核验一次升级的状态

四步清单：一看官方博客升级公告（激活 epoch/槽与日期、兼容版本清单）；二看核心开发者会议纪要是范围是否变更或延期；三看测试网生效记录与事故报告；四看自己依赖的节点/钱包服务商的适配公告。对Solana类链，还要多一层：特性经 SIMD 流程后以 feature gate 形式由集群逐步激活，“代码已发布”与”链上已激活”是两个状态（流程见Solana 升级怎么走到主网？SIMD 流程与特性门）。凡是只报”将于下周升级”却给不出测试网记录与版本清单的消息，先打问号。