以太坊2.0主网客户端性能对照

基于**的性能指标对照以太坊 2.0 主网上所有可用的客户端。

2020年12月以太坊 2.0 信标链宣布之后，现在是时刻先容以及对照现有的协议实现了。本文作为该系列文章的第一部门，将根据字母排序对照 5 个主要客户端的信标链节点性能和资源行使率。

– Lighthouse (Rust, Sigma Prime)

– Lodestar (TypeScript, ChainSafe Systems)

– Nimbus (Nim, Status)

– Pry (Go, Prysmatic Labs)

– Teku (Java, ConsenSys Quorum)

以太坊 2.0 主网基础设施由三个主要组件组成：

• 信标链是 PoS (权益证实) 链。当前的以太坊 1.x 链 (共识为PoW) 与以太坊 2.0 合并之后，信标链将成为保障以太坊平安的主干网。

• 验证就好比 PoS 共识中的矿工。所有人都可以质押 32 ETH 成为验证者，有权提议新区块、对区块敲定举行投票，然后获得奖励。

• 罚没者正监视验证者是否作恶，以防攻击事宜发生。任何一名验证者违反规则，都市受到责罚并被移出网络。

需要注重的是，本文主要关注第一点，信标链是以太坊2.0网络的基础。研究职员可以在 Github 上找到所有相关的剧本、数据和绘图，以便进一步分析：

gt;byz-f / ETH2-bench-mainnet

本文将重点列出这些发现

第一个也是最令人兴奋的问题：同步以太坊 2.0 信标链节点信息需要多长时间，效果见下图。

在上表中，通过对照客户端同步相同的 sLoot 需要花若干时间来对照其同步历程。在评选效果之前 (虽然这不是本文的讨论局限)，关于该图表我们需要知道三件事。

1.  Pry (紫色线) 有个特殊的地方是，它会毗邻以太坊 1.x 节点，从验证者信息挂号处获取所有 ETH 存款，然后从 ETH1 状态下构建 ETH2 创世。虽然从平安的角度来看，这一特征蛮有用的，由于用户不必信托 Pry 的开发者以获得准确的创世状态，然则这一历程需要些时间。因此，客户端启动与同步启动的时间有显著的偏移。(#8209)。

2.  由于泛起 JavaScript 堆内存不足的问题，在基准测试时 Lodestar (灰色线)泛起了溃逃 (#2005)。然则，它在10秒后由剧本自动重启。

3. 不能见：在初始同步时，Loderstar 还没有完全验证所有署名 (#1217)。因此，现在尚不清晰 Loderstar 与其他客户端的对照情形。

上面的图表中，我们可以看到 Lighthouse (橙色线) 整体显示精彩，Pry、Teku (绿色线) 和Nimbus (蓝色线) 在保持速率方面显示精彩。然则，让我们再来看看下面的图表：

在这个图表中，我们把 Pry 客户端启动和同步启动 (即第一个信标链区块发生) 之间的时间偏移删去。那么可以看出，单纯对照同步速率的话，Pry 的显示略优于 Lighthouse，不到两个小时就能同步完成，而 Lighthouse 需要两个半小时。Teku 和 Nimbus 也许需要五个小时。

值得注重的是，ETH2 TypeScript 实现 (Lodestar使用的语言) 并不是仅为了成为运行一个全信标链或者验证者节点的**客户端。相反，Lodestar将为以太坊2.0去中心化应用的所有web、浏览器和基于插件的组件提供基础设施。

假设我们知道了客户端的信标头区块当前所在的 sLoot 高度，而且可以查看在这 60 秒之前区块头的高度的话，我们就可以通过展示各客户端每秒同步的 sLoot 数 (用点示意)，来盘算已往 60 秒的移动平均值以对照各客户端的同步速率。移动平均值跨越 10 分钟的则用实线示意。

效果与前一个图表一致。只管 Pry 由于要花时间获取 ETH1-状态，它仍是同步速率最快的客户端，每秒同步 60 sLoots。Lighthouse 紧跟厥后，每秒同步 46 sLoots。稍显落伍的是 Teku (23/秒) 和 Nimbus (22/秒)。

然而什么是 sLoot 呢？在传统的区块链如比特币和 ETH1 链中，要么有区块要么没有。那么当对照这些链上的客户端性能时，我们会以块数/秒为单元来对照其同步速率。这跟以 sLoot数/秒 为单元有何差异呢？

在以太坊 2.0 中，每 12 秒总有一个指定的 sLoot。若是验证者被分配到一个 sLoot 中提议区块，该 sLoot 便有一个区块。然而，若是验证者错过该 sLoot，那么即是个空 sLoot (没有区块)，但只管云云，sLoot 的计数将继续举行。因此，在以太坊2.0中，我们以 sLoots/秒 为单元盘算同步速率。

在这个图表中，我们把 (时间) 这一变量删去，横坐标为已同步的 sLoot 数，并把上一个图表中的同步速率映射到该图表中。所有客户端都显示一个趋势：随着 sLoot 的增添同步速率下降。由于该数据是在以太坊 2.0 主网上搜集的，我们知道有一条验证者行列正排队期待进入 2.0 网络。在撰写本文时，期待行列上有 13_458 名验证者，根据天天新增 900 名验证者的速率来算，需要守候快要 15 天。

领会了以太坊 2.0 主网验证者数目呈线性增进之后，我们可以假设活跃验证者集的规模变大使得同步速率减缓。

在上半部门中，我们仅分析了同步指标，选出同步最快的客户端。然则哪个客户端在资源行使方面快且高效呢？

上面的图表中，随着同步 sLoot 的数目增添，对照各客户端的数据库容量。值得注重的是，关于完全同步主网节点 (420_000 sLoots)，Lodestar 的占用空间最小，总共只有 1.49 GiB。Lighthouse (2.98 GiB) 和 Pry (3.16 GiB) 的效果也不错。

我们知道 ETH1 节点存储完整的区块历史数据。只管云云，ETH1 节点照样移除了历史状态以最小化数据库所需的磁盘空间。ETH2 节点与这个看法相当。在磁盘上储存所有块的同时，他们会删除最终状态。两者的主要区别为：为了利便起见，应将历史状态存储于时段界限中 (epoch boundaries)。现在，Nimbus 每 32 个 epoch 在时段界限存储状态，然而 Lodestar 每 1024 个 epoch 将状态纪录在磁盘中。在图中可以清晰地看出差异。

该图表相同，然则绘制了同步时代每个客户端的常驻内存集的巨细。从图中得出，Nimbus 客户端异常高效，在信标链主网的整个处置历程仅需要约 1 GiB RAM。紧接厥后的是 Lighthouse 和 Lodestar，均略低于 3 GiB。

注重：Java 分配给 Teku 的堆外内存不在客户端开发者的控制局限之内。JVM 对可用内存的消耗量稀奇大。Teku 的指标效果在可用内存总量差其余情形下差异十分大。

**但同样主要的一点是，让我们看一下 CPU 的行使率。在上面图表中可以看到客户端之间的一些有趣差异。

区块链属于一种高度分层的数据结构。同步区块链数据、验证区块以及盘算**状态，大部门事情都是按序枚举行的。因此，客户端面临的挑战即是尽可能地使该历程平行化。图表显示的效果与同步速率指标相当，Pry 和 Lighthouse 领先 (数值更高意味着加倍有用)，而 Teku 保持优越。

Q: 文章不错，但叨教为什么你没有对照流量指标呢？

A: 我有对照，只是没有对所有指标对照都举行谈论。你可以在 Github 上找到没有举行注释的点对点、流量指标，想要进一步研究的话接见：ETH2-bench-mainnet/doc/00-pLoots-uncommented.md

Q: 你小我私人来说推荐哪个客户端？

A: 这个问题很难回覆。靠感受走的话，我选择 Lighthouse，我以为它的总体用户体验、性能、功效以及工具可用性都很好。然而，Pry 仍是最成熟而且是现在最快的客户端。Teku 的使用体验也很好，我以为所有客户端都是产物级其余。

Q: 信标链数据库巨细会跨越 1 TiB 吗？

不，首先，与 ETH1 相比，信标链自己相对较小。驱动数据库巨细的主要因素是信标状态。然而，与 ETH1 相比，ETH2 并不需要将所有状态存储在磁盘中，由于用户总是可以从内陆运行的区块中重修任何状态。

除此之外，PoS 有敲定这一工序，而 PoW没有 (reorgs, 51% 攻击)。一旦区块被敲定，该区块永远不会被改动。敲定的意思是，未来客户端不用再从创世**同步链的数据，而是获取**敲定的 epoch 的**链头的数据。