原文标题：《观点 | 一种 EIP 流程改进思路》
撰文：Alex Beregszaszi
翻译 & 校对：闵敏 & 阿剑

一句话总结：首先，我会总的介绍一下 EIP 流程及其在 2019 年的调整。然后，我会提出新的 EIP 流程，其灵感主要源于 RFC 和 W3C 流程。

自 2016 年以来，我一直在参与 EIP （以太坊改进提案）。我最初是一名贡献者，之后参与 「AllCoreDev 流程」 并承担编辑任务。

现行流程

当前的 EIP 库中包含两种迥异流程：

1. 规范（Specification）
2. 全网推行（硬分叉计划）

EIP-1 和 EIP 233 定义了这两种流程的部分内容。之后，EIP-2378 又在此基础上进行了扩展。

在 2019 年，有人提议了几处修改，其中与提案状态相关的有 4 处：

1. 引入 「Review （审核）」 状态
2. 将 「Accepted （已同意）」 重命名为 「Ready （已就绪）」
3. 引入 「Abandoned （已弃用）」 状态
4. 移除 「Deferred （已弃用）」 状态

引入前两个变更的动机相似，但是略有不同。「Review」 状态是一个全新的阶段，在这个阶段，提案并不急着实施，虽然已经有清晰的提案、可以接受更广泛的审查。「Ready」 状态只是一个小小的增量变化，语气相比 「Accepted」 更加柔和，但是仍保留 EIP-1 中的硬分叉流程。

引入 「Abandoned」 状态是为了清理很多被放弃的草案。显然，过去未使用的 「Withdrawn」 状态已经被移除。

由于 EIP-233 和 EIP-2378 发生了更改，「Deferred」 状态已渐渐变得不合时宜，已经被移除。

还有人提议移除其它关于硬分叉的状态，例如，「Accepted」 和 「Rejected」。

请注意，我不会详细解释下图中每个状态的含义。请阅读 EIP-1 以了解每个极端情况。不过，下文的 ‘提议流程’ 会给出合理的解释。」

2019 年 6 月，我们就已经深入讨论过 EIP 流程的复杂性。如果考虑到每个状态，则整个 EIP 流程（在 「Deferred」 状态被移除之前）如下图所示：

当时，我自己假设 EIP 可以从 「Last Call(最后一次征求意见)」 状态转向 「Abandoned」 状态，虽然文档里面没有这么写。

我没有提到的是，有两种流程不同的 EIP，而且并非以上所有组合都是有效的。

「核心」 EIP 的流程如下所示：

这里要特别说明的是，「核心」 EIP 直到最近才引入 「Last Call」 状态。

「非核心」 EIP 的流程如下所示： (责任编辑：admin)