2020年6月的ETH2.0状态（中）

2020年6月的ETH2.0状态（中）

作者：@Danny Ryan

如此多的验证器

分片的一个关键组成部分依赖于将共识参与者（验证者）随机抽样到委员会中，以验证协议的一个子部分（例如分片）。如果协议中有足够的验证器，并且攻击者的最大规模假定为1/3（比如说，控制验证器的1/3），那么攻击者在数学上不可能超过任何一个委员会并破坏系统。这使我们可以设计系统，使拥有消费类计算机的任何人（例如笔记本电脑或者甚至是旧手机）都可以成为验证器（因为验证程序被分配到系统的子部分，并且验证任何子部分都可以使用单个机器的计算资源）。

这就是使分片变得不可思议且同时又困难的原因。首先，我们必须有足够的验证器以确保此随机抽样的安全：这意味着ETH2比大多数（我认为是）其他权益证明协议具有更多的预期验证器。这在过程的每个层级中都引入了挑战——从研究到共识机制规范、网络、资源消耗和客户端优化。每个附加的验证器都会在系统的每个阶段引起系统上的负载，必须对此加以考虑。ETH2客户团队已经完成了艰巨的任务，即管理成千上万验证者的共识，以便我们可以安全有效地集成第1阶段中的许多碎片。

如此多的分片

另一个使我们难以构建的基本设计决策是，在以太坊中，我们选择获得可扩展性但又不影响去中心化性质。

如果我们不在乎用户事实上是否能够自行验证链，也不在乎保证数据实际上可用于网络，那么将区块链扩展到每秒数万个事务并不难。需要分片共识机制的复杂性，以便可以将系统分解为一口大小的可验证块。规范和实施这种共识机制是一件非常困难的任务。

如此多的客户端

以太坊的核心宗旨是以太坊首先是协议。以太坊是组成协议的抽象规则集，而不是这些规则集的任何特定实现。为此，以太坊社区从第0天开始就鼓励许多客户端实现。在以太坊主网上，现在的形式是besu、ethereumJS、geth、nethermind、nimbus、open-ethereum、trinity和turbo-geth。在ETH2中，这表现为cortex、lighthouse、lodestar、nimbus、prysm、teku和trinity.

多客户端范例具有许多重要的优点：

● 有许多客户可以对思想、算法和体系结构进行更广泛的探索（每个客户都有自己的方法和观点）。

● 客户通常有不同的设计目标。随着时间的推移，这将导致用户和应用程序更加多样化。客户端可能或多或少地专注于以下任何方面：性能、安全性、水平缩放、UI / UX、轻客户端、浏览器、资源受限的设备等。

● 由于主网上有许多生产级客户端，当其他客户端都很强大时，若碰到一个可以导致任何一个客户端崩溃的重大攻击（例如DoS攻击）都会有恢复能力。这是在以太坊历史上很早的“上海DoS攻击”中看到的，当时一系列DoS攻击能够降低安全性和均等性，但绝不会同时出现。

● 每个客户端都充当通往编程语言社区的门户。特定语言客户的基础打开，并邀请该语言进行实验和创新。围绕客户的基础工具通常会滚入该语言的强大工具和贡献者生态系统。多客户端范例增强了以太坊的引力。

这些明显的优势带来了一些困难：

● 规格和测试必须是严谨的，以避免在主网上意外分叉。如果该协议只有一种实现，那么该实现会将成为这个协议。在单客户端的情况下，如果在主网上碰到任何形式的共识“错误”，那么它将变成协议的现实。从纯度的角度来看，这不是很好，但是它消除了意外分叉的风险。为了解决这个难题，如果我们在主网上拥有良好的客户端分布（例如，没有客户端的节点/验证器总数超过1/3），即使面对一个有共识问题的客户端，网络也可以保持正常运行。

● 与仅单个客户端相比，协调N个客户端会产生线性开销，但在某些情况下可能会导致二次开销（N ^ 2）。我们采用了一些技术来减少这种开销——例如共识（即将推出网络）测试套件——但是它将始终以某种能力存在。

在过去的两年中，Phase 0 ETH2客户端已经成为非常复杂的软件，能够处理数千个节点中成千上万个验证器的分布式共识。我们目前正处于测试网阶段，并且每天都更接近启动。事实证明是这样。

我要求您在发布之前的这段时间内，离开您的舒适区并尝试多个客户。两者之间需要权衡取舍，因此您必须动手以找出最适合您的方法。如上所述，以太坊以多客户端模式运行。为了获得这种范例的好处，我们需要用户运行各种各样的客户端（以在所有类型的客户端上创建健全的分布）。

除此之外，该协议还内置了反相关激励措施。在一些极端的情况下，当一个主要的客户不小心导致验证器离线，或者犯了一个严重的错误，如果你的验证器的行为与该客户相关，那么比起您做错了事却与他人无关的行为，您受到的惩罚要大得多。换句话说，在这种情况下，运行少数客户端而不是拥有大量网络的客户端会更好。

绝对要明确——如果有多个可行且安全的客户端，您有责任运行少数客户端软件，以促进客户端软件在网络上的健康分布。

另外，不要害羞。如果您在文档方面遇到问题，请告知他人。如果看到错字，请提交PR。如果崩溃或弹出错误，请在github或客户端中报告。您是Beta版用户，在您的帮助下，我们可以为所有人提供更好的体验。

测试网

我们目前正在运行小型公共devnet，大约每隔一到两周就会重新启动一次。我之所以说“ devnet”，是因为它们首先是客户团队开发人员通过bug、优化等进行工作的工具。它们是公开的，欢迎您加入，但是要注意，它们还没有像Goerli或Rinkeby那样长期存在。由Afri Schoedon领导的最新发布是运行v0.11规范的Witti测试网。

客户团队正在积极升级到v0.12规范，该规范集成了最新版本的IETF BLS标准。从那里开始，随着我们不断扩大网络规模，在客户端上增加越来越多的负载，我们将把devnet过渡到v0.12。在有2-3个客户端可靠地启动成功的v0.12网络并以高负载运行之后，我们将运行一个更公开的测试网，在其中您将运行大多数节点和验证程序。这里的目的是创建一个长期存在的多客户端测试网，该网尽可能模拟主网（用户可以在其中可靠地练习运行节点并测试他们想要的其他任何东西）。理想的做法是将其旋转一次，并在维护网络的同时对所有故障进行分类。但是，根据故障的存在和严重程度，我们可能需要运行几次才能到达那里。

除了普通的测试网以外，我们还将提供激励性的“攻击网”，客户团队可以在其中运行稳定的测试网，并邀请您尝试以多种不同的方式来破坏它。对于成功的攻击，EF将提供ETH奖励。

（未完待续。。。）

（本文为翻译转载，仅代表原作者个人观点。原文地址：https://blog.ethereum.org/2020/06/02/the-state-of-ETH2-june-2020/） 

EOS Cannon往期好文精选

1、加密网络中的增压网络效应

2、加密资产如何打破外汇交易基础设施

3、为什么比特币可能无法在比特币标准下生存（下）

4、货币的未来可能是可自由支配的（下）

5、使用总线因素检测加密货币中的单点故障（下）

6、洪水过后的BTC（下）

7、Layer 2解决方案的投资现状（下）

EOS Cannon

社群官网：https://eoscannon.io

官方twitter：https://twitter.com/cannon_eos