EIPs

以太坊改进提案 (EIPs) 描述了以太坊平台的标准，包括核心协议规范、客户端 APIs 和合约标准。网络升级在 Ethereum Project Management 仓库中单独讨论。

贡献

首先查看 EIP-1。然后克隆仓库并将您的 EIP 添加到其中。这里有一个 EIP 模板。然后向以太坊的 EIPs 仓库 提交拉取请求。

EIP 状态术语

• 想法 - 草案前的想法。这不在 EIP 仓库中跟踪。
• 草案 - EIP 开发中第一个正式跟踪的阶段。格式正确时，EIP 编辑器会将 EIP 合并到 EIP 仓库中。
• 审议 - EIP 作者将 EIP 标记为准备好并请求同行审议。
• 最终征求意见 - 这是 EIP 在进入最终状态前的最后审议窗口。EIP 编辑器将分配最终征求意见状态并设置审议结束日期 (`last-call-deadline`)，通常是 14 天后。如果此期间导致必要的规范性更改，它将把 EIP 恢复到审议状态。
• 最终 - 此 EIP 代表最终标准。最终 EIP 处于完成状态，应仅更新以纠正勘误和添加非规范性说明。
• 停滞 - 任何处于草案或审议状态的 EIP，如果 6 个月或更长时间不活跃，将移至停滞状态。EIP 可以通过作者或 EIP 编辑器将其移回草案状态从这种状态中复活。
• 撤回 - EIP 作者已撤回拟议的 EIP。此状态具有最终性，不能再使用此 EIP 编号复活。如果以后继续这个想法，则被视为新提案。
• 活跃 - EIP 的特殊状态，设计为持续更新且不达到最终状态。这最明显地包括 EIP-1。

EIP 类型

EIPs 分为多种类型，每种类型都有自己的 EIPs 列表。

标准跟踪 (876)

描述影响大多数或所有以太坊实现的任何更改，例如网络协议的更改、区块或交易有效性规则的更改、拟议的应用标准/约定，或影响使用以太坊的应用程序互操作性的任何更改或添加。此外，标准 EIPs 可以分为以下类别。

核心 (316)

需要共识分叉的改进 (e.g. EIP-5, EIP-211), 以及不一定是共识关键，但可能与“核心开发”讨论相关的更改(例如, EIP-225中描述的测试网的PoA算法).

网络 (22)

包括围绕 devp2p (EIP-8) 和轻量以太坊子协议的改进，以及对 whisper 和 swarm 网络协议规范的拟议改进。

接口 (52)

包括对客户端API/RPC规范和标准的改进，以及某些语言级别的标准，如方法名 (EIP-6) 和合约ABIs。“接口”标签与接口库保持一致，并且在EIP提交到EIP存储库之前，应该主要在该存储库中进行讨论。

ERC (486)

应用级标准和约定，包括合约标准，如代币标准 (EIP-20)、名称注册表 (EIP-137)、URI 方案 (EIP-681)、库/包格式 (EIP-190) 和账户抽象 (EIP-4337)。

元数据 (38)

描述围绕以太坊的流程或提议对流程的更改（或流程中的事件）。流程 EIPs 类似于标准跟踪 EIPs，但适用于以太坊协议本身以外的领域。它们可能提议实现，但不针对以太坊的代码库；它们通常需要社区共识；与信息类 EIPs 不同，它们不仅仅是建议，用户通常不能自由地忽略它们。示例包括程序、指南、决策过程的更改，以及对以太坊开发中使用的工具或环境的更改。任何元数据 EIP 也被视为流程 EIP。

信息类 (14)

描述以太坊设计问题，或向以太坊社区提供一般指导或信息，但不提议新功能。信息类 EIPs 不一定代表以太坊社区共识或建议，因此用户和实现者可以自由地忽略信息类 EIPs 或遵循其建议。