以太坊的升级公告里经常出现「本次升级包含 EIP-A、B、C」这样的句子，但很少有人问：这个「包含」是由谁、在哪里、用什么文件定义的？答案是 Meta 类 EIP：一类不提出任何新技术、专门负责给硬分叉装箱登记的元提案。EIP-1013《Hardfork Meta: Constantinople》就是升级史元文档的标本，作者 Nick Savers，2018 年 4 月 20 日创建，状态 Final，登记的正是 2019 年初那趟差点把网络掀翻的君士坦丁堡列车。
先看这份清单的骨架。规格部分只有一张表：代号 Constantinople，别名 Metropolis 第二部分；主网激活条件为区块号达到 7,280,000，测试网分别给了 Ropsten 的 4,230,000、Kovan 的 9,200,000 与 Rinkeby 的 3,660,663；收录五件行李——EIP-145 为 EVM 带来 SHL、SHR、SAR 三条原生移位指令，EIP-1014 引入按哈希承诺派生合约地址的 CREATE2，EIP-1052 加入读取账户代码哈希的 EXTCODEHASH，EIP-1234 把难度炸弹向后推迟并调整出块奖励，EIP-1283 把 SSTORE 的 gas 计量改为净计法。文末 References 指向当年的 All Core Dev 会议议题页与进度 wiki，再挂上官方博客公告链接——一份合格的装箱单，每一项都能回查到出处。读表头时注意元提案的语义：EIP 文件里 Meta 类提案的 Requires 字段登记的是装箱关系——EIP-1013 的 requires 列着 145、609、1014、1052、1234、1283，其中五个是本次收录的行李，609 是上一站拜占庭的元提案，表示升级路线前后相继，并不意味着这五件行李彼此存在技术依赖。
逐项看一眼行李成色。EIP-145 的动机朴素得可爱：EVM 长期以来没有位移指令，编译器想做一次移位只能拿乘除法凑，原文测算用算术模拟 SHL 与 SHR 各要花 35 gas，而新指令定价 3 gas——这是给 Solidity 位运算、打包多个小整数进一个字这类日常操作直接打折。EIP-1052 解决「我想确认这个地址上的代码是不是我认识的那份，但不想把整段代码抄进来看」的问题：EXTCODEHASH 返回账户代码的 keccak256，合约可以拿它与白名单哈希比对；在它之前只能用最贵的 EXTCODECOPY 全量拷贝。EIP-1014 的 CREATE2 允许把合约地址由发送者、salt、初始化代码哈希三者承诺出来，先算地址后部署、链下预派生、工厂合约一次开一批——今天去中心化交易所的每一条自动做市商创建交易、每一张元铸（metamorphic）合约彩票，都踩在这条操作码上。EIP-1234 是升级里的例行公事加一笔财政：继续推迟难度炸弹为向 PoS 迁移争取时间，同时把每块出块奖励从 3 个以太下调到 2 个以太，用发行率给矿工补偿。EIP-1283 把 SSTORE 从「按写入次数粗计」改为「按存储槽新旧值净差计量」，反复写同一槽不再次次全额收费，是编译器与合约作者期待多年的公平账本。
然后就是那段著名的翻车史：正是清单里看起来最无害的 EIP-1283，在链高逼近 7,280,000 激活线时被审计发现会让重入防护的经典写法失效——净计量让「同一笔交易里反复进出同一合约」的 gas 记账出现可被利用的偏差。社区随即紧急停车：2019 年 2 月 22 日公告推迟主网激活，把不含 EIP-1283 的四件行李重新打包，为这次紧急修正立了名为圣彼得堡的升级（后来以 EIP-1716 登记元提案），2019 年 2 月 28 日主网在 7,280,000 高度激活了这一修正后的组合。今天回读 EIP-1013，它的状态依然是 Final——元提案登记的是「当初计划装什么」，而历史用另一份文档（EIP-1716 圣彼得堡）记录了「实际发走了什么」。这个细节恰好展示了 EIP 流程的分层诚实：清单是清单，发货单是发货单，两份都要可查。
元提案体裁本身也值得说一句。它承自比特币 BIP 里的 Hardfork Meta 传统（BIP-64 一系），以太坊的第一份是登记拜占庭的 EIP-609，此后伊斯坦布尔、柏林、伦敦各有装箱单，直到近年的 Dencun 元提案把「升级等于哪些 EIP 的并集」写成可机读的稳定引用。没有这类文档，「以太坊现在跑的是哪套规则」就只能靠会议记录考古；有了它，任何实现者对照一张表就能自证合规。这是协议工程里最不性感却最不可或缺的文档类型。
常见误区三条。第一，把元提案当成规格：EIP-1013 自己不改变任何共识参数，参数全在五个被收录的 EIP 里。第二，以为清单一旦 Final 就代表历史结局：Final 只说明文档定稿，EIP-1283 的遭遇证明升级内容与激活结果可以分道扬镳，查证网络实际行为永远以链上激活高度和后续元提案为准。第三，把别名 Metropolis part 2 读成独立升级：大都会（Metropolis）是分阶段路线图的名字，拜占庭是第一部分，君士坦丁堡是第二部分，两份元提案构成同一条路线的两站。
快速问答。问：怎么查一次升级到底包含哪些 EIP？答：先找对应的 Hardfork Meta 提案，再看有没有后续修正（如圣彼得堡对君士坦丁堡的抽件），最后以客户端发布说明的激活块为准。问：为什么要单独设 Meta 类型？答：升级是「规则集合的切换」，不是单个提案的属性；没有登记表，节点实现、测试网协调、区块浏览器标注就各说各话。问：EIP-1013 表头的 609 是什么？答：那是上一站拜占庭的元提案，被列进 Requires 表示元文档谱系上的前后相继，不代表君士坦丁堡依赖拜占庭的某项技术细节。
风险提示：本文为升级史与协议机制科普，不构成投资建议；涉及奖励与发行的讨论均以协议文档原文为准，历史事件的日期与高度可再经区块浏览器独立核验。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。