尧图网站建设 
EIP-7723 网络升级纳入阶段详解EIPs 仓库中 Core EIP 从提案到激活的治理规范【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7723Network Upgrade Inclusion Stages是一份 Meta 类 EIP它形式化了以太坊网络升级规划过程中 EIP 所经历的各阶段Proposed for Inclusion提议纳入、Considered for Inclusion考虑纳入、Scheduled for Inclusion排期纳入、Declined for Inclusion拒绝纳入与Included已纳入。本文以该文档为骨架结合当前 EIPs 仓库中真实的升级 Meta EIP如 EIP-7773、EIP-8081与 EIP-1 流程说明帮助你理解以太坊核心开发者如何决定哪些 EIP 进入下一次硬分叉以及提案作者、实现团队与测试团队在各阶段的职责与操作方式。为什么需要形式化升级纳入阶段以太坊的治理长期遵循rough consensus粗略共识模式。按照 EIP-1 的描述AllCoreDevs 电话会议通常会对应该实现哪些 EIP形成粗略共识这种共识建立在两个假设之上EIP 没有争议到足以引发网络分裂并且技术上健全。然而随着网络升级规模越来越大如 Dencun、Pectra一个 EIP 当前处于什么状态缺乏统一的、可被社区与客户端团队共同引用的语言。EIP-7723 的动机正是填补这一空白为网络升级规划过程中的 EIP 定义一套标准阶段并提供何时、如何将 EIP 从一个阶段移动到下一个阶段的上下文与准则。形式化这些阶段能让协议维护者与更广泛的以太坊社区获得更好的可读性legibility。该文档属于Meta类型 EIP状态为Last Call最后调用截止日期 2025-04-01作者包括 Tim Beiko、Alex Stokes 等长期负责网络升级协调的核心开发者。五个阶段的总体视图EIP-7723 定义了以下五个纳入阶段它们是本文的核心阶段缩写含义Proposed for InclusionPFI已有人提议将该 EIP 纳入某次网络升级Considered for InclusionCFI客户端开发者已审阅打算尝试在 devnet 中实现并测试Scheduled for InclusionSFI核心开发者确认有强烈意愿纳入且规范与实现已足够成熟Declined for InclusionDFI客户端团队反对将该 EIP 纳入本次升级IncludedIncluded升级已激活该 EIP 已随升级生效通用规则与适用范围每个阶段都针对单次网络升级所有纳入阶段都只适用于一次具体的网络升级。EIP 必须为每次网络升级分别Proposed、Considered、Declined或Scheduled一个 EIP 不能同时Included于两次网络升级一个 EIP 在上一次升级中被Declined for Inclusion并不妨碍它在未来的任何升级中被重新Proposed、Considered、Declined或Scheduled提案不会自动顺延如果某 EIP 未被纳入其首次提案对应的升级它不会自动带入下一次升级必须重新走流程。Core EIP 是主体non-Core EIP 可选用这些阶段主要针对Standards Track - Core EIP定义——这类 EIP 必须由网络上所有节点同步激活。为了便于优先级排序和沟通非 Core EIP 也可以被赋予这些阶段各阶段定义中已注明对非 Core EIP 的差异与含义。文档中的关键词约定规范部分按 RFC 2119 与 RFC 8174 解释关键词MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、OPTIONAL。也就是说MUST是硬性要求SHOULD是推荐实践MAY是允许选项——下文将按此语义区分各阶段的责任强度。Upgrade Meta EIP承载阶段列表的载体任何人均MAY起草一份 Meta EIP 来列出某次网络升级的 EIP。这类升级 Meta EIP 的规范Specification部分SHOULD包含四个类别Proposed for InclusionDeclined for InclusionConsidered for InclusionScheduled for Inclusion即使某个类别当前还是TBD待定也SHOULD在初始草稿中包含该类别以保证清晰性。随状态流转的列表收缩规则升级 Meta EIP 自身会经历 EIP-1 定义的 Draft → Review → Last Call → Final 流程其列表随之收缩升级 Meta EIP 移入Review时Proposed for Inclusion与Declined for Inclusion列表SHOULD被移除升级 Meta EIP 移入Last Call时Considered for Inclusion列表SHOULD被移除只保留Scheduled for Inclusion列表升级 Meta EIP 移入Final之前Scheduled for Inclusion阶段MUST改名为Included且只能包含随升级实际激活的 EIP。仓库中的实例当前仓库中的 EIP-7773Hardfork Meta - Glamsterdam状态 Review与 EIP-8081Hardfork Meta - Hegotá状态 Draft正是这一规范的直接应用两者都在规范部分声明各阶段定义见 EIP-7723并按EIPs Scheduled for Inclusion、Considered for Inclusion、Declined for Inclusion、Proposed for Inclusion分节列出 EIP。例如EIP-7773Review 状态已进入列表收缩的中间态只保留了Scheduled for Inclusion列表与Other EIPsNetworking EIP、Informational EIP分组并附有激活信息表Sepolia / Holešky / Mainnet 的激活 epoch 与时间戳留待客户端团队决定后填充EIP-8081Draft 状态则同时包含Scheduled for Inclusion、Considered for Inclusion、Declined for Inclusion暂为空与庞大的Proposed for Inclusion列表——这正是草稿阶段应保留全部四个类别的体现作为对照EIP-8007Glamsterdam Gas Repricings Meta EIP是一份纯信息性的目录型 Meta EIP自述不主动参与治理流程仅用Considered for Inclusion与Declined for Inclusion两类表格组织 gas 重定价相关提案。Upgrade Devnets纳入能力的物理约束在准备网络升级时客户端开发者通常先在**临时测试网络upgrade devnet**上实现 EIP以验证客户端互操作性之后再部署到长期测试网络testnet上。升级 devnet 遵循upgradeName-devnet-version的命名约定例如pectra-devnet-0Pectra 网络升级的第一个升级 devnetdencun-devnet-1Dencun 升级的第二个升级 devnet。由于客户端开发者能否将 EIP 纳入升级受限于这些 EIP 能否在升级 devnet 中被实现并测试EIP-7723 特别建议将Considered for Inclusion与Scheduled for Inclusion状态与 EIP 在升级 devnet 中的实现状态对齐——这是整个阶段体系与工程现实衔接的关键设计。各阶段详解1. Proposed for InclusionPFI提议纳入如何进入要提议某个 EIP 纳入升级提案人MUST打开一个 pull request将其添加到升级 Meta EIP 的Proposed for Inclusion部分。升级 Meta EIP 的作者SHOULD及时合并合理的 PR。责任约定EIP 的提案人SHOULD在整个升级周期内担任该 EIP 的主要联系人或SHOULD指定他人担任此角色在此阶段实现团队SHOULD审阅该 EIP对 Core EIP应在纳入本次升级的背景下审阅对非 Core EIP应在支持 Core EIP、支撑升级激活的背景下审阅。关键点提案必须针对每次网络升级单独发起不会自动顺延到下一次升级。2. Considered for InclusionCFI考虑纳入如何进入客户端开发者审阅了已Proposed for Inclusion的 EIP 后MAY将其移动到Considered for Inclusion阶段。一旦客户端团队决定移动升级 Meta EIPSHOULD被更新以反映这一变化。含义与配套动作Considered for Inclusion表示客户端开发者打算尝试将该 EIP 纳入 devnetAll Core Devs ExecutionACDE与 ConsensusACDC电话会议的协调人应与测试团队合作为 CFI EIP 提出优先级排序交由客户端开发者审阅并将此优先级反映到 Meta EIP 中该优先级用于决定哪些 EIP 应进入后续 devnet允许一定灵活性该阶段类似于其他开源项目中的 concept ACK概念认可不足以导致主网部署只有在满足主网部署全部要求的前提下才MAY被纳入网络升级处于 CFI 的非 Core EIPSHOULD在升级激活前获得支持如果客户端团队反对将该 EIP 纳入升级MAY将其从Considered for Inclusion移动到Declined for Inclusion。execution-specs 配套要求处于该阶段的 EIPSHOULD具有提交为开放 PR 的 Python 实现及配套测试位于以太坊执行层规范仓库 execution-specs 中EIP 作者被鼓励联系该仓库维护者获取实现协助。客户端开发者MAY允许 EIP 在缺少实现的情况下进入 CFI但需意识到实现缺失可能导致测试周期延迟。对该阶段 EIP 的任何更新SHOULD伴随 execution-specs 中实现与测试的相应更新若客户端开发者认为必要。3. Declined for InclusionDFI拒绝纳入如何进入在升级规划过程中的任何时刻如果客户端团队反对将该 EIP 纳入升级客户端开发者MAY将 EIP 从任何其他阶段移动到Declined for Inclusion。一旦决定做出升级 Meta EIPSHOULD被更新。含义Declined for Inclusion表示客户端开发者希望将该 EIP排除出当前网络升级并停止讨论其在本次升级中的纳入或实现状态在某次升级中被 DFI 的 EIPMAY在后续升级中重新被Proposed for Inclusion在特殊情况下客户端开发者MAY选择将 EIP 从Declined for Inclusion移回Considered for Inclusion或Scheduled for Inclusion。4. Scheduled for InclusionSFI排期纳入如何进入当核心开发者满足以下两个条件时可将 EIP 移动到Scheduled for Inclusion就将 EIP 纳入下一次网络升级达成强烈意愿同意该 EIP 的规范与实现已达到一定成熟度。即 SFI 状态表明除非出现不可预见的问题该 EIP 正处于纳入的正轨上。成熟度稳定性判据——以下标准可用于评估 EIP 是否足够成熟以进入 SFI已被纳入一个表现出稳定性的 devnet例如高参与率、持续 ≥1 周无关键 bugEIP 规范接近定稿无占位值或待定设计决策与其他 CFI EIP 的交互最小或这些交互已在同一 devnet 中测试测试覆盖充分客户端通过共识测试无已知跨客户端分歧。评审与批准流程All Core Devs TestingACDT电话会议可审阅 EIP 以判定 SFI 资格状态变更随后在 ACDE 或 ACDC 电话会议上批准后正式赋予 SFI 状态。配套约束规范不完整或交互未测试的 EIP 应保持 CFI直至条件满足最新的升级 devnet 必须包含所有已Scheduled for Inclusion的 Core EIP如情况变化EIPMAY从 SFI 移回 DFI客户端团队同意移除若客户端团队仍赞成纳入但无法承诺进入下一个升级 devnetMAY从 SFI 移回 CFI。execution-specs 强制要求比 CFI 更严格进入 SFI 的 EIPMUST具备提交为开放 PR 或已合并到仓库devnets/upgradeName/version分支的 Python 实现及配套测试。客户端开发者MAY允许 EIP 在缺少 execution-specs 实现的情况下进入 SFI但测试严格强制strictly mandatory。对该阶段 EIP 的任何更新MUST伴随 execution-specs 中实现与测试的相应更新若客户端开发者认为必要。5. Included已纳入如何进入网络升级激活后所有已纳入的 Core EIP 与已激活的非 Core EIPMUST被移动到 Meta EIP 的Included部分且 Meta EIP 中的所有其他状态列表 MUST 被移除。含义Included表明这些 EIP 已作为网络升级的一部分被激活。阶段流转与治理原则Rationale 要点EIP-7723 的 Rationale 部分说明了几个关键设计取向可读性优先形式化五个阶段为协议维护者与更广泛的社区提供清晰的状态语言最小化强制步骤规范尽量压缩MUST级别的步骤以契合以太坊 rough consensus 的治理模式——这也是为何多数动作使用SHOULD/MAY而MUST仅用于关键的元流程如 Final 前改名Included、SFI 的测试要求流程自演进假设被采纳后该流程应至少运行一个完整网络升级周期后才进入Last Call至少运行两个完整网络升级周期后才进入Final以便根据实际运行中暴露的问题更新流程本身。向后兼容与安全考虑向后兼容EIP-7723 不直接改变以太坊协议它只是将当前网络升级规划流程的部分实践形式化安全考虑该 EIP 本身不引入新的安全考量原文标注 None版权文档按 CC0 放弃版权见仓库根目录 LICENSE.md。在 EIPs 仓库中如何跟踪阶段落地如果你想在仓库中跟踪这些阶段的真实落地情况可以按以下路径查阅流程母本EIP-1EIP 类型、工作流与状态机定义、EIP-7723本主题的纳入阶段规范升级 Meta EIP 实例EIP-7773GlamsterdamReview、EIP-8081HegotáDraft——对比两者的列表结构即可直观看到随状态流转列表收缩规则的作用专题目录型 Meta EIPEIP-8007Glamsterdam Gas Repricings以 CFI/DFI 表格组织 gas 重定价提案可作为非 Core 场景的参考。通过对比这些文件你可以观察到同一套阶段体系在不同状态、不同用途的 Meta EIP 中的具体呈现方式从而真正理解以太坊网络升级从有人提议到随升级激活的完整治理链路。结语EIP-7723 用最小的强制规范为以太坊网络升级规划建立了统一的阶段语言Proposed→Considered→Scheduled/Declined→Included并以升级 devnet 的实现状态作为工程约束锚点。对于 EIP 作者它明确了每个阶段需要提交什么PR、实现、测试对于客户端团队它提供了优先级排序与状态变更的决策框架对于社区观察者它让某 EIP 离上线还有多远变得透明可查。这份文档既是流程规范也是理解以太坊核心治理如何在粗略共识与工程纪律之间取得平衡的窗口。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7723 网络升级纳入阶段详解：EIPs 仓库中 Core EIP 从提案到激活的治理规范
EIP-7723 网络升级纳入阶段详解EIPs 仓库中 Core EIP 从提案到激活的治理规范【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7723Network Upgrade Inclusion Stages是一份 Meta 类 EIP它形式化了以太坊网络升级规划过程中 EIP 所经历的各阶段Proposed for Inclusion提议纳入、Considered for Inclusion考虑纳入、Scheduled for Inclusion排期纳入、Declined for Inclusion拒绝纳入与Included已纳入。本文以该文档为骨架结合当前 EIPs 仓库中真实的升级 Meta EIP如 EIP-7773、EIP-8081与 EIP-1 流程说明帮助你理解以太坊核心开发者如何决定哪些 EIP 进入下一次硬分叉以及提案作者、实现团队与测试团队在各阶段的职责与操作方式。为什么需要形式化升级纳入阶段以太坊的治理长期遵循rough consensus粗略共识模式。按照 EIP-1 的描述AllCoreDevs 电话会议通常会对应该实现哪些 EIP形成粗略共识这种共识建立在两个假设之上EIP 没有争议到足以引发网络分裂并且技术上健全。然而随着网络升级规模越来越大如 Dencun、Pectra一个 EIP 当前处于什么状态缺乏统一的、可被社区与客户端团队共同引用的语言。EIP-7723 的动机正是填补这一空白为网络升级规划过程中的 EIP 定义一套标准阶段并提供何时、如何将 EIP 从一个阶段移动到下一个阶段的上下文与准则。形式化这些阶段能让协议维护者与更广泛的以太坊社区获得更好的可读性legibility。该文档属于Meta类型 EIP状态为Last Call最后调用截止日期 2025-04-01作者包括 Tim Beiko、Alex Stokes 等长期负责网络升级协调的核心开发者。五个阶段的总体视图EIP-7723 定义了以下五个纳入阶段它们是本文的核心阶段缩写含义Proposed for InclusionPFI已有人提议将该 EIP 纳入某次网络升级Considered for InclusionCFI客户端开发者已审阅打算尝试在 devnet 中实现并测试Scheduled for InclusionSFI核心开发者确认有强烈意愿纳入且规范与实现已足够成熟Declined for InclusionDFI客户端团队反对将该 EIP 纳入本次升级IncludedIncluded升级已激活该 EIP 已随升级生效通用规则与适用范围每个阶段都针对单次网络升级所有纳入阶段都只适用于一次具体的网络升级。EIP 必须为每次网络升级分别Proposed、Considered、Declined或Scheduled一个 EIP 不能同时Included于两次网络升级一个 EIP 在上一次升级中被Declined for Inclusion并不妨碍它在未来的任何升级中被重新Proposed、Considered、Declined或Scheduled提案不会自动顺延如果某 EIP 未被纳入其首次提案对应的升级它不会自动带入下一次升级必须重新走流程。Core EIP 是主体non-Core EIP 可选用这些阶段主要针对Standards Track - Core EIP定义——这类 EIP 必须由网络上所有节点同步激活。为了便于优先级排序和沟通非 Core EIP 也可以被赋予这些阶段各阶段定义中已注明对非 Core EIP 的差异与含义。文档中的关键词约定规范部分按 RFC 2119 与 RFC 8174 解释关键词MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、OPTIONAL。也就是说MUST是硬性要求SHOULD是推荐实践MAY是允许选项——下文将按此语义区分各阶段的责任强度。Upgrade Meta EIP承载阶段列表的载体任何人均MAY起草一份 Meta EIP 来列出某次网络升级的 EIP。这类升级 Meta EIP 的规范Specification部分SHOULD包含四个类别Proposed for InclusionDeclined for InclusionConsidered for InclusionScheduled for Inclusion即使某个类别当前还是TBD待定也SHOULD在初始草稿中包含该类别以保证清晰性。随状态流转的列表收缩规则升级 Meta EIP 自身会经历 EIP-1 定义的 Draft → Review → Last Call → Final 流程其列表随之收缩升级 Meta EIP 移入Review时Proposed for Inclusion与Declined for Inclusion列表SHOULD被移除升级 Meta EIP 移入Last Call时Considered for Inclusion列表SHOULD被移除只保留Scheduled for Inclusion列表升级 Meta EIP 移入Final之前Scheduled for Inclusion阶段MUST改名为Included且只能包含随升级实际激活的 EIP。仓库中的实例当前仓库中的 EIP-7773Hardfork Meta - Glamsterdam状态 Review与 EIP-8081Hardfork Meta - Hegotá状态 Draft正是这一规范的直接应用两者都在规范部分声明各阶段定义见 EIP-7723并按EIPs Scheduled for Inclusion、Considered for Inclusion、Declined for Inclusion、Proposed for Inclusion分节列出 EIP。例如EIP-7773Review 状态已进入列表收缩的中间态只保留了Scheduled for Inclusion列表与Other EIPsNetworking EIP、Informational EIP分组并附有激活信息表Sepolia / Holešky / Mainnet 的激活 epoch 与时间戳留待客户端团队决定后填充EIP-8081Draft 状态则同时包含Scheduled for Inclusion、Considered for Inclusion、Declined for Inclusion暂为空与庞大的Proposed for Inclusion列表——这正是草稿阶段应保留全部四个类别的体现作为对照EIP-8007Glamsterdam Gas Repricings Meta EIP是一份纯信息性的目录型 Meta EIP自述不主动参与治理流程仅用Considered for Inclusion与Declined for Inclusion两类表格组织 gas 重定价相关提案。Upgrade Devnets纳入能力的物理约束在准备网络升级时客户端开发者通常先在**临时测试网络upgrade devnet**上实现 EIP以验证客户端互操作性之后再部署到长期测试网络testnet上。升级 devnet 遵循upgradeName-devnet-version的命名约定例如pectra-devnet-0Pectra 网络升级的第一个升级 devnetdencun-devnet-1Dencun 升级的第二个升级 devnet。由于客户端开发者能否将 EIP 纳入升级受限于这些 EIP 能否在升级 devnet 中被实现并测试EIP-7723 特别建议将Considered for Inclusion与Scheduled for Inclusion状态与 EIP 在升级 devnet 中的实现状态对齐——这是整个阶段体系与工程现实衔接的关键设计。各阶段详解1. Proposed for InclusionPFI提议纳入如何进入要提议某个 EIP 纳入升级提案人MUST打开一个 pull request将其添加到升级 Meta EIP 的Proposed for Inclusion部分。升级 Meta EIP 的作者SHOULD及时合并合理的 PR。责任约定EIP 的提案人SHOULD在整个升级周期内担任该 EIP 的主要联系人或SHOULD指定他人担任此角色在此阶段实现团队SHOULD审阅该 EIP对 Core EIP应在纳入本次升级的背景下审阅对非 Core EIP应在支持 Core EIP、支撑升级激活的背景下审阅。关键点提案必须针对每次网络升级单独发起不会自动顺延到下一次升级。2. Considered for InclusionCFI考虑纳入如何进入客户端开发者审阅了已Proposed for Inclusion的 EIP 后MAY将其移动到Considered for Inclusion阶段。一旦客户端团队决定移动升级 Meta EIPSHOULD被更新以反映这一变化。含义与配套动作Considered for Inclusion表示客户端开发者打算尝试将该 EIP 纳入 devnetAll Core Devs ExecutionACDE与 ConsensusACDC电话会议的协调人应与测试团队合作为 CFI EIP 提出优先级排序交由客户端开发者审阅并将此优先级反映到 Meta EIP 中该优先级用于决定哪些 EIP 应进入后续 devnet允许一定灵活性该阶段类似于其他开源项目中的 concept ACK概念认可不足以导致主网部署只有在满足主网部署全部要求的前提下才MAY被纳入网络升级处于 CFI 的非 Core EIPSHOULD在升级激活前获得支持如果客户端团队反对将该 EIP 纳入升级MAY将其从Considered for Inclusion移动到Declined for Inclusion。execution-specs 配套要求处于该阶段的 EIPSHOULD具有提交为开放 PR 的 Python 实现及配套测试位于以太坊执行层规范仓库 execution-specs 中EIP 作者被鼓励联系该仓库维护者获取实现协助。客户端开发者MAY允许 EIP 在缺少实现的情况下进入 CFI但需意识到实现缺失可能导致测试周期延迟。对该阶段 EIP 的任何更新SHOULD伴随 execution-specs 中实现与测试的相应更新若客户端开发者认为必要。3. Declined for InclusionDFI拒绝纳入如何进入在升级规划过程中的任何时刻如果客户端团队反对将该 EIP 纳入升级客户端开发者MAY将 EIP 从任何其他阶段移动到Declined for Inclusion。一旦决定做出升级 Meta EIPSHOULD被更新。含义Declined for Inclusion表示客户端开发者希望将该 EIP排除出当前网络升级并停止讨论其在本次升级中的纳入或实现状态在某次升级中被 DFI 的 EIPMAY在后续升级中重新被Proposed for Inclusion在特殊情况下客户端开发者MAY选择将 EIP 从Declined for Inclusion移回Considered for Inclusion或Scheduled for Inclusion。4. Scheduled for InclusionSFI排期纳入如何进入当核心开发者满足以下两个条件时可将 EIP 移动到Scheduled for Inclusion就将 EIP 纳入下一次网络升级达成强烈意愿同意该 EIP 的规范与实现已达到一定成熟度。即 SFI 状态表明除非出现不可预见的问题该 EIP 正处于纳入的正轨上。成熟度稳定性判据——以下标准可用于评估 EIP 是否足够成熟以进入 SFI已被纳入一个表现出稳定性的 devnet例如高参与率、持续 ≥1 周无关键 bugEIP 规范接近定稿无占位值或待定设计决策与其他 CFI EIP 的交互最小或这些交互已在同一 devnet 中测试测试覆盖充分客户端通过共识测试无已知跨客户端分歧。评审与批准流程All Core Devs TestingACDT电话会议可审阅 EIP 以判定 SFI 资格状态变更随后在 ACDE 或 ACDC 电话会议上批准后正式赋予 SFI 状态。配套约束规范不完整或交互未测试的 EIP 应保持 CFI直至条件满足最新的升级 devnet 必须包含所有已Scheduled for Inclusion的 Core EIP如情况变化EIPMAY从 SFI 移回 DFI客户端团队同意移除若客户端团队仍赞成纳入但无法承诺进入下一个升级 devnetMAY从 SFI 移回 CFI。execution-specs 强制要求比 CFI 更严格进入 SFI 的 EIPMUST具备提交为开放 PR 或已合并到仓库devnets/upgradeName/version分支的 Python 实现及配套测试。客户端开发者MAY允许 EIP 在缺少 execution-specs 实现的情况下进入 SFI但测试严格强制strictly mandatory。对该阶段 EIP 的任何更新MUST伴随 execution-specs 中实现与测试的相应更新若客户端开发者认为必要。5. Included已纳入如何进入网络升级激活后所有已纳入的 Core EIP 与已激活的非 Core EIPMUST被移动到 Meta EIP 的Included部分且 Meta EIP 中的所有其他状态列表 MUST 被移除。含义Included表明这些 EIP 已作为网络升级的一部分被激活。阶段流转与治理原则Rationale 要点EIP-7723 的 Rationale 部分说明了几个关键设计取向可读性优先形式化五个阶段为协议维护者与更广泛的社区提供清晰的状态语言最小化强制步骤规范尽量压缩MUST级别的步骤以契合以太坊 rough consensus 的治理模式——这也是为何多数动作使用SHOULD/MAY而MUST仅用于关键的元流程如 Final 前改名Included、SFI 的测试要求流程自演进假设被采纳后该流程应至少运行一个完整网络升级周期后才进入Last Call至少运行两个完整网络升级周期后才进入Final以便根据实际运行中暴露的问题更新流程本身。向后兼容与安全考虑向后兼容EIP-7723 不直接改变以太坊协议它只是将当前网络升级规划流程的部分实践形式化安全考虑该 EIP 本身不引入新的安全考量原文标注 None版权文档按 CC0 放弃版权见仓库根目录 LICENSE.md。在 EIPs 仓库中如何跟踪阶段落地如果你想在仓库中跟踪这些阶段的真实落地情况可以按以下路径查阅流程母本EIP-1EIP 类型、工作流与状态机定义、EIP-7723本主题的纳入阶段规范升级 Meta EIP 实例EIP-7773GlamsterdamReview、EIP-8081HegotáDraft——对比两者的列表结构即可直观看到随状态流转列表收缩规则的作用专题目录型 Meta EIPEIP-8007Glamsterdam Gas Repricings以 CFI/DFI 表格组织 gas 重定价提案可作为非 Core 场景的参考。通过对比这些文件你可以观察到同一套阶段体系在不同状态、不同用途的 Meta EIP 中的具体呈现方式从而真正理解以太坊网络升级从有人提议到随升级激活的完整治理链路。结语EIP-7723 用最小的强制规范为以太坊网络升级规划建立了统一的阶段语言Proposed→Considered→Scheduled/Declined→Included并以升级 devnet 的实现状态作为工程约束锚点。对于 EIP 作者它明确了每个阶段需要提交什么PR、实现、测试对于客户端团队它提供了优先级排序与状态变更的决策框架对于社区观察者它让某 EIP 离上线还有多远变得透明可查。这份文档既是流程规范也是理解以太坊核心治理如何在粗略共识与工程纪律之间取得平衡的窗口。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考