编者注：本文为 Alexey Akhunov 介绍以太坊 1.x 理想工作流程的一篇文章，既总结了现有开发流程中的一些局限，也列举了新开发流程可能会面临的一些挑战。大家都知道公链治理很难，但作为外围人员，通常也并不清楚其中的流程到底是什么样的，我们能做的也只有尽可能展现他们的工作氛围，然后为值得信任的开发者争取他们应得的支持。

题目中所说的 “流程” 指的是修改以太坊规则的流程（有人会说成是“修改协议”，但是我会尽量避开“协议”这个词，免得一开始就混淆了概念）。关于规则的修改情况，下面有几个例子：

  1. 新增 EVM 操作码
  2. 更改 Gas Schedule（操作所需消耗的 Gas 比之前更多，目前还没出现过相反的情况，未来有可能出现）
  3. 取消某些规则（例如，部署合约的字节码必须超过 24 KB）
  4. 更改某些数据的含义和某些操作的作用

免责声明

我不想在行文过程中涉及太多的细节，因此下面的插图省略了一些重要的团队和人员，并且有意无意地省略了整个流程中的一些步骤。如果你觉得我遗漏了很重要的内容，请告诉我，在此先谢过了。你也可以在我给出的流程上进行修改，重新发布你自己的一版！

我个人总结的流程

网络中的人产生了修改（不一定是改进）以太坊的想法，于是写了 EIP （以太坊改进提议）。大多数想法到这一步就没下文了。

如果三个客户端实现团队之一注意到了一些 EIP，就会把它们挑出来创建原型，并做出进一步评估。我在图中列出了三个实现团队，每个都有其特殊性和重要性：

  1. Parity ——第二大常用实现（根据网络中的节点数量来看），不过矿池明显用的最多。
  2. Geth (go-ethereum) —— 第一大常用实现（根据网络中的节点数量而定）。
  3. Aleth (原生 C++ 实现) ——目前唯一一个能够“生成”共识测试的实现。

简而言之——如果上述三个团队有意向（并且有时间）为某个 EIP 创建原型，这个 EIP 就有可能实现。

在拜占庭硬分叉（2017 年 10 月）到君士坦丁堡升级（2019 年 2 月）这段时间内，客户端实现必须完成大量工作，确保其性能能够负担增多的交易量和状态量。这可能就是君士坦丁堡升级实际上没有做出什么重大改变的原因之一，因为这需要投入大量研究和/或实现（例如，账户抽象化和区块哈希扩展）。

原型实现通常会让 EIP 变得更加细化和完善，有时候会因为出现问题而被放弃。原型实现还会降低创建测试向量（test vector）——描述有可能改变规则的各种场景——的难度。

测试向量需要按照特殊格式编写，有时被称为 “filler test”。这里有一个 例子 （CREATE2 测试之一）。

我之前说过 Aleth (C++) 实现比较特殊。原因是，在 filler test 编写完成之后，将其转化成共识测试的工具（也就是 “testeth”）是与 Aleth 紧密耦合的。整个过程等于是让 EIP 在 Aleth 中的实现变成了实现范例。以这种方式生成的共识测试也可以在大多数其他实现中运行。

测试团队也很特殊，因为大多数测试向量都是他们创建的（EIP 提议者通常不会提太多这方面的东西）。

虽然整个流程到这还没结束，但我就不画示意图了。客户端实现使用共识测试（在它们自己的实现、参考实现以及技术规范中）找 bug 。共识测试也用来驱动 “Hive” 中的测试。这里面还涉及到模糊测试（不过我对这个设置不太了解）。然后还有测试网（这就需要另外写一篇文章了）。

以太坊 1.x 或将采用的流程

以太坊 1.x 不会让已有的实现团队按照主观意愿来处理改进提议，可能会专门创建一个工作组来负责这块。虽然并没有降低其中的难度，毕竟要找到愿意处理这些改进协议的开发者、愿意为此付费的人等等。不过，这个流程至少划分了职责，并且增强了流程的可扩展性。

工作组选择一个成员最熟悉的客户端实现，然后通过这个客户端实现来创建一个实现范例，再由这个范例实现产生出 EIP（比现行流程下的 EIP 优质的多）和测试向量。目前，这个步骤已经可以实现。

目前尚未实现的是如何通过非 Aleth 参考实现来生成共识测试。不过，我们希望能够将新工具 “retesteth” 集成至最流行的实现中。最初，我想过要为此专门创建一个工作组，不过后来意识到不如直接做来的快一点。点击 此处 ，查看我们目前正在进行的开发工作（我们也在对 retesteth 进行修复）。

获取人力和资金支持

我们如何为这些工作组找到成员呢？如何为工作组寻求资金支持？这些都不是小问题，但是我们尚未找到答案。我认为目前主要面临两大挑战：

  1. 我们的人才来源非常有限，可能是因为我们的 “核心开发” 在外人看来有点像是黑暗艺术。我认为应该加强自我描述和用户教育。后面我会另外写一篇文章（不会在本文展开）。
  2. 我们需要从不同的角度来看待资金支持，一方面是持续资助实现团队的工作，另一方面是资助更多具体的临时性方案。还需要解决一些问题。例如，应该将（开支方面的）“尽职调查” 和监督控制在什么程度内？谁可以决定工作组是否完成交付？诸如此类。这些问题都是可以解决的，之后会另外写一篇文章（不会在本文展开）。

Ethereum 2.0 会采用什么样的流程?

以太坊的进化之路原本是 PoW -> PoW/PoS 混合机制 -> PoS -> 分片，却在 2018 年 6 月全部推翻重写。我怀疑这一历史性转折的原因之一是以太坊的改进进程太过缓慢，无法赶上 Casper 和分片的开发进度。

很多系统在演化过程中都会出现这种转折点。通常是因为原有系统不堪应对挑战（例如，现有的客户需求），或是维护原有系统的工程师开发进度不给力。（从我有限的经验来看）我认为只有才满足下面至少一种（最好两种）条件的情况下，这种转折才能获得成功：

1）需要比原有开发团队更富有经验和能力的团队来执行新的进程

2）开发和改进进程经过了彻头彻尾的改变，能够解决原定进程所面对的挑战

我认为，以太坊 2.0 尚未与新的开发和改进计划接轨，不过我们不知道这个流程实际会是什么样子。因此，我猜想人们可能还是会回归以太坊 1.0 的流程。然而，这正是以太坊 2.0 想要避免的。

我想说的是，人们都低估了投资以太坊 1.0 的开发和改进进程的重要性，只有这样才能为以太坊 2.0 打下一个良好的基础。当然了，要是以太坊 2.0 一开始就完美无缺，不需要改进的话，这些就都不成问题了:)

结语

我认为以太坊 1.x 不仅仅是一组路线图，而是以更高效和包容的方式改进以太坊的尝试之举。这篇文章大致表述了我的想法。

原文链接: https://medium.com/@akhounov/ethereum-1x-as-an-attempt-to-change-the-process-783efa23cf60

作者:Alexey Akhunov

翻译&校对:闵敏 & 阿剑

本文由作者授权 EthFans 翻译及再出版。

相关文章