以太坊都这么堵了，Eth 2.0 在干嘛呢？
作者 | Danny Ryan
译者 | 核子可乐
策划 | 褚杏娟
自 4 月底以来，以太坊网络变得非常拥挤。
数据显示，以太坊网络上的平均燃料价格自 5 月初以来上涨了三倍多，在过去几天平均上涨了 30 Gwei。EthGasStation 表示，这样导致的结果是发送一笔简单的 ETH 交易平均要收取 0.16 美元的费用，这还是尽可能少用燃料方式下的价格，ERC-20 令牌传输和智能合约呼叫的成本可能是这个数字的好几倍。
费用增加已经对游戏 DApp 产生了重大影响。DappRadar 数据显示，5 月份，游戏类 DApp 活跃度大幅下降，而其他类型 DApp 则略有增长。
以太坊网络拥堵的原因归根到底还是目前的网络无法支撑起日益增大的交易量。而 Eth 2.0 作为一套可扩展的权益证明基础架构，在即将到来的升级中，区块链协议从 PoW 转向 PoS 共识机制，引入可扩展性、安全性和性能等方面的提升。目前 Eth 2.0 的进展如何呢？以太坊 2.0 协调员 Danny Ryan 日前发文详细介绍了目前 Eth 2.0 的最新发展和各项计划。
目前团队正在也在努力推出阶段 1，代表即将达成大量共识。预计将初步启动 64 个分片，且系统的总可用数据约在每秒 1 到 4 MB 之间。
过去两年的阶段 0 中， Eth 2.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 工具代表着前所未有的商业机遇。大家可以在这里挖掘价值，并获得真正的成功。
以下是当前正在开发的方向，更多工作也在推进当中：
资源管理器: Beaconcha.in , Etherscan , Eth 2.0stats
网络工具: Prrkl , Rumor , Pyrum , Stethoscope
密钥库与钱包: ethdo , deposit cli , EIP 2335 及其他新标准
API 设计与 原型绑定
Slashing 检测: Prysm “hash slinging slasher”
以下是部分开放工具的创意示例：
Eth 2.0 验证程序警报：提供一项服务，可在节点验证程序未达到最佳性能时向节点操作员发出警报。
验证器余额跟踪：通过跟踪验证器的保证金过程，在现有以太坊与 Eth 2.0 资源管理器间架起桥梁。
通过代理保护验证器：使用代理跟踪验证器消息，确保您的客户端不会发送不安全消息。
在目前的以太坊客户端（例如 geth 等）当中，几乎所有复杂性都体现在对用户级活动的处理当中——包括交易池、区块创建、虚拟机计算以及状态存储 / 检索等等。协议中真正的核心共识（工作证明）反倒相当简单。大部分复杂性都由核心协议之外的复杂硬件进行处理。
另一方面，Eth 2.0 客户端则具有全面共识性。在权益证明与分片中，大部分复杂性被归入协议当中，用以实现共识的可扩展目标。这种关注点的差异，使得 eth1 与 Eth 2.0 客户端能够完美匹配。
目前，geth（EF）与 TXRX（ConsenSys）团队的成员正在对二者进行合并。这项工作的具体内容包括：
定义 eth1 与 Eth 2.0 客户端之间的通信协议；
向 eth1 客户端添加可通过该通信协议进行控制的共识引擎；
对 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 目前工作中，遇到的挑战主要是要引入过多的验证器、分片和客户端。
分片机制的关键在于共识参与者（即验证器）必须以随机抽样的形式加入委员会，并对协议中的特定部分（例如分片）进行验证。如果特定协议中包含足够的验证器，那么即使攻击者控制的参与者数量达到最高（例如全部验证器中的 1/3），后者在数学意义上仍然不可能控制委员会并破坏整套系统（成功的几率一般在 1 / 2^40 左右）。为了达成这个目标，团队需要对系统进行设计，保证用户能够使用消费级计算设备（例如笔记本电脑甚至是旧手机）充当验证器（各验证器将被分配给系统中的各个子部分，并单一设备的计算资源足以完成对该子部分的验证）。
正是这样的设计思路，让分片机制既功能强大又难于实现。首先，我们必须拥有充足的验证器以保证随机抽样不受恶意人士控制。换句话说，eth2 天然要比大部分其他权益证明协议具有更多的潜在验证器，而这将在流程中的各个阶段给系统带来挑战——包括共识机制的研究与规范制定、网络、资源消耗以及客户端优化等等。每新增一个验证器，都会在系统的各个步骤中带来系统负载，这些影响因素显然需要得到重视。
除了验证器过多，另一项基本决策同样提升了构建难度。在以太坊中，团队希望在增强可扩展性的同时，尽可能降低对去中心化原则的影响。基于这个理念，团队必须要建立起分片共识机制并借此将系统拆分为一个个体量较小的可验证区块。设计并实施这样的共识机制将极为困难。
强调自身的协议属性是以太坊核心宗旨之一。以太坊代表着组成协议的抽象规则集，而非这些规则集的任何特定实现。为此，以太坊社区在建立之初就鼓励用户们开发出各类客户端实现方案。
今天的以太坊主网上，大家可以看到 besu、ethereumJS、geth、nethermind、nimbus、open-ethereum、trinity 乃至 turbo-geth 等等。而在 eth2 当中，又有 cortex、lighthouse、lodestar、nimbus、prysm、teku 以及 trinity。
多客户端范式具有以下几项重要优势：
多种客户端的存在，意味着社区可以对思路、算法以及架构做出更广泛的探索（每种客户端都有着自己的方法与观点）。
不同客户端通常有着不同的设计目标。随着时间推移，用户与应用程序的多样化程度也将同步提升。
目前以太坊主网上有着多种生产级客户端，大规模攻击虽然能够击倒任何单一客户端（例如 DoS 攻击），但却无法彻底淹没所有客户端。
每种客户端都是通向编程语言社区的门户。使用特定语言的客户端热情邀请该语言的用户们前来，尝试进行实验与创新。
但客户端过多，同样会带来以下负面影响：
规范与测试必须严格而慎密，避免主网发生意外分叉。如果该协议只有一种实现方式，则该实现将成为新协议。在单客户端的情况下，一旦网络上出现任何形式的共识“错误”，那么错误将成为协议中的现实。虽然这可能损害了以太坊的纯粹性，但也消除了意外分叉的风险。为了解决这个难题，团队将在主网上保持着健康的客户端分布（例如，单一客户端的节点 / 验证器总量绝对不会超过总数的 1/3）；这样即使单一客户端出现共识问题，网络仍可保持正常运行。
与单一客户端相比，协调 N 个客户端必然带来开销的线性增长，甚至在某些情况下引发开销的平方增长（N^2）。团队采用一系列技术来减少这种开销——包括共识测试套件（网络测试套件也即将推出），但这种开销只能削减、永远不会彻底消失。
参考阅读：
https://blog.ethereum.org/2020/06/02/the-state-of-eth2-june-2020/
InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员