档案学里有一种文献叫「回溯编制」：文件在运转中先散着放，多年后专门立项把它们编目。EIP-7568 就是以太坊标准体系的一次回溯编制。标题直译「硬分叉元提案补编——从柏林到 Shapella」，Tim Beiko 起草，2023 年 12 月 1 日创建，状态 Final、类型 Meta。它的正文几乎全是一张指路表：把缪尔冰川之后那些没有元提案的网络升级按激活顺序排好，执行层变更标 EL、共识层变更标 CL，每一个链到真正定义变更的规范文件。
一段被中断的传统
要理解这份补编的必要性，得先知道元提案曾经是以太坊升级的标准包装。从 frontier 时代到 2019 年，每次硬分叉都有一份 Meta 类型 EIP 负责写清代号、激活高度、收录清单——Homestead 的 EIP-606、拜占庭的 EIP-100 系列、君士坦丁堡的 EIP-1013、伊斯坦布尔的 EIP-1679 都是这个传统的产物。传统在缪尔冰川（EIP-2387，那份只装了一件提案的元文件）之后戛然而止：动机部分说得委婉——「元提案被弃用，改用以其他方式追踪升级所含变更」。实际变化是升级节奏与流程重排：Berlin 的内容改由 execution-specs 仓库的 berlin.md 页面定义，之后每次升级的「装箱单」都成了升级仓库的专属文档。EIP 仓库这边，档案就此断档。
断档的真实代价
升级仓库的记录对当期开发者足够，对长期检索者却留下三个坑。第一，跨仓库引用会腐烂：Berlin 最初也被记在 EIP-2070 名下，文件迁移后旧指针含义漂移，EIP-7568 正文里保留着「最初规定于 EIP-2070、随后移至执行规范仓库」这类注释，正是坑存在的化石证据。第二，双链时代的升级不再是单个「硬分叉」：合并由执行层 Paris 与共识层 Bellatrix 两名拼成，Shapella 是 Shanghai 与 Capella 的合字，没有统一登记处，普通人很难回答「合并到底改了哪几份 EIP」。第三，共识层升级（Altair、Phase 0 启动）从来不在 EIP 流程管辖内，只能靠引用外部锚点——比如信标链启动直接指向 consensus-specs 仓库 v1.0.0 发布的某个具体提交哈希。补编把这三类指针收进同一个页面，等于给断档期重建了索引。
钟摆为什么摆回来
动机部分第二段的措辞值得逐字读：多年使用元提案记录升级后，社区近期就在重新使用它们达成一致。从这份 2023 年 12 月的补编往前数，新的元提案重新出现（Glamsterdam 有 EIP-7773，后续升级亦沿用），往后数，它收录的清单成了回答「那几年发生了什么」的标准入口。流程工具的废弃与复归很少是认错，更多是约束条件变了：2019 年弃用元提案，因为多线并行的升级节奏让单一装箱单力不从心；重新启用，因为升级仓库的规范文档成熟后，元提案可以退化为纯指针页而不必承载规格细节——EIP-7568 自己就是这种退化的示范：全文没有任何技术变更，价值全在结构。
快速问答
问：EIP-7568 收录的升级里哪些动过共识规则？ 答：EL 侧的柏林伦敦含协议变更，CL 侧的 Phase 0 与 Altair 是信标链自身演进；具体条目它只给指针不给清单，需顺链查询。
问：为什么箭头冰川、灰色冰川这种「只改延迟参数」的也要收录？ 答：登记册的标准是「发生过即入册」，完整性优先于变更大小，这恰是档案与教程的区别。
问：怎么查一次没被收录的更早升级？ 答：往前接旧传统，每次升级的元提案仍在 EIP 仓库，两代文件首尾相衔。
一条对照线
把 EIP-7568 与比特币的 BIP-123 附表现象对照会很有趣：一个靠事后补录修复断档，一个靠快照表内建过时风险——共同教训是，登记类文档的保质期取决于更新流程而不取决于初始质量，指针比摘抄耐存放。
常见误区
一是把补编当规范读，它不定义任何行为，只指路；二是以为元提案复归意味着回到 2019 年前的流程，今天的元提案与规格文档是两层皮；三是忽略它标注的 EL/CL 分栏，把两条链的升级史混成一条时间线。
风险提示：本文解释标准流程文档，不构成投资建议；各升级的准确内容以链上激活参数与当期规范为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。