BTCV繁华资讯 > 货币新闻 > 硬核测试以太网2.0_btcv-繁华资讯

硬核测试以太网2.0_btcv-繁华资讯

作者:_btcv-繁华资讯来源:_btcv-繁华资讯 货币新闻 2020年09月29日

摘要:Prysm是ETH2.0的优秀实现,也是目前在Medalla测试网上运行最多的实现。Prysm采用信标链节点验证节点的架构。前者负责同步块数据,后者负责签出块和见证。感谢ValidatorNode

Prysm是ETH2.0的优秀实现,也是目前Medalla测试网上最流行的实现。Prysm采用信标链节点验证器节点的架构,前者负责同步块数据,后者负责签出块和见证。由于Validator Node可以同时加载多个验证器,为了对可以加载的验证器数量以及相关验证器的部署步骤有一个定性和定量的了解,我们特意安排了这个测试。

测试结论

我们重新创建了Medalla测试网络,搭建了HashQuark自己的ETH2.0信标链,并进行了两轮测试,总共有14个测试用例,数十万个Validator。Prsym的实现非常出色。对于想用少量ETH(几十到几百个验证器)参与Ethereum Staking的普通用户来说,一个4核8G云服务器可以流畅运行Beacon Chain Node和Validator,但是运行过程中遇到的技术问题,不是技术人员的普通用户是无法解决的。

对于运行数万个验证器的专用PoS矿池,需要更高的配置来确保超高的阻塞率。阻塞率将随着验证器数量的增加而降低。

我们将在一个开放的测试网络Medalla进行下一轮测试,以更接近主网络环境。目前我们在Medalla已经运行了近3000台Validator,占整个网络的5%。

测试环境

Geth用于搭建私有的ETH1.0网络。像Rinkeby或goerli一样,使用“Clique”权限证明算法是因为它比PoW需要更少的资源。Prysm在测试时采用最新的发布版本。

以下测试采用云主机部署,我们选择的是通用的n型号,CPU平台是Intel/Broadwell。系统采用Ubuntu 18.04.2 LTS。Geth版本1 . 9 . 19-稳定,Prysm版本1.0.0-alpha.24.

第一阶段的初步尝试

测试方案

首先,我们简单地测试不同数量的验证器对服务器资源的压力,以获得基础知识。

采用最基本的两个ETH1.0节点、两个ETH2.0信标链节点和两个验证器节点构建专用网络作为初步尝试方案。观察期是网络稳定运行的一天。

判例案件

下表概述了我们的测试:

硬核测试以太坊2.0

表1

测试指数

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

测试过程

测试1中,2核4G信标链节点内存分阶段增加。运行6小时左右,内存利用率达到100%,导致进程因内存不足错误而停止,CPU利用率也逐渐提高。如下图所示:

硬核测试以太坊2.0

图1

硬核测试以太坊2.0

图2

之后我们把信标链节点的配置升级到4核8G。

例2-5中,依次增加校验器1k-10k,观察服务器CPU、内存、磁盘IO、带宽等指标数据。没有压力,没有异常。

之后我们在不同区域部署ETH2.0节点,观察不同区域的网络互联是否会对各项指标产生较大影响,实验结果均正常。

测试摘要

根据专网测试,Beacon Chain Node推荐4核8G配置,Validator node 2核4G配置就够了,但导入密钥文件时会占用1核CPU,CPU占用率为100%(如下图)。出于安全考虑,推荐4C6G配置。

硬核测试以太坊2.0

图3

第二阶段对比测试

测试方案

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

测试指数

在测试过程中,我们会收集CPU、内存、磁盘IO、网络带宽IO、应该发出的块数、应该见证的实际块数、应该见证的实际块数等等。

判例案件

以下是我们的测试案例:

硬核测试以太坊2.0

表2

ETH1.0网络由三个2核4G云服务器组成,两个在香港,一个在圣保罗。封锁时间设置为15秒。

我们已经在香港、新加坡、洛杉矶、法兰克福、圣保罗和伦敦部署了信标链节点和验证器节点。每个区域的信标链节点和验证器节点通过内部网连接。配置和对应的验证器数量如上所示。

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

示例3、4、5和6增加了验证器的数量。鉴于我们不可能在一台机器上放置超过10k的验证器,我们将测试次数停止在20k。

各个区域的信标链节点与其他节点相连。

测试网络的参数选择

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

mingenesissaactivevalidatorcount设置为8192,可以满足,因为我们的测试包括40k验证器。

Eth1FollowDistance设为20,表示ETH1.0网络上的存款合同5分钟后会被ETH2.0网络监控;

SecondsPerETH1Block设为15,与ETH1.0网络中各块的时间设置一致;

MinGenesisTime设为1599811200,也就是说最早2020-09-11t 16:0336000 08:00开始。

实际上,因为我们提前发送了所有的存款交易,满足了最早开始时间设置的最小核对员数,所以整个ETH2.0网络在1599811207(2020-09-11t 16:00336007 08:00)开始。

数据统计和测试结果

我们已经部署了一个额外的信标链节点来连接到ETH2.0专用网络来查询数据。将参数“每个归档点的插槽数=1”相加,以永久存储每个数据块的数据,从而加快查询速度。通过参数-RPC-max-page-size=1000,我们可以每次查询更多的数据,从而减少请求数量,加快整体速度。

我们选择了一个网络相对稳定的时期,从75历元(约2020-09-12 00:003:0800)到12 00历元(2020-09-17 00:00:0800)进行采样,获得了这一时期不同情况下验证者的区块和见证。

所有验证器均成功阻断,无阻断泄漏;

不同地区核查员的见证情况略有不同:

硬核测试以太坊2.0

表3

在这里,我们将证人比率定义为一段时间内包括的证人人数除以分配给它的证人人数。不难看出,总体来说,随着核查员数量的增加,见证率会降低。然而,在示例3中,虽然验证器只有2k,但见证率低于6k甚至10k。

为了探究示例3的总体见证率异常的原因,我们统计了每个示例中验证者的见证率,并对其进行了分析,以查看总体比率是否由于单个验证者的问题而降低。

我们根据范围划分每个验证者的比例,得到如下数据:

硬核测试以太坊2.0

表4

因为每个实例中的验证器数量不同,所以转换成比例会更直观:

硬核测试以太坊2.0

表5

可以看出,例3中大多数验证者的见证率并不高,说明例3应该有问题。

所以我们查了例3的日志,发现Beacon Chain Node与其他节点和ETH1.0的连接不稳定,导致见证率异常,需要后面查。

服务器压力

在这一轮测试中,我们观察到下表中的性能指标数据:

硬核测试以太坊2.0

硬核测试以太坊2.0

硬核测试以太坊2.0

硬核测试以太坊2.0

硬核测试以太坊2.0

硬核测试以太坊2.0

- Beacon Chain Node

在示例1-5中,信标链节点的CPU利用率在5%和10%之间,示例6中信标链节点的CPU利用率约为12%。内存稳步增长,磁盘IO和带宽在12%-17%之间没有明显差别。

-验证器节点

随着验证器数量的增加,验证器节点的指标稳步增加。可以看出,磁盘IO和带宽与验证器数量基本成正比。

另外,在生成验证器密钥文件方面,我们使用了一个推荐的python post-command工具(https://github.com/ether eum/eth 2.0-deposit-CLI),生成密钥的效率相对较低。多核机器上只需要一个核,生成2000个密钥对大约需要2.5个小时。另一方面,Validator Node导入密钥对也是单核执行,2000个密钥对的导入时间约为40分钟。

测试摘要

通过这一轮测试,我们在私有网络中观察到,验证器数量的增加会影响节点上所有验证器的阻塞率。对于单个验证器,在最好的情况和最坏的情况下,平均每天会少见证10块左右。我们的测试在阻断方面没有发现差异。相对于CPU和带宽,内存和磁盘IO的利用率随着验证器数量的增加而明显增加。

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

在这一轮测试中,以下几个方面占用了更多的准备时间:

验证者密钥对的生成

部署存款合同

验证器节点导入密钥对

在后续计划中,计划优化上述步骤,提高测试效率。

此外,在后续测试计划中,考虑到不同区域网络之间的稳定性及其对验证者指数的影响,可以考虑以下改进:

在同一区域添加多个测试用例,比较是否是区域差异造成的;

部署多个ETH1.0节点,使信标链节点能够顺利连接ETH1.0网络,减少影响;

增加同区域对比测试,增加验证器数量,控制变量,简单对比验证器数量的影响。

在统计数据方面,考虑增加更多维度,比如考虑证人的包含距离等。参考本文关于见证效率(https://www . provenance . io/post/defining-attitution-effective/)。

试题摘要

GRPC数据量超过了默认大小

验证器节点将报告grpc获得的消息大小5350532(5M)超过了最大值4194304(4M),当它增加到接近4k授权码时。

硬核测试以太坊2.0

图4

解决方案:当启动验证器节点时,使用-grpc-max-msg-size参数来增加grpc允许的消息大小。

信标链节点无法同步

在第一轮测试中,当网络中只有两个信标链节点时,很容易出现两个节点之间的块不能同步的问题,两个节点都不认为对方是合适的对等体。如下图所示:

硬核测试以太坊2.0

图5

解决方案:目前我们采用清除节点的数据再同步来解决问题。在测试中,我们发现随着信标链节点数量的增加,这个问题不再发生。

存款金额错报不足

如果下面计算的activeEpoch太大或者存款金额不够,说明Prysm的实现有问题。请参考此问题(https://security.feishu.cn),此问题已在此报告的最新版本中修复。

硬核测试以太坊2.0

图6

原文来源:王泽树,HashQuark社区

标签: btcv