详解以太坊EIP：掌控千亿巨轮的方向舵

Fairyproof Tech ｜2022-11-01 18:01

EIP是以太坊生态中相当重要的一个组成部分，它推动了以太坊的发展，丰富了以太坊的生态，起着导向作用并扮演着风向标的角色。

在以太坊生态中，我们经常听到一个词“EIP”，比如典型的EIP-1559、EIP-20、EIP-721等。这个耳熟能详的词经常出现在以太坊发展的关键节点以及各种以太坊应用中。

那什么是EIP呢？

我们将在这篇文章中给大家作一个简单的介绍。

一什么是EIP？

EIP全称是Ethereum Improvement Proposal。它是一系列以太坊平台上推荐使用的标准和协议的统称。它所包含的具体标准和协议涉及以太坊的核心协议、客户端API、智能合约标准等。每一个EIP包含对某个标准或协议的定义。

我们所熟知的众多知名通证标准如同质通证（EIP-20）、非同质通证（EIP-721、EIP-1155）等都出自EIP提案库；我们所见证的众多以太坊发展史上具有里程碑意义的事件如对Gas机制的改革（EIP-1559）、以太坊的合并（EIP-3675）等也都基于EIP提案库中的提案标准进行。

二 EIP的种类

EIP根据其涉及的领域不同大体可以分为三大类：Standards Track EIP、Meta EIP和Informational EIP。

1 Standards Track EIP

它描述的是任何改变以太坊所有或大多数实现细节的EIP，比如对网络协议的改变、对区块或交易有效性判别的改变、新的应用规范、对应用互操作性的改变等。

一个Standards Track EIP包含三部分：设计文档、实现代码以及规范定义。更进一步，Standards Track EIP又可以被分为四个子类：Core、Networking、Interface、ERC。

Core：这类EIP指可能导致分叉的对以太坊共识的修改（如EIP-5、EIP-101等）或者对以太坊核心开发相关部分的修改（如EIP-90等）。

Networking：这类EIP指对以太坊网络通信devp2p （EIP-8）和Light Ethereum Subprotocol的修改或对whisper和swarm网络协议的修改。

Interface：这类EIP指对以太坊客户端API/RPC定义和标准的修改以及对调用方法名称（如EIP-6）和合约ABI等的修改。在EIP库中有一个[interfaces repo]库，此类EIP在被提交到EIP库以前尽量在[interfaces repo]库里进行提交讨论。

ERC：ERC的全称是Ethereum Request for Comments。这类EIP主要涉及应用层，包括通证标准（如EIP-20），命名注册（如EIP-137）、URI格式、代码库及代码包格式、钱包格式等。

在以太坊的应用开发中，很多开发者经常提到或听到的ERC就是此类EIP。比如EIP-20也被很多开发者成为ERC-20。可以说，ERC是EIP的一个子集。

2 Meta EIP

Meta EIP通常指对以太坊周边相关事物或者对以太坊本身某个流程（或事件）的改进。这类EIP也有可能提出对某个以太坊实现方式的改进，但这种改进不涉及以太坊的代码库。这类EIP通常需要社区达到共识。它不仅仅是建议，而是社区用户不得不遵循的规则。典型的Meta EIP包括对流程的修改，对用户指南的修改，对决策过程的修改、对以太坊开发工具及开发环境的修改等等。这类EIP也被称为Process EIP。

3 Informational EIP

Informational EIP主要针对以太坊的设计、以太坊社区的通用指南或信息给出改进意见。这类EIP通常不会提出新的功能或特性，它也不一定代表以太坊社区的共识或建议。因此用户或开发者可以仅将其作为参考而不必强制遵循。

三 EIP的评审流程及状态

一般来说，一个EIP从构思到被正式认可，要经历下列流程：构思（Idea）、草案（Draft）、审核（Review）、最后审稿（Last Call）、定稿（Final）、停滞（Stagnant）、撤回（Withdrawn）和动态（Living）。

构思（Idea）：这主要指作者在拟草案前对EIP的构想、组织和整理。这一状态并不会在EIP库中显示。

草案（Draft）：这是一份EIP被提交后，第一个显示在EIP库中的状态。一份符合撰写格式的EIP被提交后会被EIP编辑整理合并到EIP库中。

审核（Review）：这个状态表明EIP作者认为该EIP已经初步完善，要求相关人员对其进行审核。

最后审稿（Last Call）：这是一个EIP的最后阶段的审核。EIP编辑会为EIP设定一个最后的截止审核时间，通常是14天。这一阶段的审查如果发现EIP仍然有需要进行严肃修改的地方，则该EIP的状态会被修改为“审核（Review）”。

定稿（Final）：这是一个EIP的最后状态。一个被“定稿”的EIP即便还需要修改也无需大改，仅仅只进行一些细节方面的完善。

停滞（Stagnant）：如果EIP的状态为“Draft”、“Review”或“Last Call”并维持此状态超过6个月，则状态会变为“Stagnant”。此时，EIP的作者或编辑可以主动将其状态改为“Draft”或其先前的状态，否则该EIP会永远处于“Stagnant”状态。

撤回（Withdrawn）：EIP作者撤回其提交的EIP后，其EIP状态就会变为“Withdrawn”。一旦EIP状态变为这个状态，就无法再改变了。如果作者撤回EIP后，重新整理或修改了其想法，并再次提交，则EIP会被提交为一个新的EIP。

动态（Living）：这是一种特殊的状态。处于这种状态的EIP会被持续更新，而不会有一个最终状态。最典型的此类EIP就是EIP-1。

上面的状态可以用下图表示：

详解以太坊EIP：掌控千亿巨轮的方向舵

四 EIP的格式及内容

一份标准的EIP一般包含下列内容：

前言（Preamble）：前言的格式需遵循RFC 822标准，包含EIP的元数据（metadata）、EIP编号、标题（44个字符以内）、描述（140个字符以内）和作者信息。注意：标题和描述中无需注明本EIP的编号。

概述（Abstract）：概述通常用一小段话描述EIP的技术要点，让读者快速理解此EIP的要点、了解它要解决的问题。

动机（Motivation）：动机为可选写部分。虽然是非必要，但对某些EIP（比如要改进以太坊协议）而言，对动机的描述非常重要。它需要清晰地表述为什么现有的协议、标准等不足以或无法解决此EIP所要解决的问题。当然，如果一个EIP的动机显而易见，作者也可以忽略不写。

定义（Specification）：此部分需要从技术角度对EIP中各个特性、方法的语法、语义等进行详细描述。它需要细化到以太坊的各个客户端平台（比如cpp-ethereum、go-ethereum、parity、ethereumJ、ethereumjs-lib等）都能实现，并做到兼容和互操作。

原理（Rationale）：此部分详述“定义”的缘由和推理过程。作者最好在此部分也列举一下在构思EIP的过程中设想的其它方案以及进行的其它相关工作，比如某个定义的特性、方法用其它编程语言该如何实现等。此部分尤其要列举构思及讨论EIP过程中出现的反对意见及担忧。

后向兼容（Backwards Compatibility）：此部分亦为可选写。但对所有可能存在后向兼容问题的EIP，则此部分为必须。作者须尽量在此部分详细罗列此EIP可能引发的种种不兼容问题和可能导致的后果。此外，作者还需尽量给出解决这些问题的建议和方法。对不会引入后向兼容问题的EIP，此部分可忽略。

测试用例（Test Cases）：此部分可选写。但对要改进共识协议代码的EIP（比如Core类别），则此部分必须。测试用例可以在EIP中写成输入/输出形式比如“input/expected output”或以文件形式写为“../assets/eip-###/<filename>”。对于非Core类别的EIP，此部分可忽略。

参考实现（Reference Implementation）：此部分可选写。此部分包含了作者给出的具体的参考实现方式（比如参考代码）。它能帮助读者更好地理解一个EIP。

安全考虑（Security Considerations）：所有的EIP都必须包含此部分。作者在这部分主要应提及此EIP带来的改动可能引发什么潜在的安全问题或注意事项，并对这些潜在问题或事项尽可能给出可行的建议及措施。一个没有包含这部分内容的EIP将被拒绝，且不可能进入到“Final”状态。

版权放弃声明（Copyright Waiver）：所有的EIP都属于知识产权法规中的公有领域（public domain）。版权放弃声明必须指明相关的授权文件，使用“Copyright and related rights waived via [CC0](/LICENSE).”的表述。

上述内容为EIP作者在撰写EIP标准时需要包含的内容，是每个作者在撰写时都必须了解和熟知的。遵循这些标准写出的EIP不仅能让读者和编辑更清晰的了解一个EIP，并能够加快EIP的审核进度和提高审核效率。

五 EIP的撰写及审核涉及的相关方

EIP的撰写及审核主要会涉及两方：EIP作者和EIP编辑。

EIP作者的主要职责就是构思和撰写EIP。

以太坊是一个开源的社区，它面向全世界爱好者和开发者，因此全世界所有关注以太坊发展和开发的人士都可以向EIP库提交自己撰写的EIP。

我们建议作者在撰写EIP之前最好先梳理一下自己的想法，并在以太坊社区的论坛（比如Ethereum Magicians forum）中发帖和大家讨论自己的想法。这可以避免因提交重复的EIP而被拒绝，浪费作者的时间和精力。

当作者的想法在社区被证明大概率还未被列为EIP之后，就可以开始撰写EIP了。不过在撰写的过程中，作者一定要注意所写EIP的类别与其所需要的工作量是要匹配的。比如写一个类别为Core的EIP其工作量就比写一个类别为ERC的EIP要大得多，并且前者需要有足够多的以太坊客户端团队愿意采纳才行。EIP作者要注意社区对EIP的负面意见，有时这些负面意见很可能导致EIP仅仅停留在“Draft”阶段。

EIP编辑的主要职责是审核EIP。

他们通常要进行以下事项：

1 审阅提交的EIP。编辑会根据EIP标准中定义的各项内容检查其是否符合要求，判断该EIP是否合理及完备。如果编辑认为该EIP仍有待完善，则会告知作者进行进一步完善和修改。

如果编辑认为该EIP基本完善，则进行下一步：

2 给提交的EIP分配一个EIP编号，将其纳入EIP库，通知作者进入下一步工作。