硬核丨我们在以太坊 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

以太坊域名服务 ENS 全年收入接近 200 万美元

链闻消息，以太坊域名服务（ENS）在发布的全年数据中表示，自去年 10 月 1 日至今，该服务的总收入达到 5513 ETH，以当前 ETH 价格计算接近 200 万美元，其中 3982 ETH 为新注册域名收入，1531 ETH 为域名续约收入。另外 ENS 还公开了一些其他数…以太坊,ENS,以太坊域名服务

这里我们界说见证率为在一段时间内被包罗的见证数除以被分配到见证数。不难看出，总体来说，随着验证人数目的上升，见证率会下降。但在实例 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 分钟。