HBC 环保卫士系统搭建

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

#EIP 状态（status terms）

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

草案（Draft -> 最后召集（Last Call） -> 已接受（Accepte） -> 最终（Final）

• 草案 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)

核心提案包含产生共识分叉的改进(如：EIP5, EIP101)，以及一些也许不是共识部分但可能与“核心开发”讨论相关的变更（例如，矿工/节点策略更改 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 或遵循他们的建议。