以太坊的升级节奏曾经多年没有章法：重要改进攒够了就发一次，间隔从几个月到一年不等，矿池、交易所、钱包各自按传闻排人力。EIP-1872在2018年3月由Danno Ferrin提出，想把升级变成学期制——每年固定四个窗口，升级声明进驻哪个窗口早早公开。提案最终停在Stagnant，从未激活，但把它当作一份升级治理的说明书来读，信息密度很高。
三档升级，一套日历
提案把网络升级分成三类。路线图类（Roadmap）是深思熟虑的协议改进，历史上Homestead、Byzantium、Constantinople都属于这一档，它们只能排进四个窗口之一：一月、四月、七月、十月里第三个星期所在的那一周。窗口选择刻意在一二季度假期与二三季度假期之间找缝隙，提案原文自己批注：月份和周次只是初稿建议，公开评审时随时可改。优先级类（Priority）是有技术原因必须尽快上、但不构成系统性风险的变更；危急类（Critical）处理系统性风险，随到随发，日历管不着它。配套节奏也写死了：软件要在升级前二到四周就绪，块号要在窗口前四到六周定下——把发布管理的每个环节都钉上时间表。
窗口制的收益与它的敌人
收益侧很好列：生态各方的运维排期可以年为单位提前锁定，交易所升级钱包、矿池换客户端都有确定档期；发布质量的改进可以流水线化，测试网部署、漏洞赏金、文档更新按同一节奏转圈。敌人也很具体。第一，协议改进不配合日历排队——关键缺陷的修复等不到下一个季度；一旦危急类通道被反复使用（当年的重入漏洞与难度炸弹调整都等不了窗口），日历的信用就会塌方。第二，客户端发版有自己的节奏，把共识切换绑进固定周，意味着客户端团队要在别人定的一天交卷。第三，也是提案自己未解决的：窗口用不用、块号何时选，这些调度细节明文排除在范围之外。
为什么停摆不等于失败
Stagnant状态说明共识层从未采纳日历。但把以太坊后来的实际演化摆在它旁边看很有意思：升级依然不按季，却逐渐形成了自己的可预期性——命名升级、测试网时间线、固定的客户端开发者协调会。治理的可预期性并未消失，只是从日历制换成了里程碑制。1872的价值在于把选择点摆到了台面上：协议迭代速度、生态协调成本、紧急响应通道，三者怎么配比是一道明题而非暗账。今天读升级公告时那份对排期的追问，和1872当年的追问是同一个。
一次实际排期与日历的错位
回看1872提出后的岁月，日历制从未跑通，但每份升级公告都在回答1872的问题。以难度炸弹推迟为例：这类提案技术上半小时能写完，排期却每次都成为争论焦点——它天然符合提案分类里的哪一档？若按路线图档排进下一季度，链可能在窗口前就触发炸弹；按危急档随到随发，又显得对日历失信。现实选择是走紧急通道，而这恰恰验证了日历制的软肋：协议安全类变更的时间压力不会迁就发布节奏。再比如带新功能的升级，历史上多次从原定季度滑档，滑的理由从测试网发现漏洞到大客户端发版延迟，都是日历无法预知的变量。把这些事件当作1872的反事实实验来读，会发现它输给的对手不是理念，是协议工程的随机性。
快速问答
问：这提案算失败吗？ 答：作为规则从未生效；作为治理讨论材料仍然被引用，其分类框架后来反复出现在升级流程文件里。 问：现在升级怎么排期？ 答：由客户端团队在协调会上按功能就绪度定，先测试网、再主网时间或高度，公告先行数月。 问：难度炸弹和窗口制冲突吗？ 答：不直接冲突，但炸弹调整历来走紧急通道，恰好演示了危急类对日历的侵蚀。
风险提示：本文描述治理机制史，不构成任何投资建议。升级安排以官方公告为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。