首页>新闻>新闻详情>

观点 | 一种 EIP 流程改进思路

2020-09-20 16:16:00


一句话总结:首先,我会总的介绍一下 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 的流程如下所示:2020 年 5 月,我提议了一个更加简单的流程:该提议的目的是引入 “Review” 状态,并移除所有协调硬分叉的尝试。这样可以统一 “核心” EIP 和 “非核心” EIP 的流程。但是,为了方便起见,我略去了协调硬分叉的部分。关于这点,我们已经进行过讨论。但是就像很多在走 EIP 流程的提案一样,这个提议并未得到推进。引起争论的还有是否应该将 “Withdrawn” 和 “Abandoned” 这两个状态合并的问题。在最近的议题中,这一点已经有了明确的解释。在电话会议上,还有人建议用 “Living(生效)” 一词来代替 “Active(激活)” 。前者或许不是最佳选择,但是听起来优于后者。
硬分叉


我赞成将硬分叉管理和规范管理这两个过程分开。现在看来,似乎有很多人都这么认为。这样可以让流程变得更加简单流畅。根据全体核心开发者会议上的新消息,现在似乎有一个 ETH 1.0 规范库专门追踪和管理提案,并在所谓的 “YOLO” 临时测试网上进行测试。我认为,即使将最后残余的硬分叉流程从 EIP 库中移除,EIP-233 最初的构想依然是合理的:将已有的硬分叉记录到元文档中(跟描述规范变更的 EIP 放在一起)然而,人们在 EIP-233 的最初构想上迈开了一步,规则变成了尽快创建元文档以明确硬分叉的名称,因为不同的客户端使用不同的名称。但是在命名机制得到一致认可后,这个问题就不再是问题了。最后,EIP-233 的构想再次延伸,延伸出了在计划和协调过程中追踪硬分叉的流程。幸运的是,以后这将由 ETH 1.0 规范来处理。硬分叉发生后,所有数据都记录在 “hard fork metas” 中。事实证明,hard ford metas 是一种非常有用的资源。
我建议的流程


要想站在巨人的肩膀上,我们所能找到的最好资源是 RFC 流程和 W3C 流程。尽管这两个流程所涉及的规范通常比 EIP 大得多,但是我认为我们可以向它们取经。这里,我从 W3C 流程借用了一些我个人比较喜欢的术语。不过,上图还给出了其它选择,都是现有术语或提议术语。我个人更倾向于 “Candidate(候选)” 这个术语。


Idea(构想)

任何提案在提交以前,都应该有一个深思熟虑的阶段,再提交创建草案的 pull request(拉取请求)。我们可以在 Ethereum Magicians、ethresear.ch,以及 Gitter 或 Discord 上的频道讨论和评议构想。


Draft(草案)

假设某个构想引起了人们的兴趣,我们就应该基于 EIP 模版为其创建草案。只要这个草案符合基本的语法要求,我们就应该将其合并。问题:关于编辑应有多大的审核提案的权限,人们的观点各不相同,目前还没有明确的答案。如果我们有一个良好的流程来移除不成功的 EIP,那么早一点合并草案无疑是正确的做法。在这一阶段,预期会有一小群感兴趣的参与者对草案进行讨论。“Draft” 状态没有时间限制,但是建议不要超过合理的时间范围(几个月)。


Candidate(候选)/Review(审核)

一旦草案足够稳定,预期不会再进行重大修改,就应该进入这一阶段。在这个阶段,会有更多参与者提供反馈。这时,参与者有理由相信这个规范不会突然发生重大变化,因此他们更有可能投入时间来进行审核和讨论。这个阶段至少应持续 45 天,以便收集反馈。


Proposed(提议)/Last Call(最后一次征求意见)

一旦参与者认为这个规范已经非常稳定,不会再进行修改,就应该进入这一阶段。在这个阶段,这个规范会被推给更多参与者来征求意见。之后,这个规范就得到最终确定,无法再进行修改。【“errata(kan)” 除外,详见下文】这个阶段应该持续至少 14 天。如果需要进细微调整,可以在不改变当前状态的情况下进行,否则必须回退到 “Candidate” 状态。特殊要求:frontmatter 中必须带有 review-end-date 字段。


Final(敲定)

如果 “Proposed” 状态的规范成功通过,就会最终敲定下来。


Withdrawn(撤销)

除了 “Final” 和 “Living” 之外,其它所有状态都有可能变成这个状态。特殊要求:以下几种情况可能会导致 “Withdrawn” 状态,但是必须带有 reason 字段:
  • withdrawn by author:作者在任意阶段做出了撤销决定
  • withdrawn due to inactivity:作者在一段特定的时间(180 天)内没有任何活动。


Living(生效)/Active(激活)

那些作为注册表的 EIP-1 以及其它特殊的 EIP 都会被标记为这个状态,因为它们永远也不会被敲定。任何新的注册文件必须经历完整的 EIP 流程,然后才会变成 “Living” 状态。


Archived(存档)

虽然这不是一个状态,但是通过这种方法,可以将撤销了很久的 EIP 移除,以免堆满 EIP 库。点击此处,了解详情。


Obsolete(淘汰)

这不是一个状态,而是从 RFC 那里借鉴的淘汰流程。该流程会引入两个字段:
  • obsoleted-by:包含一个将当前 EIP 淘汰的 EIP 编号
  • obsoletes:包含一组被当前 EIP 淘汰的 EIP 编号
只有在处于 Final 或 Withdrawn 状态时,当前 EIP 才能使用 obsoleted-by 字段。只有被引用 EIP 的 “obsoleted-by” 字段指向当前 EIP 时,当前 EIP 才能带有 obsoletes 字段。这就意味着,作为淘汰方和被淘汰方 EIP 的作者必须达成共识。鉴于有人提议了一个更好的淘汰流程,这一点未来可能会发生变化。


Errata(勘误)

按照惯例,小的打字错误可由编辑修改。按理来说,任意能帮助阐明规范的修改都可以接受,只要它不至于使原提案面目全非,因为小的修改可以在 Errata 部分做出解释。如果需要重大修改,必须淘汰相应的 EIP,并重新创建一个 EIP 。


Remark

以下 frontmatter 字段被移除,因为它们未经详细说明 和/或 使用:
  • replace (已由淘汰流程取代)
  • superseded-by(已由淘汰流程取代)
  • resolution
需要这些字段的话,可以再添加回来。以下状态被移除:
  • Abandoned(重命名为 “Withdrawn”)
  • Rejected
  • Accepted
  • Superseded(已由淘汰流程取代)


工具


然而,EIP 面临的最大挑战是需要人力。最近,旧版本的格式校验器 eip_validator 已经换成了更好的版本 eipv。另外,我们已经启动了一个机器人来检查过时 PR 的问题。虽然有了工具的辅助,编辑和审校依然需要投入大量的人力。如果我们想要让 EIP 流程变得更加流畅,就要使用机器人来代替真人完成大部分工作。我已经创建了一个新的议题来讨论 EIP 库需要引入哪些机器人。有志愿者想要一起实现机器人吗 : ) : )

(完)

(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)


原文链接:

https://hackmd.io/@axic/eip-overhaul

作者: Alex Beregszaszi

翻译&校对: 闵敏 & 阿剑

你可能还喜欢:

观点 | 到点就发车:EIP 及升级流程改进提议

科普 | 什么是以太坊核心开发者(Ethereum core developer)?

科普 | 以太坊治理的全景

热门交易所

热门币种

Bitcoin
BTC+3.84%
19,378.4
Ethereum
ETH+7.41%
608.366

比特币蜘蛛BTCSpider.com是比特币新闻及数字货币信息的聚合站,每天追踪采集全球主流比特币等数字货币财经媒体、项目官网、交易平台的新鲜信息,实时更新海量资讯内容。