现在以太坊网络变得非常拥挤

以太坊都这么堵了 Eth 2.0在干嘛呢？

自4月底以来，以太坊网络变得非常拥挤。

数据显示，以太坊网络上的平均燃料价格自 5 月初以来上涨了三倍多，在过去几天平均上涨了 30 Gwei。EthGasStation 表示，这样导致的结果是发送一笔简单的 ETH 交易平均要收取 0.16 美元的费用，这还是尽可能少用燃料方式下的价格，ERC-20 令牌传输和智能合约呼叫的成本可能是这个数字的好几倍。

来源：Etherscan.io

费用增加已经对游戏 DApp 产生了重大影响。DappRadar 数据显示，5 月份，游戏类 DApp 活跃度大幅下降，而其他类型 DApp 则略有增长。

以太坊网络拥堵的原因归根到底还是目前的网络无法支撑起日益增大的交易量。而 Eth 2.0 作为一套可扩展的权益证明基础架构，在即将到来的升级中，区块链协议从 PoW 转向 PoS 共识机制，引入可扩展性、安全性和性能等方面的提升。

目前 Eth 2.0 的进展如何呢？以太坊 2.0 协调员 Danny Ryan 日前发文详细介绍了目前 Eth 2.0 的**发展和各项计划。

Eth 2.0 现状

目前团队正在努力推出阶段 1。预计将初步启动 64 个分片，且系统的总可用数据约在每秒 1 到 4 MB 之间。

Eth 2.0 的推出分为 4 个阶段：阶段 0、阶段 1、阶段 1.5 和阶段 2。

阶段 0 的目标是与遍布全球的数千个节点以及数十万个共识实体（验证器）达成共识。保证区块链有能力处理大量验证程序是这个阶段的难点。其他非分片权益证明机制往往只包含 100 或者 1000 个验证器，而 Eth 2.0 至少需要包含约 1600 个验证器，且这一数字有望在两年之内增长至数十万之多。

阶段 1 则代表即将达成大量共识。达成共识的“事物”将以分片链的形式出现，来自信标链的验证器将获得随机短期任务，借此构建并验证各分片链，并对每条链的状态、可用性以及有效性做出加密经济性承诺，**将结果返回至核心系统。

阶段 1.5 是将以太坊主网作为一个分片（属于阶段 1 中创建的众多分片之一）集成至新的 Eth2.0 共识机制当中。但与传统以太坊挖掘算法不同，这一次构建工作由 Eth2.0 验证器负责完成。该共识机制的热交换将保持较高程度的透明性，应用程序仍将保持原有运行状态。

阶段 2 将进一步添加状态与执行。具体操作可以采用多种形式。在目前的研究与原型设计工作当中，团队的主要工作就是弄清楚哪种形式更好、以及这种选择背后的细节含义。

Eth 2.0 客户端与测试网的状态

过去两年的阶段0中， Eth2.0客户端已经发展成极复杂的软件方案，能够处理数千节点中成千上万验证器之间的分布式共识。目前已经进入测试网阶段，一步步迈向**启动。

Danny Ryan 鼓励大家积极体验多客户端，不过需要在稳定与探索之间做好权衡取舍。

此外，该协议中还内置反相关激励机制。在极端情况下，如果某主要客户端无意间令验证器下线或者执行了某些后果严重的操作，而用户验证器又利用了这些操作，那么开发者将受到非常严厉的惩罚——严厉程度远超独立的负面操作。换句话说，在这样的制度之下，运行少而精的客户端才是**选择，因为客户端的增加只会提高出错几率。

需要强调的是——如果有多个安全且适合您需求的客户端，用户有义务主动选择其中的少数客户端软件以促进不同客户端在网络上的健康分布。

测试网现状

目前，以太坊网络上正在运行小型公共开发网，大约每隔一到两周就会进行一次重启。

该“开发网”主要负责客户团队开发人员的 bug 处理与系统优化等工作。开发网是**公开的，但还不像 Goerli 或者 RInkeby 那么成熟。由 Afri Schoedon 领导发布的** Witti 测试网目前运行 0.11 版规范。

客户端团队正在积极升级至 0.12 版规范，新规范集成了**版本的 IETF BLS 标准。以此为基础，以太坊团队将不断扩大网络规模、增加客户端的负载水平，并**将开发网**过渡至 0.12 版。在成功启动完成 2～3 种客户端，并在 0.12 版网络上运行部分高强度负载后，团队将开放公开度更高的测试网，开发者可以在其中运行大部分节点与验证程序。

测试网的目标在于创建一套长期存在的多客户端测试环境，并尽可能模拟主网的运行条件（用户可以在其中可靠地演练节点运行方式，并测试自己希望测试的一切）。最理想的做法当然是只对测试网进行一次启动，并在随后的网络维护期间对所有故障加以分类。但根据实际故障的情况与严重程度，团队也可能需要多次启动才能完成测试网的**上线。

除了普通的测试网之外，团队还将提供更具激励性的“攻击网”，客户端团队可以在其中运行稳定的测试网，并邀请更多参与者以不同方式开展**性攻击。一旦攻击成功，大家将得到以太币奖励。

Eth 2.0 工具现状

虽然 Eth 2.0 的工具体系尚处于起步阶段，但已经带来了不少令人兴奋的成果。工具贡献主要来自客户端代码库与客户端团队，但其他贡献来源也在展示自己的力量。为了更好地与 Eth 2.0 进行交互，理解、保护并增强 Eth 2.0 项目，整个社区有必要建立并扩展出更庞大的 Eth 2.0 生态系统。

Eth 2.0 工具代表着前所未有的商业机遇。大家可以在这里挖掘价值，并获得真正的成功。

以下是当前正在开发的方向，更多工作也在推进当中：

• 资源管理器: Beaconcha.in, Etherscan, Eth 2.0stats

• 网络工具: Prrkl, Rumor, Pyrum, Stethoscope

• 密钥库与钱包: ethdo, deposit cli, EIP 2335 及其他新标准

• API 设计 与 原型绑定

• Slashing 检测: Pry** “hash slinging slasher”

以下是部分开放工具的创意示例：

• Eth 2.0 验证程序警报：提供一项服务，可在节点验证程序未达到**性能时向节点操作员发出警报。

• 验证器余额跟踪：通过跟踪验证器的保证金过程，在现有以太坊与 Eth 2.0 资源管理器间架起桥梁。

• 通过代理保护验证器：使用代理跟踪验证器消息，确保您的客户端不会发送不安全消息。

Eth 1.0 Eth 2.0 的集成现状

在目前的以太坊客户端（例如 geth 等）当中，几乎所有复杂性都体现在对用户级活动的处理当中——包括交易池、区块创建、虚拟机计算以及状态存储 / 检索等等。协议中真正的核心共识（工作证明）反倒相当简单。大部分复杂性都由核心协议之外的复杂硬件进行处理。

另一方面，Eth 2.0 客户端则具有**共识性。在权益证明与分片中，大部分复杂性被归入协议当中，用以实现共识的可扩展目标。这种关注点的差异，使得 eth1 与 Eth 2.0 客户端能够**匹配。

目前，geth（EF）与 TXRX（ConsenSys）团队的成员正在对二者进行合并。这项工作的具体内容包括：

1）定义 eth1 与 Eth 2.0 客户端之间的通信协议；

2）向 eth1 客户端添加可通过该通信协议进行控制的共识引擎；

3）对 Eth 2.0 阶段 1 中的行为进行原型化与模拟，借此测试耦合结合。团队希望在今年夏季取得部分具体成果。

不同分片间执行与通信的现状

可跨多个分片正常执行的路径一直是个广受争议的技术难题。在这方面，团队需要回答很多实际问题，包括：

• 执行时应启用多少个分片？

• 对于其他分片，是否应该选择 EVM 或 eWASM 作为虚拟机方案？

• 我们该如何有效组织并处理跨分片交易？

• 我们需要对现有 EVM 做哪些变更，以使其支持跨分片交易？

• 执行与账户结构能否 / 应否具备通行的可扩展能力？

eWASM（EF）与 Quilt（ConsenSys）团队正在这些领域投入大量研究资源。事实证明，可行的解决方案多种多样，而目前的头号难题就是挖掘出更简单、更务实的解决办法，以便快速进行测试、建立设计原型并有针对性地做出讨论。eWASM 的 Eth1 x64 项目也正是由此诞生。

将抽象的跨分片思维引入具体规范、据此展开讨论并构建设计方案的实践方法，帮助团队在探索中取得了快速进步。DApp 开发人员在接下来的几个月中需要密切关注这方面动向。

无状态以太坊与 Eth 2.0 的关系

与 Eth 2.0 并行推进的另一项重大研究工作是“无状态以太坊”。

无状态以太坊的核心是解决状态规模持续增长的难题。在它的帮助下，参与者既能够完成区块验证，又无需在本地存储完整区块链状态。如今，以太坊状态转换函数中新增一项隐式输入：整体状态。使用无状态以太坊后，区块内部将包含必要的状态证明（见证），借此保证区块可以作为纯函数进行转换 / 验证。

对用户来说，这意味着以太坊将成为一个环环相扣但又互不影响的世界，我们只需要关注其中需要关注的一部分状态。某些网络参与者可能会存储所有状态（例如区块生成器、区块资源管理器、按需收费的状态提供程序等），但绝大多数参与者只需要掌握整体状态中的一部分。

对于 Eth 2.0，这将是一项重要的技术机制，能够保证节点与验证器成功验证并保护整体协议，同时无需在每个分片上存储完整的用户状态。相反，验证器可能选择接入某些分片的区块生成器，而基准验证器可能单纯验证无状态区块。无状态以太坊将成为 Eth 2.0 发展愿景中的重要补充，负责保证该分片协议的轻量化优势。

当然，如果事实证明无状态发展路线**不具备可行性，团队也准备了其他一些替代性选项。

Eth 2.0 的挑战

Eth2.0目前工作中，遇到的挑战主要是要引入过多的验证器、分片和客户端。

分片机制的关键在于共识参与者（即验证器）必须以随机抽样的形式加入委员会，并对协议中的特定部分（例如分片）进行验证。如果特定协议中包含足够的验证器，那么即使攻击者控制的参与者数量达到**（例如**验证器中的 1/3），后者在数学意义上仍然不可能控制委员会并**整套系统（成功的几率一般在 1 / 2^40 左右）。为了达成这个目标，团队需要对系统进行设计，保证用户能够使用消费级计算设备（例如笔记本电脑甚至是旧手机）充当验证器（各验证器将被分配给系统中的各个子部分，并单一设备的计算资源足以完成对该子部分的验证）。

除了验证器过多，另一项基本决策同样提升了构建难度。在以太坊中，团队希望在增强可扩展性的同时，尽可能**对去**化原则的影响。基于这个理念，团队必须要建立起分片共识机制并借此将系统拆分为一个个体量较小的可验证区块。设计并实施这样的共识机制将极为困难。

强调自身的协议属性是以太坊核心宗旨之一。以太坊代表着组成协议的抽象规则集，而非这些规则集的**特定实现。为此，以太坊社区在建立之初就鼓励用户们开发出各类客户端实现方案。

今天的以太坊主网上，大家可以看到 besu、ethereumJS、geth、nethermind、nimbus、open-ethereum、trinity 乃至 turbo-geth 等等。而在 eth2 当中，又有 cortex、lighthouse、lodestar、nimbus、pry**、teku 以及 trinity。

多客户端范式具有以下几项重要优势：

• 多种客户端的存在，意味着社区可以对思路、算法以及架构做出更广泛的探索（每种客户端都有着自己的方法与观点）。

• 不同客户端通常有着不同的设计目标。随着时间推移，用户与应用程序的多样化程度也将同步提升。

• 目前以太坊主网上有着多种生产级客户端，大规模攻击虽然能够击倒**单一客户端（例如 DoS 攻击），但却无法**淹没所有客户端。

• 每种客户端都是通向编程语言社区的门户。使用特定语言的客户端热情邀请该语言的用户们前来，尝试进行实验与创新。

但客户端过多，同样会带来以下负面影响：

• 规范与测试必须严格而慎密，避免主网发生意外分叉。如果该协议只有一种实现方式，则该实现将成为新协议。在单客户端的情况下，一旦网络上出现**形式的共识“错误”，那么错误将成为协议中的现实。虽然这可能损害了以太坊的纯粹性，但也**了意外分叉的风险。为了解决这个难题，团队将在主网上保持着健康的客户端分布（例如，单一客户端的节点 / 验证器总量**不会超过总数的 1/3）；这样即使单一客户端出现共识问题，网络仍可保持正常运行。

• 与单一客户端相比，协调 N 个客户端必然带来开销的线性增长，甚至在某些情况下引发开销的平方增长（N^2）。团队采用一系列技术来减少这种开销——包括共识测试套件（网络测试套件也即将推出），但这种开销只能削减、**不会**消失。

作者 | Danny Ryan

译者 | 核子可乐