以太坊2.0共识客户端的分析

以太坊正在进行重大升级，旨在使网络更可持续，从工作证明(PoW)过渡到股权证明，并随着数据分片的引入提高可扩展性。这一过程从2020年12月部署Beacon Chain开始，下一步称为Merge，预计将在今年晚些时候进行。在本文中，我们将探讨以太坊2.0生态系统在这次转型中取得了多大的进展，以及为进入下一阶段做了哪些准备。

为此目的，我们对在不同硬件、多个设置配置和几个用例下的以太坊2.0共识层(CL)客户端进行了全面的研究。这项研究花费了几个月的时间，消耗了近30000个CPU小时(3.4个CPU年)，在此期间我们收集了超过7.35亿个数据点，从中提取了近1.5亿个数据点，绘制了大约1000个不同的数据，以显示不同的CL客户端的表现。

实验设置

我们测量了CL客户端在三个不同的硬件平台上的表现，一个标准节点、一个胖节点和一个Raspberry Pi 4b。各类型节点的硬件配置如表1所示。

▵ 表1 硬件规格

我们还测试了默认配置以及所有主题配置以及客户端侦听 GossipSub 层上的所有子主题的全主题配置。我们测试的客户端和版本如下:

Prysm: 2.0.6

Lighthouse: 2.1.4

Teku: 22.3.2

Nimbus: 1.6.0

Lodestar: 0.34.0

Grandine: 0.2.0

整体性能分析

在下文中，我们将讨论我们的一些发现。我们收集了如此多的数据，根本不可能在这篇文章中讨论所有的细节。然而，我们将试着回顾一些最重要的问题。首先，我们绘制了不同CL客户端的CPU使用情况(图1)和内存消耗情况(图2)。我们看到，大多数CL客户端在标准节点上对CPU的使用都很合理。

▵ 图1 CPU消耗

就内存而言，它们都表现出了不同的性能。在这个实验中，Nimbus是内存消耗最低的一个。Lighthouse的内存消耗持续增加，直到客户端崩溃，我们不得不重新启动它。这可能是某种类型的内存泄漏，我们的团队与Lighthouse团队讨论过这个问题，他们正在调查这个问题。在为Teku的Java虚拟机(JVM)设置内存时，我们也遇到了一些问题，这也解释了在运行初期出现的奇怪模式。请注意，在某个时刻，大多数客户端在CPU使用和内存消耗方面开始表现不同，这一点在CPU图中用红色虚线表示。这条线标志着向Altair硬分叉的过渡。从Altair开始，CL客户端需要跟踪同步单元，以及削减条件的其他重大变化，这解释了资源消耗的变化。

▵ 图2 内存消耗

如果我们看一下磁盘使用情况(图3)，我们会注意到不同客户端需要的存储空间有很大的不同，例如Lighthouse占用的存储空间是Teku的三倍，Teku是CL客户端中占用存储空间最少的，其次是Nimbus。

▵ 图3 磁盘使用情况

在磁盘写入操作方面(图4)，大多数客户端，尤其是Prysm，在同步过程开始时，每秒的磁盘写入操作次数较多，这一数字逐渐减少，直到Altair之后趋于平稳。

▵ 图4 每秒的磁盘写入操作

这可以解释为，在Beacon链的初期，验证者的数量远低于今天，而这些时段的时隙处理速度要快得多。这两个数字是相关的，正如我们在图3中所看到的，随着网络中验证者和证明数量的增加，磁盘使用量的增长在前半段相当低，在后半段则加速。

▵ 图5 每秒磁盘读取操作次数(标准节点)

关于每秒磁盘读取操作，我们发现了一个模式，我们已经与不同的团队讨论过，但还没有完全理解这种模式。在某个时刻，磁盘读取操作会急剧增加，这在除了Teku的大多数CL客户端中都可以观察到。这并不是一个真正的问题，因为它不会影响性能，但我们仍在试图理解为什么会发生这种情况。最明显暴露出这种行为的客户端是Prysm。我们已经与Prysmatic团队分享了这一发现，他们正在调查这一模式。更奇怪的是，对于大多数客户端来说，这几乎上是同时发生的，如图5所示，大约在slot 900K。

▵ 图6 每秒磁盘读取操作(胖节点)

我们在胖节点上重复了这个实验，我们看到了几乎相同的情况(图6)，但这次的模式开始得要晚得多，大约在slot 2M附近。我们注意到这种情况也发生在Raspberry Pi上，但要更早。事实上，在拥有更多内存的节点上，这种现象发生得更晚，这使我们相信有某种内存缓存进程正在进行。当客户端达到其缓冲限制时，它开始产生大量的磁盘读取。

▵ 图7 从genesis的同步时间

在我们所做的大多数实验中，我们必须要同步CL客户端。我们同时尝试了两种方法，即从genesis同步和从检查点同步。这是一个有争议的观点，因为许多人表示，从genesis测量的同步速度不应该相关，还有人说，不管主观性多弱，从genesis开始同步仍然是该领域最常见的做法。由于我们对两者都进行了测试，所以我们给出了结果。在图7中，我们展示了CL客户端的同步速度。我们可以看到，Nimbus是所有开源CL客户端中同步速度最快的客户端。

▵ 图8 胖节点上的同步速度

我们还测试了Grandine，这是一个封闭源代码的CL客户端，它似乎在并行化共识处理的某些方面投入了大量的精力。在Grandine的高速处理中可以观察到这一点，如图8所示，这使得它的同步速度比所有其他客户端都快。请注意与磁盘写入操作类似的模式(图4)。实际上，slot的处理速度在开始时要快得多，然后迅速下降，直到达到平稳状态，这也与Beacon链开始时网络中验证者的数量较少有关。

▵图9 对等体数量

在网络带宽利用率方面，我们分析了CL客户端配对的对等体数量，我们可以看到有显著的差异(图9)。Lodestar只与25个对等体配对，而Nimbus是最灵活的，其范围在100到150个对等体之间，平均约125个对等体。Prysm显示的范围在40和60个对等体之间摇摆不定。Lighthouse和Teku也显示出非常稳定的对等策略。值得一提的是，我们对所有客户端的对等限制使用了默认配置。我们之所以选择这样做，是因为CL客户团队解释说，他们的客户端对这些数字进行了“优化”，更改它可能会影响性能。

▵ 图10 网络发送数据(MB/s)

当我们将其与网络活动进行比较时(图10)，结果与预期略有不同。Nimbus拥有最多的对等体，但比大多数其他客户端占用更少的带宽。Lodestar带宽消耗低，这与对等体数量最少的情况相符。相反，Teku占用比所有客户端更多的带宽，当启用all-topics选项时，这一点尤其明显。我们已经与Teku团队分享了这些发现，他们正在调查这种高网络活动。Teku团队报告称，自v22.5.1更新以来，CPU减少了25%，输出带宽减少了38%。Lodestar在所有主题上也显示出一些奇怪的模式，在这种模式下，它发送的数据比默认模式下要少。Lodestar团队正在调查这个问题。

▵ 图11 API响应时间

我们还研究了CL客户端在存档模式下的行为(只有四个客户端支持存档模式)。存档模式是一种配置，在这种配置中，客户端存储了许多中间状态，以便能够轻松地回答关于区块链历史上任何时间的查询。这在设置区块资源管理器或一些类似的API时特别有用。我们向四个CL客户端发送了数千个请求，并记录了它们的响应时间，如图11所示。在这方面最慢的客户端是Prysm，因为他们只支持部分标准API，所以他们将查询转换为gRPC上的另一个接口，这增加了一定的开销。到目前为止，在存档模式下回答查询的所有客户端中，速度最快的是Teku，其响应时间非常快且稳定。在与Teku团队的交谈中，他们向我们解释说，他们开发了一种新的极其快速的树状结构状态存储来快速回答查询，这对Infura团队来说尤其有趣。

▵ 图12 Raspberry Pi上的内存使用情况

最后，我们在Raspberry Pi设备上测试了客户端。在这么小的设备上从genesis同步可能需要很长时间。令人高兴的是，检查点同步工作正常，所有CL客户端在这些低功耗设备上都表现得相当好。图12显示了Raspberry Pi上CL客户端的内存使用情况。

优点和改进点

在这个详尽的评估过程中，我们发现了所有以太坊CL客户端的多个优点和改进空间。我们本研究的目标有三个方面:i)为CL客户端团队提供有用的反馈;ii)向以太坊基金会提供大量数据，以衡量以太坊2.0 CL客户端的准备情况;iii)最后但并非最不重要的是，为权益池运营商提供他们所需的所有信息，以指导有关CL客户端部署的决策。

上述评估给出了关于以太坊CL客户端在不同场景下表现的经验数据。然而，当在操作平台上部署软件时，还有许多其他方面也发挥着重要作用。请注意，其中一些方面可能是主观的，其他人可能不同意我们的结论。在接下来的内容中，我们试图涵盖其中的一些方面，并结合实测的经验数据，讨论以太坊CL客户端的优势和改进点。

Prysm

对于我们的团队来说，Prysm显然是拥有最佳用户体验的客户端。它非常易于使用并部署在默认配置上。Prysmatic团队在改善用户体验方面付出了巨大的努力。另一方面，Prysm在几个方面还有优化的空间。文档门户有待改进，搜索功能不是很直观。此外，它们使用gRPC，标准的HTTP API被重定向到gRPC，这显示出了低性能，甚至在同时执行多个请求时出现了崩溃。存档模式下的同步比其他客户端花费了更多时间。

Lighthouse

这是具有最完整API的客户端。它几乎实现了所有的Eth2 Beacon节点的API标准，这就是为什么我们用它来检查CL客户端奖励和其他相关数据。另一方面，该客户端在从Genesis同步时似乎有一些内存泄漏，而且它的存储消耗是所有客户端中最高的。应该检查内存和IO管理。

Teku

Teku似乎是最稳定的客户端之一，它具有非常完整的文档，在其中可以很容易地找到任何执行选项和命令行标志。此外，它是存储需求最低的客户端，存档模式在所有客户端中具有最快的API响应时间。然而，尽管响应时间很快，但在存档模式下同步需要很长时间(超过3周)。另外，正确设置JVM以避免内存问题并不总是那么容易。

Nimbus

Nimbus是所有平台上CPU和内存需求最低的客户端，同时也是同步速度最快的开源客户端。显然，它是更适合运行在低功耗设备上的客户端，但它在功能更强大的服务器上也表现良好。另一方面，它的编译和部署不像其他客户端那样对用户友好。另外，Beacon节点和Validator节点在相同的可执行文件上运行的这一事实可以看作是一个特性，但也可以看作是一个缺点，因为有时在保持Beacon节点活动的同时停止Validator客户端是很有用的。Nimbus团队提到，他们正在开发一个独立的Validator客户端。

Lodestar

Lodestar是最新加入竞争的CL客户端之一，该软件支持其他客户端提供的大多数功能，这确实值得称赞。此外，它还显示出相当低的资源消耗。然而，Lodestar并不总是易于编译和部署(使用Docker时除外)，文档中有多个过时的说明，比如所需的nodeJS版本等。它还是从genesis同步的最慢的客户端，而且它不提供存档模式。

Grandine

Grandine是迄今为止同步速度最快的客户端。它似乎有一个很棒的并行化策略，在从genesis同步时，它的性能肯定优于其他客户端。但是，不确定这种速度在同步后会对性能产生多大的影响。还有许多功能仍处于测试阶段。显然，这个客户端最大的缺点是它还没有开源。

结论

在本文中，我们展示了在不同条件下进行测试时所有以太坊CL客户端的多个方面。我们展示了他们的优点，并讨论了一些需要改进的地方。在所有这些实验之后，很明显，不同的CL客户端团队专注于不同的方面、用户和用例，他们在不同的方面表现出色。

也许应该强调的最重要的结论是，所有以太坊2 .0 CL客户端都能在不同的硬件平台和配置上运行良好。它们展示了以太坊强大的软件多样性，这在区块链生态系统的其他地方是很难找到的。总的来说，我们的评估表明，所有CL客户端实施团队和相关研究人员的努力推动了以太坊生态系统向更可持续和可扩展的区块链技术的迈进。