EIP-7723: 网络升级包含阶段
核心 EIP 在网络升级中激活之前所经历的各个阶段的概述。
| Authors | Tim Beiko (@timbeiko) |
|---|---|
| Created | 2024-06-12 |
| Last Call Deadline | 2025-04-01 |
Table of Contents
摘要
定义 EIP 在规划网络升级过程中所经历的阶段：Proposed for Inclusion（建议包含）、Considered for Inclusion（考虑包含）、Scheduled for Inclusion（计划包含）、Declined for Inclusion（拒绝包含）和 Included（已包含）。
动机
本 EIP 提出了 EIP 在规划网络升级时所经历的各个阶段的定义。它还提供了关于何时以及如何将 EIP 从一个阶段移到下一个阶段的背景和指南。
规范
本文档中使用的关键词 “MUST”（必须）、”MUST NOT”（禁止）、”REQUIRED”（需要）、”SHALL”（应）、”SHALL NOT”（不应）、”SHOULD”（应该）、”SHOULD NOT”（不应该）、”RECOMMENDED”（推荐）、”NOT RECOMMENDED”（不推荐）、”MAY”（可以）和 “OPTIONAL”（可选）按照 RFC 2119 和 RFC 8174 中的描述进行解释。
所有 EIP 状态都适用于单个网络升级。EIP 必须为每个网络升级单独进行 Proposed（建议）、Considered（考虑）、Declined（拒绝）或 Scheduled（计划）。虽然一个 EIP 不能在两个网络升级中 Included（已包含），但在之前的升级中 Declined for Inclusion（拒绝包含）的 EIP 并不妨碍它在任何未来的升级中被 Proposed（建议）、Considered（考虑）、Declined（拒绝）或 Scheduled（计划）包含。
以下状态通常为核心 EIP 定义，核心 EIP 必须由网络上的所有节点同步激活。为了帮助确定优先级和进行沟通，非核心 EIP 也可以被分配这些状态。过程和对非核心 EIP 的影响的差异在每个状态定义中都有说明。
升级元 EIP
任何人 MAY（可以）起草一个元 EIP，以列出网络升级的 EIP。此元 EIP SHOULD（应该）在其规范部分包含四个类别：Proposed for Inclusion（建议包含）、Declined for Inclusion（拒绝包含）、Considered for Inclusion（考虑包含）和 Scheduled for Inclusion（计划包含）。即使某个类别为空，也 SHOULD（应该）将其包含在初始草案中以保持清晰。
当升级元 EIP 被移至 Last Call（最后征求意见）时，Proposed for Inclusion（建议包含）、Declined for Inclusion（拒绝包含）和 Considered for Inclusion（考虑包含）列表 SHOULD（应该）被删除，仅留下 Scheduled for Inclusion（计划包含）。
在升级元 EIP 被移至 Final（最终）之前，Scheduled for Inclusion（计划包含）阶段 MUST（必须）重命名为 Included（已包含），并且仅包含在升级中激活的 EIP。
升级 Devnet
在准备网络升级时，客户端开发人员通常首先在临时的测试网络（升级 devnet）上实现 EIP，以验证客户端的互操作性，然后再部署到长期存在的测试网络。这些升级 devnet 遵循 upgradeName-devnet-version 的命名约定（例如，Pectra 网络升级的第一个升级 devnet 为 pectra-devnet-0，Dencun 更新的第二个升级 devnet 为 dencun-devnet-1，等等）。
由于客户端开发人员将 EIP 包含在网络升级中的能力受到可以在这些升级 devnet 中实现和测试的内容的限制，因此下面的 Considered for Inclusion（考虑包含）和 Scheduled for Inclusion（计划包含）部分建议将这些状态与 EIP 在升级 devnet 中的实现状态对齐。
Proposed for Inclusion
要建议包含一个 EIP，某人 MUST（必须）打开一个拉取请求，将其添加到升级元 EIP 的 Proposed for Inclusion（建议包含）部分。升级元 EIP 作者 SHOULD（应该）及时合并合理的拉取请求。
在这个阶段，实现团队 SHOULD（应该）审查 EIP。对于核心 EIP，这应该在将其包含在下一个升级的背景下进行。对于非核心 EIP，这应该在网络升级激活之前支持 EIP 的背景下进行。
请注意，EIP 必须为每个网络升级 Proposed for Inclusion（建议包含）。换句话说，如果一个 EIP 没有包含在它最初建议的升级中，则提案不会“延续”到下一个升级。
Considered for Inclusion
一旦客户端开发人員审查了 Proposed for Inclusion（建议包含）的 EIP，他们 MAY（可以）将其移至 Considered for Inclusion（考虑包含）阶段。一旦客户端团队决定将 EIP 移至 Considered for Inclusion（考虑包含），则 SHOULD（应该）更新升级元 EIP 以反映这一点。
Considered for Inclusion（考虑包含）表示客户端开发人员对 EIP 持积极态度。一个 Considered for Inclusion（考虑包含）的核心 EIP SHOULD（应该）在未来的升级 Devnet 中实现。假设它满足主网部署的所有要求，它 MAY（可以）包含在网络升级中。此阶段类似于其他开源项目中的“概念 ACK”，并且不足以导致部署到主网。
Considered for Inclusion（考虑包含）的非核心 EIP SHOULD（应该）在网络升级激活之前得到支持。
如果客户端团队反对将 EIP 包含在网络升级中，则 MAY（可以）将 EIP 从 Considered for Inclusion（考虑包含）移至 Declined for Inclusion（拒绝包含）。
EIP SHOULD（应该）在 execution-specs 中有一个 Python 实现，作为开放的 PR 提交，并在 execution-spec-tests 中有相应的测试，也作为开放的 PR 提交。鼓励 EIP 作者联系这两个存储库的维护者，以获得实现方面的帮助。客户端开发人员 MAY（可以）决定允许 EIP 在没有任一实现的情况下移至 Considered for Inclusion（考虑包含），但要知道缺少这些实现可能会导致测试周期延迟。
如果客户端开发人员认为必要，则对此阶段已有的 EIP 的任何更新 SHOULD（应该）伴随对其在 execution-specs 和 execution-spec-tests 中的实现的相应更新。
Declined for Inclusion
在网络升级规划过程中的任何时间，如果客户端团队反对将 EIP 包含在网络升级中，客户端开发人员 MAY（可以）将 EIP 从任何其他阶段移至 Declined for Inclusion（拒绝包含）阶段。一旦客户端团队决定将 EIP 移至 Declined for Inclusion（拒绝包含），则 SHOULD（应该）更新升级元 EIP 以反映这一点。
Declined for Inclusion（拒绝包含）表示客户端开发人员希望将 EIP 从当前的網絡升级中排除，并停止讨论其与此升级相关的潜在包含或实现状态。在一个特定升级中 Declined for Inclusion（拒绝包含）的 EIP MAY（可以）仍然在后续升级中 Proposed for Inclusion（建议包含）。在特殊情况下，客户端开发人员 MAY（可以）选择将 EIP 从 Declined for Inclusion（拒绝包含）移至 Considered for Inclusion（考虑包含）或 Scheduled for Inclusion（计划包含）。
Scheduled for Inclusion
当客户端团队同意在 下一个 升级 Devnet 中实现核心 EIP 时，EIP SHOULD（应该）移至 Scheduled for Inclusion（计划包含）阶段，并且 SHOULD（应该）更新升级元 EIP 以反映这一点。当客户端团队同意立即优先考虑其实现时，非核心 EIP SHOULD（应该）移至 Scheduled for Inclusion（计划包含）。
EIP MUST（必须）在 execution-specs 中有一个 Python 实现，作为开放的 PR 提交或合并到存储库的 devnets/upgradeName/version 分支，并在 execution-spec-tests 中有相应的测试，也作为开放的 PR 提交或合并到存储库的 main 分支。客户端开发人员 MAY（可以）决定允许 EIP 在没有 execution-specs 实现的情况下移至 Scheduled for Inclusion（计划包含），但测试是强制性的。
如果客户端开发人员认为必要，则对此阶段已有的 EIP 的任何更新 MUST（必须）伴随对其在 execution-specs 和 execution-spec-tests 中的实现的相应更新。
Scheduled for Inclusion（计划包含）表示实现和测试工作正在进行中。如果没有出现问题，EIP SHOULD（应该）包含在网络升级中。最新的升级 Devnet 必须包含所有 Scheduled for Inclusion（计划包含）的核心 EIP。
如果客户端团队反对将 EIP 包含在网络升级中，则 MAY（可以）将 EIP 从 Scheduled for Inclusion（计划包含）移至 Declined for Inclusion（拒绝包含）。如果客户端团队赞成将 EIP 包含在网络升级中，但无法承诺将其包含在 下一个 升级 Devnet 中，则 MAY（可以）还将 EIP 从 Scheduled for Inclusion（计划包含）移至 Considered for Inclusion（考虑包含）。
Included
在网络升级激活之后，所有包含的核心 EIP 和激活的非核心 EIP MUST（必须）在元 EIP 中移至 Included（已包含）。所有其他状态列表 MUST（必须）从元 EIP 中删除。
Included（已包含）表示 EIP 已作为网络升级的一部分激活。
理由
正式化 Proposed for Inclusion（建议包含）、Considered for Inclusion（考虑包含）、Scheduled for Inclusion（计划包含）、Declined for Inclusion（拒绝包含）和 Included（已包含）阶段为协议维护者和更广泛的以太坊社区提供了更好的可读性。
该规范试图最小化 MUST（必须）遵循的步骤，以与以太坊的“粗略共识”治理模型保持一致。
假设它被采用，本 EIP 中概述的过程应至少用于一个完整的网络升级周期，然后再移至 Last Call（最后征求意见），并且至少用于两个完整的网络升级周期，然后再移至 Final（最终）。这样，可以更新 EIP 以反映随着时间的推移对该过程所做的更改。
向后兼容性
本 EIP 不直接更改以太坊协议。它正式化了当前网络升级规划过程的某些部分。
安全考虑
无。
版权
通过 CC0 放弃版权和相关权利。
Citation
Please cite this document as:
Tim Beiko (@timbeiko), "EIP-7723: 网络升级包含阶段 [DRAFT]," Ethereum Improvement Proposals, no. 7723, June 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7723.