硬核丨我们在以太坊 2.0 Medalla 测试网运行了 14 个测试用例

拥用少量 ETH 普通用户只需 4 核 8G 的云服务器就能平稳运行信标链和验证节点，但专业化 PoS 矿池需要更高的配置才能保证较高出块率。

原文标题：《测试了一下以太坊 2.0，硬核的那种》
撰文：王泽枢

Prysm 是优秀的 ETH2.0 的实现，也是目前 Medalla 测试网上运行最多的实现。Prysm 采用 Beacon Chain Node + Validator Node 的架构，前者负责同步区块数据，后者负责签名出块和见证。由于 Validator Node 可同时负载多个验证人，为了对其可负载验证人数量以及相关验证人部署步骤有一个定性和定量的认知，我们特安排此次测试。

测试结论

我们复刻了 Medalla 测试网，搭建 HashQuark 自己的 ETH2.0 Beacon Chain，进行了两轮测试，一共 14 个测试用例，跑了数十万计 Validator。Prsym 的实现非常优秀，对于拥用少量 ETH （几十到上百个 Validator）想参与以太坊 Staking 的普通用户而言，一台 4 核 8G 的云服务器就能够平稳地运行 Beacon Chain Node 和 Validator，但运行过程中遇到的技术问题都不是非技术人员的普通用户能解决的。

对于运行上万个 Validator 的专业化 PoS 矿池，需要更高的配置才能保证超高出块率。出块率会随着 Validator 数量的增加而减少。

我们接下来会在公开测试网 Medalla 进行下一轮测试，以更贴近主网环境，目前我们已经在 Medalla 正常运行了近 3000 个 Validator，占整个网络的 5%。

测试环境

我们采用 geth 来搭建私有 ETH1.0 网络，与公开测试网 Rinkeby 或 goerli 一样，采用 ‘clique’ proof-of-authority 算法，因为其相比 PoW 对资源需求更少。Prysm 采用测试时的最新的 release 版本。

以下测试采用的云主机部署，我们选取通用型 N 机型，CPU 平台为 Intel/Broadwell。系统采用 Ubuntu 18.04.2 LTS。geth 版本为 1.9.19-stable，Prysm 版本为 v1.0.0-alpha.24。

第一阶段初步尝试

测试方案

我们先从不同数量的验证人对服务器资源的压力进行简单测试以获得基本认知。

采用最基础的两台 ETH1.0 节点 + 两台 ETH2.0 Beacon Chain Node + 两台 Validator Node 架构搭建私网作为起始尝试方案。网络稳定运行一天为观察的时间段。

测试用例

下表为我们进行测试的概览：

表 1

测试指标

测试过程中我们收集了各个实例服务器的 CPU、内存、磁盘 IO、网络带宽 IO 等指标。

测试过程

在测试 1 中，2 核 4G 的 Beacon Chain Node 内存阶段性上升，在运行约 6 小时后，内存使用率达到 100%，导致进程出现内存不足错误被迫停止，同时 CPU 使用率也逐步提高。如下图所示：

图 1

图 2

之后，我们提升了 Beacon Chain Node 的配置为 4 核 8G。

在实例 2-5 中，依次提升验证者数量 1k-10k 来观察服务器 CPU、内存、磁盘 IO、带宽等指标数据，均无压力，也没有异常。

之后我们在不同地区部署 ETH2.0 节点，来观察不同地区的网络互联情况是否会对各指标产生较大影响，实验结果均无异常。

测试小结

根据私网测试情况来看，Beacon Chain Node 建议 4 核 8G 配置，Validator 节点 2 核 4G 的配置够用，但是在导入 key 文件时会占用 1 核 CPU，该 CPU 占用率为 100%（如下图所示），稳妥起见，建议 4C6G 的配置。

图 3

此外，在本阶段的测试中，对磁盘的 I/O 性能和外网带宽要求很低，可能是由于私网的原因，具体的对应的性能要求还需要在 ETH2.0 官方测试网中进行测试。

第二阶段对比测试

测试方案

第一阶段主要测试了不同数量的验证人对于服务器资源的压力，此外，验证者的出块和见证也是也是对于验证人很重要的指标。为此我们进行了对比测试。在同一个网络中，将不同数量的验证人部署在不同的地区来进行对比测试。

测试指标

测试过程中我们将收集各个实例服务器的 CPU、内存、磁盘 IO、网络带宽 IO、应出的块数、实际出块数、应该见证的块数、实际见证的块数等指标。

测试用例

以下为我们的测试用例：

表 2

ETH1.0 网络由三台 2 核 4G 云服务器组成，两台位于香港，一台位于圣保罗。出块时间设置为 15s。

我们分别在香港、新加坡、洛杉矶、法兰克福、圣保罗、伦敦六个地区部署了 Beacon Chain Node 和 Validator Node。各个地区的 Beacon Chain Node 和 Validator Node 通过内网连接。配置和相应的验证人数量如上图。

实例 1 和实例 2 都是 1k 验证人，区别在于 Validator Node 的配置，用于对比不同配置的验证人数量对指标的影响。

实例 3,4,5,6 增加了验证人数量。鉴于实际情况下我们不太可能将超过 10k 的验证人置于单台机器上，因此我们将测试数量停在了 20k。

各个地区的 Beacon Chain Node 与其余 node 相连。

测试网参数选择

我们先在 ETH1.0 网络上部署了 deposit 合约，生成所需数量的验证人密钥后，批量发送了存款交易。Prysm 启动时修改了以下参数 :

• MinGenesisActiveValidatorCount 设置为 8192，由于我们的测试中包含了 40k 验证人，所以能够满足；
• Eth1FollowDistance 设置为 20，也就是 ETH1.0 网络上的存款合约在 5 分钟后会被 ETH2.0 网络监测到；
• SecondsPerETH1Block 设置为 15，这与 ETH1.0 网络每个块时间设置的一致；
• MinGenesisTime 设置为 1599811200，也就是说最早在 2020-09-11T16:00:00+08:00 启动。

实际上，由于我们事先发送了所有的存款交易，满足最早启动时间设置的最小验证人数量，整个 ETH2.0 网络在 1599811207(2020-09-11T16:00:07+08:00) 启动。

数据统计和测试结果

我们额外部署了一个 Beacon Chain Node 来连接到 ETH2.0 私有网络，来查询数据。加上--slots-per-archive-point=1 的参数来持久化存储每个区块的数据，从而加快查询速度。加上--rpc-max-page-size=1000 的参数，使得我们每次可以查询更多的数据，从而减少请求次数加快总体速度。

我们选取了网络相对稳定的一段时间 ，从 75 epoch （大约 2020-09-12 00:00:00 +0800）到 1200 epoch （2020-09-17 00:00:00 +0800）采样，获取这段时间内处于不同实例中验证者的出块和见证的数据加以分析，得出如下结果 :

• 所有验证人都成功出块，无漏块情况；
• 不同地区的验证者见证情况略有差异：

表 3

这里我们定义见证率为在一段时间内被包含的见证数除以被分配到见证数。不难看出，总体来说，随着验证人数量的上升，见证率会下降。但在实例 3 中，虽然验证人只有 2k，但见证率却比 6k 甚至 10k 的见证率都要低。

为了探究导致实例 3 总体见证率异常的原因，我们统计每个实例里验证者的见证率加以分析，看是否由于个别验证者出了问题拉低总体比例。

我们将每个验证者比例按照范围划分，得到以下数据：

表 4

由于各个实例验证人数量不同，换算成比例会更加直观：

表 5

可以看到，实例 3 中大多数验证人的见证率都不高，这也意味着实例 3 应该出了问题。

为此，我们检查了实例 3 的日志，发现 Beacon Chain Node 与其它节点以及 ETH1.0 的连接并不稳定，猜测是由此导致了见证率的异常，有待后续检验。

服务器压力

在本轮测试中，我们观察到如下表的性能指标数据：

表 6

Beacon Chain Node

实例 1-5 中，Beacon Chain Node 的 CPU 使用率在 5%-10% 之间，实例 6 的 Beacon Chain Node 的 CPU 使用率约为 12%。内存方面呈现平稳增加，在 12%-17% 之间，磁盘 IO 与带宽无明显差异。

Validator Node

随着验证者数量的增加，Validator Node 的各项指标均平稳增多，可以看到，磁盘 IO 与带宽基本上正比于验证者的数量。

此外，生成验证者密钥文件方面，我们采用的是一个推荐的 python 命令行 工具，该工具生成密钥的效率相对不高，在多核的机器上只占用 1 核，生成 2000 个密钥对需要 2.5 小时左右。另一方面，Validator Node 导入密钥对也是单核执行，导入 2000 个密钥对的时间大约为 40 分钟。

测试小结

通过本轮测试，我们在私有网络中观察到，验证人数量的增加会影响节点上所有验证人的出块率，对于单个验证人来说，在最好的情况和最坏的情况下，平均每天少见证约 10 个块。出块方面在我们的测试中并未发现不同。内存与磁盘 IO 的使用率相对于 CPU 和带宽，更加明显地随着验证人数量的增加而提升。

后续测试方案和待优化步骤

在本轮测试中，以下几方面占据较多的准备时间：

• 验证者密钥对生成
• 部署 deposit 合约
• Validator Node 导入密钥对

在后续方案中，计划对上述步骤采取优化，提高测试效率。

此外，在后续测试计划中，考虑到不同地区的网络之间的稳定性及其对验证人指标的影响，可以考虑以下几点改进：

• 在同一地区增加多个测试实例，来对比是否为地区造成的差异；
• 部署多个 ETH1.0 节点，使 Beacon Chain Node 能够畅通连接 ETH1.0 网络，减少造成的影响；
• 增加单独同一地区对比测试，增加验证者数量，控制变量，单纯比较验证者数量的影响。

在统计数据方面，考虑增加更多维度，如考虑到见证被包含的距离等，可参考这篇关于 见证效率 的文章。

测试问题汇总

GRPC 数据量超过默认大小

当增加到近 4k 验证人时，Validator Node 会报错 grpc 获取的消息大小 5350532(5M) 超过最大值 4194304 （4M）。

图 4

解决方案：启动 Validator Node 时通过--grpc-max-msg-size 参数将 grpc 允许的消息大小适量调大。

Beacon chain node 无法同步

进行第一轮测试时，在网络中只存在两个 Beacon Chain Node 的情况下，容易出现两个节点之间无法同步区块的问题，两个节点都不认为对方是合适的 peers。如下图所示：

图 5

解决方案：我们目前采用清除节点的数据重新同步来解决。测试中我们发现，随着 Beacon Chain 节点的数量增多，该问题便不再发生。

存款金额误报不够

如发生下述计算 activeEpoch 过大或存款金额不够而实际已够的情况，则表示 Prysm 实现存在问题，参考这个 issue，该问题已在编写本报告的最新版本修复。

图 6

来源链接：mp.weixin.qq.com