观点 | 到点就发车：以太坊 EIP 及升级流程改进提议

这篇文章是 Danno Ferrin 和我在 DevconV （第六届以太坊开发者大会）上的谈话的粗略记录。文章中讨论了社区在过去一年中提出的一些 EIP 流程改进建议，并且将其纳入到一个统一的框架中用来指导我们如何让以太坊更顺利地升级。我们把它称之为 “火车站模型”。

 

摘要

 

我们根据过去一年来社区提出的几点建议，提出了一种协调以太坊网络升级的新方法。具体来说，我们认为：

• 升级应每年进行两次，以向社区提供明确的可预期性；
• 升级应该只包含准备好发布的以太坊改进提案（EIP），任何仍在讨论中的改进内容都应该放到下一个升级，而不应延迟当前的升级；
• 以太坊改进提案应由工作组以独立的方式制定，并且只有在完成后才应考虑纳入升级；
• 以太坊改进提案和工作组应该有一个拥护者或者代表，用来联络社区，解答社区对相关 EIP 的疑问。

如果你想更深入地讨论这个提案，请前往 EthMagicians 论坛的这个帖子。

让我们先简单谈谈以太坊的升级历史。最初的几次网络升级，包括前沿，家园，拜占庭和君士坦丁堡，有点像 1950 年代的家庭度假，爸爸妈妈会把车子行李打理好，我们会跳上后座，或许还会带上我们最喜欢的玩具，总之他们会把我们安全地送到目的地。 这是一个过去升级的简单类比，但是对于这些升级，核心开发人员编写了大部分的以太坊改进提案，而以太坊社区足够小，以至于他们可以有组织地，有计划地与社区沟通，使得分叉和升级顺利进行。

…. 但也有他们忙不过来的时候！少数那么几次，我们不得不赶着去救火。在那些场合，我们基本上是全民皆兵。无论是上海举办 Devcon 2 期间发生的网络攻击事件，The DAO 导致的以太坊分叉事件，还是君士坦丁堡升级前最后一刻发现的弱点，社区总是能团结一致修复 bug，解决问题同时让用户将他们的节点及时升级。

-一条以太坊色的瀑布-

直到现在的伊斯坦布尔升级。在开始计划升级的时候，我们已经很好地掌握了我们的工作流程，并决定更彻底地计划升级的流程。我们为升级过程的每一个阶段都设定了一个时间节点，从以太坊改进提案提出到最后主网升级都做了详细规划。在我们有所察觉之前，我们一直都处在一种以太坊瀑布模型中！

正如我们所知，瀑布模型不适用于软件开发。但是，我们还是将它用于伊斯坦布尔升级过程。我们原计划在一月份开始，花几个月的时间审议以太坊改进提案，并将 5 月中旬设定为以太坊改进提案最后的接受期限，然后花两个月完成新客户端的部署，估计结束要到 7 月中旬。做完以上所有的这些，预计 8 月中旬可以完成测试网升级，10 月中旬完成主网升级，也就是说在以太坊开发者大会两周前完成。

然而，这些计划好的时间节点有多少真正按时完成呢？只有一个，就是刚开始的时候。

很多事情在执行的过程中出现了差错。其中一个更重要的原因是，自从上次升级以来，以太坊社区已经有了很大的发展，到了开始审查伊斯坦布尔升级提案的时候，核心开发人员不得不将 30 多个以太坊改进提案打包在一起阅读，而不是只有少数几个提案需要评议！

这大大拖慢了整个流程。数量多还只是一方面，重点是它们处于完全不同的开发阶段（有些以太坊改进提案还没有合并到代码库中，而另一些以太坊改进提案已经在测试网上运行），还有一些相互依赖或相互竞争的以太坊改进提案。

-因为要在幻灯片中使用特定的字体，所以我们没法用一页把所有的伊斯坦布尔 EIP 列出来……-

当我们得到以太坊伊斯坦布尔最终改进提案列表时，已经是夏天的中期了，按照本来的计划，这时候我们应该要把客户端实现做完了。当这种情况发生时，很多人意识到这个开发过程远远不及预期，关于我们如何使伊斯坦布尔之后的柏林升级运行得更加顺畅，已经有人提出了很多建议。我们现在将讨论一些其中的建议，然后将它们合并到我们所称的 “火车站模型” 中。

-“柏林” 会天气晴好、风景明媚-

 

以太坊1.X 会尝试改变 EIP 开发流程

 

在伊斯坦布尔升级期间，第一个尝试解决开发流程问题的人是 Alexey Akhunov。他写了一篇博文（编者注：中译本见文末超链接），描述了我们可以如何通过组建工作组、使用 ReTestEth 来增加为以太坊协议改进作贡献的成员数量，同时减轻现有核心开发者的负担。在 “pre-1.x” 的改进流程中，提交的以太坊改进提案将主要由 Geth，Parity 和 Aleth 的客户端开发人员实现，在这种情况下，以太坊改进提案将由这些团队协同改进。一旦客户就以太坊改进提案的最终规范达成一致，就可以生成参考测试。Aleth 是唯一可以生成测试的客户端，因此为了生成这些测试，所有以太坊改进提案都要在 Aleth 中得到实现。EF 的测试团队随后将运行这些测试，并编写所有客户端都要运行的一致性测试。

-幻灯片上的图片取自 Alexey 的原帖-

这个过程有几个瓶颈：主要的客户端实现团队，Aleth 生成引用测试，EF 的测试团队所编写的一致性测试。为了提升工作的效率，Alexey 提出了设立工作组的想法。这些工作组将由有共同改善以太坊愿望的一部分人组成。他们可以从以太坊改进提案的早期阶段着手，帮助完善它，使其或多或少接近或者达到最终的版本。这样，客户端开发人员将看到成熟的以太坊改进提案，至少可能有一个初步的实现，大多数相关的开放式问题也已经得到了解答。

除此之外，由 EF 测试团队开发的新测试工具 retesth 将使工作组能够为任一客户端（目前是 Geth、Aleth 和 Hyperledger Besu）生成所需的 EIP 参考测试。因此，这一工作组框架不仅会使以太坊改进提案的完善过程更加去中心化，也会减少测试方面的瓶颈和压力。

 

eEIP 拥护者

 

在伊斯坦布尔升级的准备过程中，所有核心开发者开电话会议的时候，没有人谈论特定的以太坊改进提案是常见的现象，这不仅减缓了以太坊改进提案的发展进度，而且，在需要讨论一些相互依赖或相互竞争提案的时候，会明显降低整个升级过程的进度。

解决这个问题的一个简单方法由 Alex Beregszaszi 在以太坊 1.x 柏林会议上提出，即要求在以太坊改进提案讨论中要选举出一个拥护者。

-感谢 MP 和 Boris 协助举办了讨论这些事项的研讨会-

拥护者的作用是让其成为一个与以太坊改进提案相关的联络节点，他们作为以太坊改进提案的讨论协调员，负责确保升级过程顺利向前推进并确定合适的人参与到了合理的讨论中。他们并不负责所有的工作也不必然要自己去做实现，但他们应该是以太坊改进提案执行过程中的关键人物，并致力于在社区内与成员充分沟通升级的过程。

 

以 EIP 为中心的分叉

 

另一个想法，最近由 EF 团队的 Martin Holst Swende 提出，是调整以太坊网络升级过程，使其更加以 EIP 为中心。与其以升级为中心、努力确保所有以太坊改进提案在升级的各个阶段都步调一致，不如集中精力让各 EIP 成熟，并且仅为成熟、可发布的 EIP 计划升级。 如果有人想让以太坊改进提案从草稿阶段直至成功在主网激活，下面是他们在这个框架下的实现方式（引用了最初的提议，为了可读性做了一些小的修改）：

步骤 1：得到 ACD 的肯定 假定以太坊改进提案存在（步骤 0），ALCORIEDEV （论坛）将初步决定以太坊改进提案是否 “初步接受”。“初步接受”（ 或 “肯定” ）是指主要客户端和生态系统利益相关者对该以太坊改进提案持有积极的态度，愿意接受（精心编写）的 PR 以将 EIP 整合到代码库中并开始测试……但这一阶段不会指定激活的实际区块高度。

这种 “初步接受” 的状态对于像 EF、ConsenSys 甚至 MolochDAO 这样的资助协议升级的组织来说也是一种有用的信号机制。资金资助可以分为几个阶段（即 “初步接受” 之前和之后），以确保大多数资金都花在了促进主网上线的计划上。

步骤 2：执行 一旦 ACD 给出了明确的方向，开发人员和其他以太坊改进提案作者就可以着手实现，并针对客户端发布更新。 如果实现的功能被合并到主要的客户端中，这个里程碑就完成了。 步骤 3：测试案例 由于该特性现在可以在客户端中 “激活”，因此现在可以为该特性生成跨客户端测试，测试案例应该包含 happy-path 测试和 quirk/edgecase 测试，此步骤应交给不仅对该 EIP 有深入了解还对 EVM （以太坊虚拟机）有了解的人一起执行，以求最大限度的降低出错的可能性。 到了这个阶段，还应进行安全审查，审查项目应以 “安全考虑” 的名义反馈至以太坊改进提案，审查的重点还应放在寻找边缘问题和容易被忽略的问题。这一阶段的完成以测试团队的认可为标志。 步骤 4：ACD 最终接受 此时，ACD 可以再次讨论和评估以太坊改进提案的实现、副作用和测试案例等。如果一切正常，ACD 可以直接决定何时激活以太坊改进提案。 “那么，让我们在一个月后在测试网上激活这个以太坊改进提案（在区块 X 高度上），两个月后在主网上激活这个以太坊改进提案（在区块高度 Y 上）。” 所有的客户端都将在下一个版本中包含升级的内容，从现在起一周内，还可以从实际出发，通过命令行标志推迟以太坊改进提案。 如果多个以太坊改进提案同时到达步骤 4，ACD 可以决定同时推出两个或三个以太坊改进提案，除非有人担心以太坊改进提案可能有内部之间的 依赖/耦合（这可能会导致不必要的测试干扰）。

为了直观地表示这个新过程，James Hancock 绘制了一个图形，显示了一个以太坊改进提案将如何通过上面提到的每个阶段直至在主网激活。

-谢谢 James Hancock 画的这么直观清楚的图片！- 使用这个框架将允许每个以太坊改进提案按自己的步调推动，因此可以减少升级过程中争论时间和讨论的范围，同时还能减少测试团队的压力，因为这个流程相较原来更可预测，测试团队就不用在截止日前手忙脚乱地集中测试了。

 

1872 号以太坊改进提案

 

另外一个平滑以太坊网络升级过程的建议是 1872 号提案，是由 Danno Ferrin 提出。随着越来越多的公司依赖以太坊作为其基础设施的核心部分，我们应该致力于使网络升级更具可预见性。 这一提案建议以太坊采用默认的网络升级时间表，类似于微软固定周二发布补丁的做法。这样，运行以太坊节点的人就知道他们大概率该在什么时候监视潜在的升级。简而言之，这一提案建议我们这样做：

• 让主网升级默认发生在一个月的第三个星期三，最好是在 1 月、4 月、7 月或 10 月，以避开大多数主要的美国和欧洲假日。
• 如果升级不能如期推出，就推迟到下一个月的第三个星期三（如君士坦丁堡升级期间发生的情况）
• 目标是从现在开始，让主网每 6 个月升级一次
• 无论何时何地只要发生问题，即刻解决

这一 EIP 不会限制我们在意外情况发生时的处理能力，只是比较强调默认的周期性，比如 6 个月一次的固定升级，以减少市场对升级不确定性的担忧，同时减少核心开发者在升级过程中的沟通时间。 它还为我们当前的方法和 “一个以太坊改进提案，一次升级” 方法（即以 EIP 为中心的分叉方法）之间提供了 “中间地带”。

 

火车站模型

 

结合上述建议的各个部分，我们得出了一个更接近火车站运营方式的流程，而不是我们目前的 “更接近机场运营方式” 的流程。

当前，我们的升级类似于购买机票的工作方式：日期和时间是固定的，不管怎样，我们都会尽量让每个人都上飞机，哪怕会因为帮他们托运行李而延误。

我们相信，如果转向这样一种模式：人们手拿行李出现在火车站，准备出发，然后乘下一班有座的火车离开，这将有助于使网络升级比现在更加顺畅。

具体来说，火车站模型主要有四个部分。 首先，各以太坊改进提案应该独立进行。工作组可以推动提案向前推进，并且只有当一个以太坊改进提案处于准备好投入使用的状态时，我们才会给它安排网络升级。

第二，以太坊改进提案和工作组需要拥护者。这些拥护者应作为以太坊改进提案的代表和默认联络点。他们负责将提案在 AllCoreDevs 或者其他论坛与社区沟通，他们可以是也可以不是 EIP 的实际实现者。

第三，完成了什么就发布什么。当网络要升级的时候，把所有已经准备好发布的 EIP 都放到升级中。任何仍在讨论中的提案都不会安排升级。类似地，如果提案在最后一分钟出现问题，我们也会将其转移到下一次升级，而不是推迟整个升级。

第四个也是最后一个，升级每年进行两次。通过设定每 6 个月的升级目标，我们可以减少在以太坊改进提案上工作的团队的不确定性和延宕性。这样，如果某次特定的升级中没有包含某些内容，那么这些内容在几个月后的下一次升级就会出现。虽然升级日期是提前选择的，但测试网的特定升级区块是在主网升级日期之前 8-10 周确定的，而主网特定升级区块是在升级日期之前 4-6 周确定的。

.……就在这里！我们希望这种方法能够为以太坊提供更高效、更可预测和更快速的网络升级。 特别感谢 Alexey Akhunov、Alex Beregssaszi、María Paula Fernández、Boris Mann、Martin Holst Swende、James Hancock 和其他所有对改进以太坊升级方式提出建议的人。