以太坊 EIP-1：EIP 目的和指南

七兄弟

需要读完

24分钟

8分钟速读

译者：开发者七哥原文：译文：

1个

什么是 EIP？

EIP指的是以太坊改进提案（Ethereum Improvement Proposal）。 EIP是为以太坊社区提供信息，或描述以太坊新功能、新流程、新环境的设计文档。 EIP 应提供简明的技术规范和功能原理。 EIP 作者负责在社区内就 EIP 建立共识并记录异议。

2个

EIP的原理

我们打算让 EIP 成为提出新功能、从社区收集有关某个问题的技术输入以及记录以太坊设计决策的主要机制。 由于 EIP 在版本化存储库中以文本文件的形式维护，因此版本修订历史就是功能提案的历史。

对于以太坊实施者而言，EIP 是跟踪其实施进度的便捷方式。 理想情况下，每个实现维护者都会列出他们已实现的 EIP。 这将为最终用户提供一种方便的方式来了解特定实现或库的当前状态。

3个

弹性IP类型

EIP 有 3 种类型：

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

Informational EIP（Informational EIP）描述了以太坊的设计问题，或者向以太坊社区提供一般性的指导或信息，而不是提出新的特性。 它不一定代表以太坊社区的共识或建议，因此用户和实施者可以自由选择遵循或忽略信息型 EIP 提出的建议。

强烈建议单个 EIP 仅包含一个关键提案或新想法。 EIP 越专注，它就会越成功。 对一个客户端的更改不需要 EIP； 对影响多个客户端或被多个应用程序使用的标准定义的更改需要 EIP。

EIP 必须满足某些最低标准。 它必须清楚和完整地描述提议的改进。 这种增强必须是净改进。 提案的实施（如果适用）必须扎实并且不会使协议过于复杂。

3.1

核心EIP的特殊要求

如果核心 EIP 提到或建议对 EVM（以太坊虚拟机）进行更改，它应该通过助记符来引用指令，并至少为这些助记符定义一次操作码。 首选方式如下：

REVERT (0xfe)

4个

EIP工作流程

4.1

田园生态产业园

EIP 过程中涉及的各方是您、倡导者或 EIP 作者、EIP 编辑者和以太坊核心开发人员。

在开始编写正式的 EIP 之前，您应该仔细考虑您的想法。 如果这个想法是原创的，请先询问以太坊社区，避免将时间浪费在基于先前研究而被拒绝的事情上。 因此建议在 Ethereum Magicans 论坛 ( ) 上开一个帖子来讨论它。

想法经过审查后，您的下一个职责是（通过 EIP）向审查人员和所有感兴趣的各方展示您的想法，邀请编辑、开发人员和社区通过上述渠道提供反馈。 您应该尝试平衡对您的 EIP 的兴趣与实施它所涉及的工作以及有多少方必须遵守它。 例如，实现一个核心 EIP 所需的工作量将比 ERC 大得多，EIP 将需要以太坊客户团队的足够兴趣。 考虑负面的社区反馈以太坊地址格式，这可能会阻止您的 EIP 通过草案阶段。

4.2

核心 EIP

对于核心 EIP，由于它们要求客户端实现被认为是最终的（请参阅下面的“EIP 流程”），您需要为客户提供实现或说服客户实现您的 EIP。

让客户实施者审查您的 EIP 的最佳方式是在 AllCoreDevs 电话会议上展示它。 您可以通过在 AllCoreDevs 议程 GitHub Issue ( ) 上发布链接您的 EIP 的评论来请求这一点。

AllCoreDevs 调用是客户端实现者执行三件事的一种方式。 首先，讨论EIP的技术优点； 其次，衡量其他客户将实施什么； 三是统筹实施EIP网络升级改造。

这些呼吁通常会就应实施哪些 EIP 达成“粗略共识”。 这种“粗略的共识”是基于这样的假设，即 EIP 的争议性不足以导致网络分裂，并且 EIP 在技术上是合理的。

⚠️ EIP 流程和 AllCoreDevs 调用并非旨在解决有争议的非技术问题，但由于缺乏其他解决方法，往往最终会被卷入其中。 这给客户端实施者带来了尝试和衡量社区情绪的负担，从而阻碍了 EIP 和 AllCoreDevs 调用的技术协调功能。 如果您正在指导 EIP，您可以通过确保您的 EIP 的 Ethereum Magicians 论坛 ( ) 线程包含或链接到尽可能多的社区讨论来促进建立社区共识的过程，并确保各种利益相关者更容易获得充分授权。

简而言之，您作为倡导者的角色是使用下述风格和格式编写 EIP，在适当的论坛中引导讨论，并围绕该想法建立社区共识。

4.3

EIP流程

以下是所有轨道上所有 EIP 的规范化流程。

Idea - 想法 - 一个预先起草的想法，未在 EIP 存储库中跟踪。

Draft - Draft - EIP 进度的第一个正式跟踪阶段。 当格式正确时，EIP 编辑器会将 EIP 合并到 EIP 存储库中。

Review - Review - EIP 作者将 EIP 标记为就绪并请求同行评审。

Final Publicity - Last Call - 这是EIP进入Final的最终公示窗口。 EIP编辑器会指定Last Call状态，并设定公示期限（Last-call-deadline），一般在14天之后。 如果在此期间进行必要的规范性更改，EIP 将恢复审查。

Final - Final - 此 EIP 代表最终标准。 最终 EIP 处于最终状态，仅应更新以更正勘误表并添加非规范性说明。

Stagnant-Stagnant - 处于 DRAFT 或 REVIEW 或 Last Call 状态的任何 EIP 已停用 6 个月或更长时间，将移至 Stagnant。 作者或编辑可以通过将 EIP 移回草稿或更早的状态来使 EIP 从停滞中恢复过来。 如果不恢复，提案可能会永远保持这种状态。

EIP 作者将收到有关其 EIP 状态的任何算法更改的通知。

Withdrawn - Withdrawn - 其提案已被 EIP 作者撤回的 EIP。 此状态是最终状态，无法使用此 EIP 编号复活。 如果这个想法在以后被采纳以太坊地址格式，它将被视为一个新提案。

Living - EIP 的特殊状态，适用于那些打算持续更新但尚未达到最终状态的 EIP。 这包括最著名的 EIP-1。

5个

一个成功的 EIP 应该包括什么？

每个 EIP 应包含以下部分：

6个

EIP格式和模板

EIP要写成markdown格式，有模板可循：

7

EIP 头部序言

每个 EPI 必须以 RFC 822 ( ) 样式的标头前导码开头，前后加上三个连字符 (---)。 这个头也被 Jeyll 称为“front matter”（）。 标头必须按以下顺序出现：

eip：EIP 编号（由 EIP 编辑器决定）。

title：EIP的标题是几个词，不是一个完整的句子

描述：描述是一个完整的（短的）句子

author：作者的姓名和/或用户名，或姓名和电子邮件列表。 详情见下文。

* discussions-to: 指向官方讨论主题的URL

状态：状态：草稿、审查、最后一次通话、最终、停滞、撤回、生活

last-call-deadline：最终调用截止时间（可选字段，仅当状态为Last Call时才需要）。

类型：标准轨道、元或信息之一。

类别：核心、网络、接口或 ERC 之一（可选字段，仅在标准跟踪 EIP 中需要）

created：EIP 的创建日期

* 要求：（依赖）EIP 编号（可选字段）

withdrawal-reason：一句话解释为什么EIP被撤回。 （可选字段，仅当状态为撤回时才需要）

可能的标题列表必须包含以逗号分隔的元素。

标头要求日期始终采用 ISO 8601 格式 (yyyy-mm-dd)。

7.1

作者头

作者标头列出了 EIP 作者/所有者的姓名、电子邮件地址或用户名。 那些喜欢保持匿名的人可以只使用用户名，或者名字和用户名。 作者标题内容格式必须是：

如果包括电子邮件地址或 GitHub 用户名：

> 随机 J. 用户或随机 J. 用户 (@username)

如果没有提供电子邮件地址：

> 随机J.用户

不能同时使用电子邮件和 GitHub 用户名。 如果你必须同时使用两者，你​​可以写两次你的名字，一次用你的 GitHub 用户名，一次用你的电子邮件。

至少一位作者必须拥有 GitHub 用户名才能收到修订请求的通知并有权批准或拒绝它们。

7.2

讨论——到头

尽管 EIP 是草案，但 discussions-to 标头将指示讨论 EIP 的 URL。

首选的讨论站点是 Ethereum Magicans ( ) 线程。 该 URL 不能指向 Github PR、任何临时 URL 以及任何可能随时间锁定的 URL（例如 Reddit 线程）。

7.3

类型标题

类型标头指定 EIP 类型：Standards Track、Meta 或 Informational。 如果类别是标准的，则包括子类别（核心、网络、接口或 ERC）。

7.4

类别负责人

类别标头指定 EIP 的类别。 这仅适用于标准类 EIP。

7.5

创建头

创建的标题记录了为 EIP 分配编号的日期。 两个标头都应采用 yyyy-mm-dd 格式，例如 2001-08-14。

7.6

需要标题

EIP 可能有一个 requires 标头，指示 EIP 所依赖的 EIP 编号。 如果存在这样的依赖关系，则此字段是必需的。

如果没有另一个 EIP 的概念或技术元素就无法理解或实施当前的 EIP，就会出现 require 依赖。 仅仅提及另一个 EIP 并不一定会产生这种依赖性。

8个

关联外部资源

除下面列出的特定例外情况外，不应包含指向外部资源的链接。 外部资源可能突然消失、移动或改变。

EIP-5757 (./eip-5757.md) 中描述了管理允许的外部资源的过程。

8.1

共识层规范

可以使用普通的 markdown 语法包含到以太坊共识层规范的链接，例如：

[Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md)

渲染到：

信标链

允许的共识层规范的 URL 必须锚定到特定的提交，因此必须匹配此正则表达式。

^https://github.com/ethereum/consensus-specs/blob/[0-9a-f]{40}/.*$

8.2

网络规范

可以使用常规降价语法包含指向以太坊网络规范的链接，例如：

[Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md)

渲染到：

以太坊连接协议

允许的 Web 规范 URL 必须锚定到特定提交，因此必须与此正则表达式匹配。

^https://github.com/ethereum/devp2p/blob/[0-9a-f]{40}/.*$

8.3

数字对象标识符系统

符合数字对象标识符 (DOI) 资格的链接可以使用以下语法：

这是个带有脚注的句子。[^1]
[^1]:    ```csl-json    {      "type": "article",      "id": 1,      "author": [        {          "family": "Jameson",          "given": "Hudson"        }      ],      "DOI": "00.0000/a00000-000-0000-y",      "title": "An Interesting Article",      "original-date": {        "date-parts": [          [2022, 12, 31]        ]      },      "URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y",      "custom": {        "additional-urls": [          "https://example.com/an-interesting-article.pdf"        ]      }    }    ```   

有关支持的字段，请参阅引文样式语言模式 ( )。 除了根据架构通过验证外，引用还必须包含一个 DOI 和至少一个 URL。

顶级 URL 字段必须解析为可以零成本查看的参考副本。 additional-urls 下的值也必须解析为引用的副本，但可能会产生费用。

9

关联到其他 EIP

对其他 EIP 的引用应遵循 EIP-N 格式，其中 N 是您引用的 EIP 的编号。 EIP 中引用的每个 EIP 第一次引用时必须有一个相对的 markdown 链接，并在后续引用时有一个链接。 该链接必须始终使用相对路径，以便该链接在 GitHub 存储库、此存储库的分支、EIP 主站点、EIP 主站点的镜像中有效，例如，您可以使用 ./eip-1.md 链接到此 EIP .

10

辅助文件

图像、图表和辅助文件应包含在该 EIP 的资产文件夹的子目录中，如下所示：assets/eip-N（将 N 替换为 EIP 编号）。 当链接到 EIP 中的图像时，使用相对链接，例如 ../assets/eip-1/image.png。

11

EIP所有权的转移

有时需要将 EIP 的所有权转让给新的支持者。 一般来说，我们希望保留原作者作为分配的 EIP 的合著者，但这完全取决于原作者。 转让所有权的一个很好的理由是原作者不再有时间或兴趣更新它或遵循 EIP 流程，或者已经失去在线联系（即无法联系或不回复电子邮件）。 转让所有权的一个糟糕理由是，如果你不同意 EIP 的发展方向。 我们尝试围绕 EIP 建立共识，但如果不可能，您可以随时提交竞争性 EIP。

如果您有兴趣获得 EIP 的所有权，请向原作者和 EIP 编辑发送消息请求接管。 如果原作者没有及时回复邮件，EIP编辑会做出单方面的决定（这种决定不是不可逆的:)）。

12

EIP编辑器

当前的 EIP 编辑器是

EIP 名誉编辑：

如果你想成为一名 EIP 编辑，请查看 EIP-5069。

13

EIP 编辑职责

对于每个新输入的 EIP，编辑器将执行以下操作：

如果 EIP 没有准备好，编辑会发回给作者修改，并附上具体说明。

一旦 EIP 准备就绪，EIP 编辑器将：

许多 EIP 由有权编写以太坊代码的开发人员编写和维护。 EIP 编辑会监控 EIP 的更改，并纠正我们发现的任何结构、语法、拼写或标记错误。

编辑不评判 EIP。 我们刚刚完成了管理和编辑部分。

14

时尚指南

14.1

标题

序言中的标题字段：

14.2

描述

序言中的描述字段：

14.3

EIP编号

当通过编号引用 EIP 时，请写上带连字符的 EIP-X，其中 X 是 EIP 的分配编号。

14.4

RFC 2119 和 RFC 8174

我们鼓励 EIP 遵循 RFC 2119 ( ) 和 RFC 8174 ( ) 的术语，并在规范部分的开头插入以下内容：

本文档中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”根据 RFC 2119 和 RFC 8174 规定进行解释。

15

历史

本文档主要源自 Amir Taaki 的比特币 BIP-0001 ( )，而后者又源自 Python 的 PEP-0001 ( )。 很多地方的文字都是简单的复制修改。 尽管 PEP-0001 文本由 Barry Warsaw、Jeremy Hylton 和 David Goodger 撰写，但他们不对其在以太坊改进过程中的使用负责，也不应打扰他们处理与以太坊或 EIP 相关的技术问题。 请将所有评论直接提交给 EIP 编辑。

16