EIPs

以太坊改进建议 (EIP) 描述了以太坊平台标准，包括核心协议规范、客户端API和合约标准。网络升级的问题将在以太坊项目管理仓库

贡献

首先审查 EIP-1，然后克隆仓库，将你的 EIP 添加到其中。这里有一个 EIP 模板。然后向 Ethereum 的 EIPs 仓库提交一个 PR 请求。

EIP状态术语

想法-Idea - 一个预先起草的想法，不在 EIP 资源库中跟踪。
草稿-Draft - EIP 进展中的第一个正式跟踪阶段。当格式正确时，EIP 编辑会将 EIP 合并到 EIP 资源库中。
审核-Review - EIP 作者将 EIP 标记为准备好并请求同行评审。
最后公示-Last Call - 这是 EIP 进入Final的最后公示窗口。 EIP编辑将指定 Last Call 状态，并设定公示期限 (`Last-call-deadline`)，通常是14天后。如果这段时间产生了必要的规范性修改，它将把 EIP 恢复为 Review。
终版-Final - 该 EIP 代表了最终标准。终版 EIP 是以最终状态存在的，只应在纠正勘误和增加非规范性澄清时进行更新。
停滞-Stagnant - 任何处于DRAFT 或 REVIEW 或 Last Call 状态的EIP，如果在 6 个月或更长时间内没有活动，将移至 Stagnant。 EIP 可由作者或编辑将其移回草案状态。
撤回-Withdrawn - EIP 作者已撤回提案的 EIP。这种状态具有终结性，不能再使用这个 EIP 编号复活。如果这个想法在以后的日子里被推行，它将被视为一个新的提案。
活的-Living - EIP 的特殊状态，适用于那些旨在持续更新而未达到终版状态的 EIP。这包括最引入注目的 EIP-1。

EIP 类型

EIP 被分成若干类型，每种类型都有自己的 EIP 清单。

标准类 (529)

描述了影响多数或全部以太坊实现的任何更改，例如网络协议的更改、块或交易有效性规则的更改、提议的应用程序标准/约定，或影响以太坊应用程序交互的任何更改或添加。标准类 EIP 由三部分组成 - 设计文档、实施、（如果有必要）对正式规范的更新。此外，标准类 EIP 可细分为：

核心-Core (0)

需要共识分叉的改进(如 EIP-5, EIP-211, EIP-211), 以及那些或许非共识关键但可能与“核心开发”讨论相关的（如 EIP-225) 中描述的测试网 PoA 算法）。

网络-Networking (0)

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

接口-Interface (0)

包括围绕客户端 API/RPC 规格和标准的改进，还有某些语言级别的标准，如方法名 (EIP-6) 和合约 ABIs。标签“interface”与 interfaces 仓库一致，在将 EIP 提交到 EIP 存储库之前，讨论应该主要发生在该库中。

应用-ERC (0)

应用层面的标准和约定，包括合约标准，如代币标准 (EIP-20)、名称注册 (EIP-137)、URI 方案 (EIP-681)、库/包格式 (EIP-190)和钱包格式(EIP-4337)。

描述了围绕以太坊的一个流程或提出对一个流程的变更（或一个事件）。流程 EIP 类似于标准类 EIP，但流程 EIP 适用于以太坊协议之外的领域。他们可能会提出一个实施方案，但不会针对以太坊代码库；他们通常需要社区达成共识；与信息类 EIP 不同，它们不仅仅是建议，用户一般不能随意忽略它们。这方面的提案包括程序、指南、决策过程的更改以及以太坊开发中使用的工具或环境的更改。任何 meta-EIP 也会被视为一个流程 EIP。

信息类-Informational (6)

描述以太坊的设计问题，或向以太坊社区提供一般的指南或资讯，而非提出新功能。它不一定代表以太坊社区的共识或建议，所以用户和实施者可以自由的选择遵循或忽略信息类 EIP 所提出的建议。