一份提案怎么进升级：EIP-7723 给网络升级列出的五种收录状态

读以太坊的新闻时，你大概见过这样的句子：「某提案已被列入下一个升级」，也可能见过「被暂缓考虑」。问题在于，早期并没有一套统一的词表来支撑这些说法——同一份提案，A 客户端团队说「在考虑」，B 团队的博客说「已排期」，读者无从对齐。EIP-7723 就是来补这张词表的：它是一份流程类提案，2024 年 6 月 12 日创建，目前处于 Last Call（最后公告）阶段，为「提案与单次升级的关系」定义了五个正式阶段。

五个阶段分别说什么

按提案文本，五种收录状态依次是：Proposed for Inclusion（被提议收录）、Considered for Inclusion(被考虑收录)、Scheduled for Inclusion（被排期收录）、Declined for Inclusion（本次被拒绝收录）、Included（已随升级激活）。链条的直觉是漏斗：任何人可以给一份提案挂上「提议收录」；核心开发者会议讨论后进入「考虑收录」；一旦某次升级的规格冻结并公告，被选中的提案转「排期收录」；升级成功上线，转「已收录」；而每一轮没被选上的，挂「本次拒绝」，不是死刑——文本明确写了，上一轮被拒不影响下一轮重新被提议或考虑。

关键设计：状态挂在「升级」上，不挂在「提案」上

这份词表最重要的规则是作用域。EIP-7723 强调所有收录阶段都以「单次网络升级」为单位：一份提案对 Pectra 可以是 Declined，对 Glamsterdam 可以同时是 Proposed——两个标签并存不矛盾。它还指出，一份提案不可能同时在两个升级里 Included；被同步激活要求的 Core 类提案必须走完整流程，而非 Core 类（比如接口标准）也可以被贴这些阶段标签，只用于优先级沟通，不产生同样的强制含义。换句话说，它把「这份提案活着吗」和「这份提案这次进不进」彻底拆成了两个独立问题。

和提案自身状态标签怎么区分

每份 EIP 文件头部本来就有一套生命周期字段：Draft（草稿）、Review、Last Call、Final（定稿），还有 Stagnant（停滞）、Withdrawn（撤回）等。两套标签回答的问题不同。EIP-7723 自身就是活例子：它自己的文件状态是 Last Call——意思是这份流程文档在走定稿前的最后公示；而它定义的 Scheduled for Inclusion 说的是「被某次升级排期」。看到「某提案 Final 了」别自动翻译成「快上线了」：Final 只说明文本定稿，收录与否要看那五个升级阶段。媒体标题里最常见的混淆，恰恰是把这两套词表当一套用。

一套词表改变了什么

规则本身不改变任何技术决策：谁进谁不进，仍然由客户端团队在核心开发者协调中商定。词表改变的是沟通的代价。有了这五个词，升级备忘录、会议记录和客户端发布说明可以引用同一个阶段名；「暂缓」不再需要读者猜是「这轮没戏」还是「永远没戏」——按 7723 的写法，答案被强制拆成「本轮 Declined、未来待定」两个字段。对跟踪升级的普通读者，实操建议只有一条：读任何升级新闻时，先问这份提案对当前这一轮升级挂的是哪个阶段，再决定要不要为它准备客户端升级。

一笔对照账

拿一份假想提案走一遍词表就清楚粒度有多细：某份存储类 EIP 对上一次升级挂过 Declined，对再下一轮挂 Considered，第三次才被排进 Scheduled——三个阶段分别登记在各自的升级记录里，任何一处都不与另外两处冲突。真实世界不乏近似样本：升级元提案文件本身就按这套词表分节列名单，比如 Glamsterdam 的元提案 Specification 段直接引用 EIP-7723 的阶段定义来标注自家排期。另一个常被忽略的细节是 Included 的唯一性：一份提案不可能同时 Included 进两次升级，这条约束让「它进了哪个升级」成为可以链外证伪的问题——去对应升级的规格文件里找名字即可。