# EIPs 概要

以太坊改进提案(EIPs)描述了以太坊平台的标准,包括核心协议规范,客户端 API和合同标准。 任何人都可以参与以太坊的改进,参与的方式是向以太坊EIPs GitHub库提交改进提案的pull request,大家可以阅读EIP-1 了解如何提交改进提案。

# EIP 状态(status terms)

一个“成功的”EIP会经过以下几个状态:

草案(Draft -> 最后召集(Last Call) -> 已接受(Accepte) -> 最终(Final)
1
  • 草案 Draft - 说明此提案还在开放讨论,正在进行快速迭代和更改的EIP。
  • 最后召集 Last Call - 完成了初始迭代,并准备好供更大受众查阅。
  • 已接受 Accepted - 核心EIP(core EIP) 至少在 最后召集 状态至少两周。并且作者已解决了所要求的任何技术变更。核心开发团队决定是否将EIP作为硬分叉的一部分编码到客户端(硬分叉的过程不是EIP过程的一部分)。 如果做出这样的决定,EIP将进入最终决定。
  • 最终 Final (non-Core) - EIP 至少在 最后召集 状态至少两周。并且作者已解决了所要求的任何技术变更。
  • 最终 Final (Core) - 核心开发团队决定实现此EIP并作为将来/或已经硬分叉的一部分。

# EIP 分类(Types)

EIP 分为多种类型,每种类型都有自己的EIP列表。

# 标准跟踪 Standard Track (202)

描述影响以太坊实现的任何更改,例如网络协议的更改、块或交易有效性规则的更改、应用程序标准或约定,或影响以太坊应用程序交互的任何更改或添加。标准跟踪EIP 细分为以下几类。

# 核心 Core (84)

核心提案包含产生共识分叉的改进(如:EIP5EIP101),以及一些也许不是共识部分但可能与“核心开发”讨论相关的变更(例如,矿工/节点策略更改EIP86的2,3和4))。

# 网络 Networking (7)

包括围绕devp2p (EIP8) 和轻客户端子协议的改进,以及对 whisper 和 swarm 网络协议规范的改进建议。

# 接口 Interface (18)

包括有关客户端API/RPC规范和标准的改进,以及某些语言级别标准,如方法名(EIP6)和合约ABI。

# 应用标准提案 ERC (93)

ERC 是 Ethereum Request for Comment 的缩写,原本是征求大家意见的意思,主要是应用程序标准或约定,包含如:代币标准合约(ERC20),名称注册(ERC137),URI schemes (ERC681),库/包格式 (EIP190), 钱包格式 (EIP85)等。

# 元提案 Meta (14)

描述以太坊的改进过程(或事件),也被视为过程EIP(Process EIP)。 流程EIP类似于标准跟踪EIP,但流程EIP描述以太坊协议外的内容(而不是协议本身)。 他们可能会提出一个实现,但不会加入到以太坊的代码库; 这些提案经常需要社区共识; 与信息EIP不同,它们不仅仅是建议,用户通常也不能忽略它们。 提案包括程序,指南,决策过程的变更以及以太坊开发中使用的工具或环境的变更。

# 信息提案 Informational (1)

描述以太坊设计问题,或向以太坊社区提供一般指导信息,但不提出新功能。 信息提案不一定代表以太坊社区的共识或推荐,因此用户和实施者可以自由地忽略信息EIP或遵循他们的建议。