Bitcoin Vault -比特币保险库

教程

在本文中,我了解了以太网EIP过程的改进思路

一句话总结:首先,我介绍一下EIP进程及其2019年的调整。然后,我会提出一个新的EIP过程,主要是受RFC和W3C过程的启发。

前言:从2016年开始,我一直参与EIP(以太网改善方案)。我一开始是一个投稿人,后来参加了“AllCoreDev Process”,承担了编辑任务。

当前流程

目前的EIP图书馆包含两个非常不同的过程:

规范

全网络实施(硬分叉计划)

EIP-1和EIP 233定义了这两个过程的一部分。此后,EIP-2378在此基础上得到扩展。

2019年,提出了几项修正案,其中四项与提案的现状有关:

介绍“审核”状态

将“已接受”重命名为“就绪”

介绍“废弃”的现状

删除“延期”状态

引入前两项变革的动机相似,但略有不同。“复习”状态是一个全新的阶段。在现阶段,该建议并不急于实施,尽管有明确的建议可以得到更广泛的审查。“就绪”状态只是一个小的增量变化,语气比“已接受”更柔和,但仍保留了EIP-1中的硬分叉过程。

引入“已放弃”状态是为了清理许多已放弃的草稿。显然,未使用的“已撤回”状态已被删除。

由于EIP-233和EIP-2378的变化,“延期”的地位逐渐变得过时并被取消。

其他人则建议删除其他关于硬分叉的状态,如“已接受”和“已拒绝”。

请注意,我不会在下图中详细解释每个状态的含义。请阅读EIP-1了解每个极端情况。但是,以下“提案流程”将给出合理的解释。"

2019年6月,我们深入讨论了EIP进程的复杂性。如果考虑每个状态,整个EIP过程(在“延迟”状态被删除之前)如下图所示:

当时,我假设EIP可以从“最后的呼唤”变成“放弃的”,尽管文件中没有写。

我没有提到的是,有两个EIP,流程不同,以上组合并不都有效。

“核心”EIP的流程如下:

特别是“核心”EIP直到最近才引入“最后一次通话”状态。

“非核心”EIP的流程如下:

2020年5月,我提出了一个更简单的流程:

此建议的目的是引入“审查”状态,并消除所有协调硬分叉的尝试。这样,“核心”EIP和“非核心”EIP的过程就可以统一起来。不过为了方便,我省略了协调硬分叉的部分。

这一点我们已经讨论过了。然而,同许多采用EIP进程的提案一样,这一提案没有得到推广。

争议的问题是“撤回”和“放弃”两个状态是否应该合并。在最近的几期中,这一点已经得到了明确的解释。

在电话会议中,还建议使用“活着”一词,而不是“积极的”。前者可能不是最好的选择,但听起来比后者更好。

硬分叉

我同意把硬分叉管理和标准管理这两个流程分开。现在看来很多人都是这么想的。这样可以让流程更简单流畅。

根据来自所有核心开发者大会的新消息,似乎有一个ETH 1.0规范库,专门用于跟踪和管理提案,并在所谓的“YOLO”临时测试网络上进行测试。

在我看来,即使从EIP图书馆移除了最后一个剩余的硬分叉过程,EIP-233的最初想法仍然是合理的:将现有的硬分叉记录到元数据文档中(与描述规范变更的EIP一起)

然而,人们在EIP-233的最初想法上向前迈出了一步,规则改变为尽快创建元文档来指定硬叉的名称,因为不同的客户端使用不同的名称。但是命名机制被一致认可后,这个问题就不再是问题了。

最后,EIP-233的思想再次得到扩展,扩展了规划协调过程中跟踪硬分叉的过程。幸运的是,这将在未来由ETH 1.0规范来处理。

硬分叉发生后,所有数据都记录在“硬分叉metas”中。事实证明,硬福特metas是一个非常有用的资源。

拟议流程

站在巨人的肩膀上,我们能找到的最好的资源就是RFC流程和W3C流程。虽然这两个过程涉及的规范通常比EIP大得多,但我认为我们可以从中学习。

在这里,我从W3C流程中借用了一些我个人比较喜欢的术语。然而,上图也给出了其他选项,即现有条款或建议条款。就我个人而言,我更喜欢候选人这个术语。

想法

在提交任何建议之前,在提交创建草稿的请求之前,应该有一个经过深思熟虑的阶段。我们可以讨论和评论以太网魔术师、以太网和渠道或不和谐的想法。

草稿

假设一个想法已经引起了人们的兴趣,我们应该为它创建一个基于EIP模板的草稿。只要草稿符合基本语法要求,就应该合并。

问题:对于编辑应该有多大的权限来审查提案,人们有不同的看法,目前还没有明确的答案。如果我们有一个很好的过程来消除不成功的EIP,这无疑是正确的方式合并草案早些时候。

在这一阶段,预计一小组感兴趣的与会者将讨论该草案。

“草稿”状态没有时间限制,但建议不要超过合理的时间范围(几个月)。

候选人/评审

一旦选秀足够稳定,预计不会有大的变动,就应该进入这个阶段。

在这个阶段,更多的参与者将提供反馈。此时,参与者有理由相信这个规范不会突然发生显著变化,因此他们更有可能投入时间进行评审和讨论。

这个阶段应该持续至少45天来收集反馈。

提议/最后一次通话(最后一次征求意见)

一旦参与者认为这个规范很稳定,不会被修改,就应该进入这个阶段。

在这个阶段,这个规范将被推给更多的参与者进行评论。之后规范定稿,不能修改。[除了“勘误表(kan)”,详见下文]

这个阶段应该至少持续14天。

如果需要微调,可以在不改变当前状态的情况下完成,否则必须返回“候选”状态。

特殊要求:审查结束日期字段必须包含在frontmatter中。

决赛

如果“建议”状态的规范成功通过,将被最终确定。

撤回(撤回)

除了“最终”和“活着”,其他所有的状态都可能变成这个状态。

特殊要求:以下情况可能导致“撤回”状态,但必须包括原因字段:

由作者撤回:作者在任何阶段都做出了撤销决定

因不活动而撤回:提交人在一段特定时间(180天)内没有活动。

活着(主动)/主动(主动)

EIP 1号作为注册地和其他特殊的EIP将被标记为这种状态,因为它们永远不会被最终确定。

任何新的注册文件必须经过一个完整的EIP程序,然后才能成为“活的”。

存档(存档)

虽然这不是一个州,这样,已经被撤销很久的EIP就可以被撤销,从而避免被EIP图书馆填满。单击此处了解更多信息。

过时(过时)

这不是一种状态,而是借鉴RFC的淘汰过程。这个过程引入了两个领域:

废弃者:包含废弃当前EIP的EIP号码

过时的:包含一组被当前EIP淘汰的EIP数

只有当处于“最终”或“撤回”状态时,当前EIP才能使用“作废者”字段。

只有当被引用的EIP的“废弃者”字段指向当前的EIP时,当前的EIP才能拥有该废弃字段。

这意味着被淘汰和被淘汰的EIP的作者必须达成共识。鉴于有更好的淘汰程序的提议,这种情况今后可能会改变。

勘误表(勘误表)

按照惯例,编辑可以纠正小的打字错误。

从理论上来说,任何有助于澄清规范的修改都是可以接受的,只要它不会使远的建议变得面目全非,因为小的修改可以在勘误表部分进行解释。如果需要进行重大修改,就必须消除相应的EIP,建立一个新的EIP。

备注(评论)

以下frontmatter字段已被删除,因为它们未被指定和/或使用:

*替换(由淘汰过程替换)

*被取代(被淘汰过程取代)

*分辨率

如果您需要这些字段,可以将其添加回来。

删除了以下状态:

*放弃(更名为“撤回”)

*拒绝

*接受

*被取代(被淘汰流程取代)

工具

然而,EIP面临的最大挑战是对人力的需求。

最近,旧的格式检查器eip_validator被更好的版本eipv所取代。另外,我们还启动了一个机器人来检查过期PR的问题。

在工具的帮助下,编校还是需要投入大量的人力。如果我们想使EIP进程更加顺利,我们应该使用机器人而不是真人来做大部分工作。我创造了一个新话题来讨论哪些机器人应该被引入EIP图书馆。

志愿者要不要一起实现机器人?) :)

Title