提起以太坊升级，人们记住的是名字：伦敦、巴黎、坎昆。名字背后有一套相对枯燥的制度，出处是Alex Beregszaszi在2017年3月提交的EIP-233，标题就叫“硬分叉的正式流程”，类型为元提案，当前状态Stagnant。它想解决的事在提案开头一句话点破：当时关于硬分叉的讨论散落在各种论坛，有时以临时拼凑的方式进行。这篇提案把升级拆成文书和节点，让任何一次升级都能被外部人从头到尾追踪。
元提案：一份升级的户口本
EIP-233规定，一旦计划新的硬分叉，就应创建并合并一份元提案作为Draft。这份文书必须包含四样东西：升级代号、定了就写的激活区块号、时间表章节、拟收录EIP章节；它的Requires字段指向上一次升级的元提案。于是整个以太坊协议史被串成一条链：每份升级档案都能顺着引用回溯到前一次，从创世一路数到今天。元提案本身不写任何技术细节，它只做登记——哪些EIP在候选、哪些被接受、哪些被拒绝、哪些已经随测试网演练过，全部在同一个文件里分节陈列。后来的伊斯坦布尔元提案就是它附带的模板，近年历次升级档案也都延续了这套结构。
时间线上的四个节点
提案给升级时间表划了一个基本骨架：接受提案的硬性截止、主要客户端实现软性截止、测试网升级的预计日期、主网升级的预计日期。四个节点各司其职。硬截止之后不再进新车，软截止考的是客户端团队跟不跟得上，测试网日期用来把接受的提案拉出来演练一遍，主网日期最后落成激活区块号。每个节点都是公开的，社区不需要凭传闻猜升级走到哪一步——看元提案的时间表章节和EIP在几个章节之间的移动就够了。
一份EIP的三种去向
按EIP-233的设计，任何人为某次升级提交核心EIP，就给对应的元提案提合并请求，EIP先进入候选章节，并至少留一个联系人负责答辩。之后由All Core Devs开发者会议讨论推动：被接受进本次升级的，移入接受章节，若在时间表日期前拿到主要客户端实现且没有安全问题，就排进日程；被拒绝的，移入拒绝章节写明去向；接受章节里的EIP在测试网成功上线后，再移入收录章节。元提案自身的状态也随进程变化——引用的EIP全部定稿时它转为Accepted，升级真正激活后转Final。整套设计里没有谁有一锤定音的按钮，只有状态迁移和公开记录。
流程管不住的部分
值得留意的是EIP-233自己的状态：Stagnant。流程文本在2017年写成后基本没再修订，而实践早就长出了它没覆盖的枝杈——升级从“按区块号激活”改成了按时间协调，客户端数量从多家并存走到现在的多实现验证，测试网也换了一茬又一茬。但这不影响它作为底版的地位：今天升级档案的章节划分、状态词表、Requires串联，仍和这份文书的骨架一致。流程类提案的命运常常如此——写成Final的是规则，留在草稿上却被所有人照着做，也是一种生效。
一场升级的档案怎么读
给想跟踪升级的读者一条实用路线。第一步找到当次元提案，读它的代号和时间表章节，确认四个节点各自的状态；第二步扫接受章节，每个EIP点进去看它自己的状态与实现清单，接受进升级不等于已随主网上线，中间还隔着测试网演练一步；第三步拒绝章节同样值得读，那里记录了这一轮谁被请下车、理由写在讨论链接里；最后看元提案状态：还在Draft说明名单未冻结，转Accepted即定妆，转Final才代表升级真的激活。四步走完，你对一次升级的了解就超过了绝大多数凭热度转述的信息。
快速问答
问：元提案算不算一次投票表决？ 答：不算。它是登记文书，决定发生在开发者会议的讨论里，元提案只负责把讨论结果记录成章节和状态。 问：为什么现在有些升级档案的格式和这个模板不太一样？ 答：实践一直在微调，EIP-233记录的是2017年版的流程底版，后来的变化没有回写进这篇文书，读它要看清哪些仍是惯例、哪些已被替换。 问：错过硬截止的EIP还有救吗？ 答：只能等下一轮。截止机制的意义就是给升级画一个冻结线，拖延整班车从来不是默认选项。
风险提示：本文描述协议流程，不构成任何投资建议，也不涉及任何资产的买卖时机判断。流程细节以EIP原文与官方开发者会议记录为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。