|
围绕更广泛利益相关者的网络治理互动争议才刚刚开始，而开源协作、协议标准等其它治理层级则会继续进步。 原文标题：《科普 | 以太坊治理的全景》 在本文中，我尝试归纳以太坊治理方法的不同层级。核心的概念曾在 Ethereum Magicians 论坛上发表过，也引发了一些讨论。 如果你想了解一些我的背景，你可以看看我进入以太坊社区的经历，就在本文的末尾。在以太坊社区我还是一个新手，不过我已经有很丰富的开源协作经历了，包括帮助成立 Drupal 协会以支持 Drupal CMS。 「以太坊」 一词有多个内涵：
现在我们算是有一些基本概念了，然后我们来看看治理的层级。下文列举的顺序有些粗糙，但更高层级确实会循环回更低的层级。 开源协作「开源」 实际上是一个缩写词，它也有很多意思：它可以指称使用许可的一种性质、也可以指称一种工作方式、或者一种哲学理念；我在《区块链与开源的定义》一文中讨论了它的含义。我后面写的《基于公开的同辈共同生产》使用了一个比较详细的定义，用开源来指代允许开源使用的计算机代码的管理方式：代码库管理员、未解决问题（issue）、代码参与请求（pull request）、复制（fork），以及用户和贡献者的全球社区。 以太坊百科页面上有一个 ETH1 客户端列表 3 —— 如你所见，今天大部分都是由以太坊基金会来管理的，虽然在实践上是各个团队及其贡献者自己来管理项目，都是相互独立的，虽然大家都是由以太坊基金会（EF）来支付报酬的，不论是雇员还是外包。Parity Ethereum 客户端（项目由 Parity Technologies 公司控制）以及 PegaSys Pantheon 客户端（由 ConsesnSys 公司控制）是两个例外。这两个客户端也被认为是 「主要」 客户端，因为项目还是活跃的，软件也被用来运行节点、连入主网。Status 的 Nimbus 客户端也在开发中，我们可以看到代码控制权的多样性正在增加。一份 ETH2 信标链实现的早期名单也凸显了这一点。（作者注 3：我在帮助维护这个页面，但是所有东西都是开放编辑的，而代码由 Virgil Griffith @virgilgr 维护，他在以太坊基金会的研究部门工作。）（译者注：作者的文章写于 2019 年 3 月。现在，Parity Technologies 公司已放弃了 Parity 客户端项目，Parity Ethereum 已转成 Open Ethereum 项目。） 所有以太坊客户端软件都是当成开源项目来管理的，都有数量不等的贡献者在贡献代码。当我们说 「作为开源项目来管理」 的时候，意思是说，由 issue 来表述的 bug 或功能请求可以由任何人来解决和满足，任何人都能使用代码参与请求来提交代码修复和新功能，然后由一群管理员来管理这些进程。管理员就是那些拥有代码库写入权限 以及 / 或者 能帮助管理 issue 队列的人。管理员可能是由某个组织支付报酬的，也可能是志愿者。 软件的使用许可很关键，今天大部分的以太坊技术栈都是严格 copy-left 的（译者注：copy-left 与 copyright 「版权」 相对，指的是虽然可以自由分发及使用，但要遵守一些规定，而且据此产生的后续产品也必须遵守这些规定）。这就制约了许多商业组织直接参与的兴趣 以及 / 或者 能力。另一方面，如果软件的主要版权持有者向商业组织出售了许可，那就能获得收入。这也是整个开源软件生态系统当前要解决的问题 4。（作者注 4：如果你真想好好探究一番，请看专业的软件许可律师 Kyle Mitchell 的文章，他自己就提出过许多新的许可类型。） 我在这方面的建议是迁移到 Apache2 许可，因为它是非常宽容的，也能跟商业组织兼容，也包含专利保护。 在许多方面，我们这些长期参与开源协作的人已经 「赢了」 —— 微软买下了 GitHub、致力于成为世界上最开放的公司 —— 但与此同时，开源协作的许多核心规范不再被提及，甚至开发人员也不例外。我认为我们可以做更多，我也确实希望能引导更多新的开发者变成以太坊核心技术栈的工程师，同时让 ETH2 技术栈锤炼出下一代的技术专家。 总结一下，如果你是个商人，不搞技术，那么理解围绕开源软件开发的一系列规范和流程是很关键的。开源软件不仅支撑了几乎所有区块链技术，也是今时今日运行在世界上的大部分软件的基础。 协议标准的治理以太坊升级提案（Ethereum Improvement Proposal，EIP）流程是我们用来提议并对标准达成共识的流程。宽泛地说，这就是协议标准的治理。这些标准可能应用在以太坊软件层面（即需要实现互操作软件的客户端作一些更改），也可能应用在网络层面。这个网络层，既是指以太坊主网，也包括其它运行以太坊协议的区块链。其它网络可能会跟随以太坊主网来纳入和接受 EIP （现在的大部分情况都是这种），也可能会经历一遍自己的升级流程。 我们暂且把 EIP 流程想成是主要为以太坊主网设计标准的过程。至于参与者是不是开发者，提议会不会部署到主网上，那另外再说。 你可以在 eips.ethereum.org 上看到所有已公开的 EIP。而 EIP-1 指明了核心层 EIP （会改变网络共识规则、需要大家一致同意才能部署的变更）及其它类型的 EIP 的提交及审议流程。 EIP 库中还有一种标准是针对应用层的，也叫 「Ethereum Request for Comment （ERC）」。这些 ERC 可能被分割成一个独立的代码库和流程（我自己更喜欢这种形式）。 大概来说，创建和提交 EIP 的过程是向所有人开放的，而且也很简单，当然你得知道一些 GitHub 的使用方法。也不需要你附上代码。你可以使用模板，创建一个用 Markdown 格式写成的文本，然后在 GitHub 上发起一个参与请求（pull request），然后你的文本就成了一个 EIP 草案。如果这个 EIP 的格式是正确的，那它就会被合并到 EIP 库中，该 EIP 也会有一个专门的网页，供大家讨论。EIP 的编辑有一些自由裁量权，但迄今为止，还没有出现类似垃圾邮件攻击的那种情况 —— 没有人用显然荒谬的 EIP 来堵塞这个流程。学习 GitHub 的使用以及保证格式正确已经是一个足够高的门槛了。 …… 我认为 EIP 流程运作得非常好，而且还在进步。当然，教育（尤其是对那些可以为网络增加价值的技术专家的教育）是越多越好的。 …… EIP 流程的目的就是标准化 —— 即为了确保同样的软件可以由多个团体开发出来，而且大家的软件是可以相互操作的。而且以太坊有多个客户端，这一点非常关键。实际上，这比软件的使用许可重要得多。如果有一个好的标准，那任何人都能实现它，并且知道实现之间是可以互操作的。 有一项运动才刚刚开始，就是为以太坊技术栈的不同部分安排专门的管理员和代码库 —— EVM、devp2p、JSON-RPC 接口，等等。这就意味着，有更多协作者可以一起工作，甚至能跨过以太坊主网的边界，来提升及保证以太坊的互操作性。 核心开发者协作AllCoreDev 视频会议，乃是主要客户端实现的开发人员开展合作的方法。视频会议每两周举行一次，由 Hudson Jamieson 主持，他是以太坊基金会的全职员工。 同样，核心开发者会议的议程也是作为一个 issue，公开在一个 GitHub 代码库 ethereum/PM 里的。任何人都能在 issue 页面中发表评论，表明自己有时间参会、能够提出问题或与大家分享看法。 整体上来说，整个流程旨在以技术为重点。核心开发者考虑的事情是一个特定 EIP 的技术合理性，还有更大范围内的某些 「网络健康」 属性。当然，每一个技术决策都会产生一些技术之外的影响，而这种模糊性也是许多问题的根源。 核心开发者曾经表示他们不想做非技术性的决策。因为，参与核心开发者会议的主要是沉浸在技术中的人员，他们感兴趣的是围绕全球区块链网络开发的挑战。他们不是协调专家，也不是社区参与专家。即使是开源项目的管理员，我们也没看过客户端代码变得非常活跃。 跟各客户端团队交流之后，我得到的反馈是：代码实现真的不需要花多少时间；进一步的进展受到了非技术性决策和路线图争议的限制。 核心开发者的到底使用什么流程来产生决策？嗯，有点像 EIP 流程的 「实时」 版本，只不过是每两周作一次实时讨论。我的意思是，IETF （互联网工程任务管理）风格、粗糙的共识和可运行的代码，才是这个过程的核心。最近的讨论指明需要增加一些形式 —— 要求共识和记录讨论 —— 也许是为了消除不确定性。 理解 EIP 及核心开发者审议流程的有用工具是 Dan Finlay 画的流程图。我就直接拍在这里了：
网络治理我使用 「网络治理」 一词来指代整个以太坊生态中形成的治理决策。这比 「仅仅是技术决策」 要大得多。 上述所有方法 —— 从开源协作，到协议标准治理，再到核心开发者协作 —— 往往只跟技术有关。如果你不写代码、不筹集资金及雇用开发者，那你能做的事情是很少的。 那么以太坊网络对利益相关者的参与究竟有何责任？如果 「我们」 想要更广泛的利益相关者参与，我们能怎么办呢？ 注意，什么是 「我们」？我自己会把 「我们」 定义成所有自认是以太坊生态一员的广泛人群，并关心这个人群的机能和进一步演化。目前为止，所有的互动方法都是在志愿参与、自设目标自己完成的基础上形成的（这在开源社区中是很自然的）。就我所知，整个生态为社区组织作贡献的人中，Hudson Jamieson 是唯一全职有报酬的。即使如此，他的大部分时间还是花在了核心开发者协作上。 最近的很多争议都围绕着如何理解网络治理在治理流程中的位置、如何实现网络治理、如何参与 / 如何让声音能够被听到，等问题。 一种观点是 「利益相关者应该自我组织」。我相信这一点，但我也相信，我们应该欢迎大家使用已经存在的基础设施和通道。 现在我们拥有的最小决策单元是核心 EIP：这些 EIP 会影响网络的核心功能、如果要部署这些 EIP 则主要客户端必须在技术上实现它们、这些 EIP 也必须经一个额外的提议纳入一次硬分叉中以便在网络上同步激活。这简直就是最触碰大家敏感神经的地方。…… 我不认为把网络治理放在协议标准或核心开发者协作的前面是有意义的。他们更像是同步的过程。我们作为一个技术社区，可以在指出这些即将实现的核心 EIP 的实质上做得更好，然后广泛的利益相关者团体就可以自我通知。……就我看到的情况，网络治理主要都是靠在核心开发者意识中引发质疑来触发的。因为核心开发者关心网络的健康 —— 包括不希望触发一场有争议的硬分叉 —— 他们可以大声呼吁、打破共识。不过，这可能主要是因为相关 EIP 还未实现：在这个时候说 「yes」 会更困难。 我认为，围绕更广泛利益相关者网络治理互动的争议才刚刚开始。目前来看，其它治理层级会继续进步，而除非利益相关者以 EIP 为基础提高他们的声音，这个进程还会继续下去。我很乐于通过教育、组织活动以及将技术语言翻译成非技术解读来帮助网络治理，但这不是我最感兴趣的领域（只是为了表明我的立场）。 节点运行客户端软件最终，区块链网络的去中心化还是要靠大家都能运行节点，而且任何人都能选择开源客户端软件的不同版本来运行，包括能复制客户端代码库来开发自己的客户端，或者运行一个跟大多数人不同的旧版本和补丁版本。 …… 以太坊路线图另一个在 EIP 之外的关键是以太坊的路线图。这个问题最早是在以太坊魔术师的柏林大会上被提出来的，也有越来越多的活动、在线会议在讨论长期路线图。 没有人在 「全盘控制」 以太坊那个的路线图，因为它是一再由此前所有项目共同组合而成的。 不过，有必要凸显是所谓的 「ETH 1.x」 和 「ETH 2」。 以太坊那个网络的下一个版本，缩写为 ETH2，希望完全建立在权益证明协议（而非运行工作量证明算法的矿工）上；还希望建构分片系统，就是让多个分片链来共同组成一个网络，提供大得多的网络整体吞吐量。ETH2 主要仍然是由受以太坊基金会资助的研究者来推动的。初步的实现计划分成三个阶段，没有写进 EIP 里面，现在主要是由实现者和研究员协作产生技术规范。 一开始大家说的是 ETH2 和权益证明近在眼前。现在，我认为说可能要 3 年以后才能全面实现已经没有争议了，因为在 Phase 1 和 2 阶段还有多个开放性研究问题。 与此同时，很多人的注意力也不在我们当前的区块链上了，但是，这是我们拥有的唯一一条链；在我们可以迁移、整合到另一个网络上之前，它一直都是。因此，从 2018 年 11 月布拉格的 DevCon 上开始兴起一场运动，现在是自主支撑的，要继续开发我们当前的这条链，升级成 ETH1.x。我也支持现在就做这些升级 —— 当然也要学习怎么做 —— 以便把这些知识运用到未来的链上去。 一个即将到来的根本讨论是：我们应该计划更多小的硬分叉，还是计划更少但更大型的硬分叉。现在，大家似乎更倾向于频繁但小型的分叉。想了解更多信息，请看以太坊百科的路线图页面。 如何参与？如果你看完了上面所有内容，你可能会想参与以太坊社区。 我花了大量时间在以太坊魔术师论坛上，论坛的好处是有长文段和分帖子的讨论。该论坛也变成了 EIP 讨论的一个中心 —— 因为 GitHub 的 Issue 页面不是那么容易访问，也不支持分帖子讨论。 我也组织社区的线上会议、活动，也参与标准治理，包括升级 EIP 库并让以太坊协议栈能连接更广泛的用户。 作为一个没有技术背景的人，学会 GitHub 的用法真的非常有用。Issue 和项目工具非常像一个共享的任务表或者说项目管理系统，任何习惯使用 web 应用的人都能学会。我在尝试使用 EthMagicians Issue 队列与更多人开展协作，已组织志愿者的线上会议及完成工作。 最后，有很多办法能从 Twitter 或其他社交媒体的短篇幅中解放出来，参与更长的讨论、协作并提出问题、要求问责并把事情办好（这些才是更重要的）！ (责任编辑：admin1) |
