BTCV高分资讯 > 数字货币 > 硬核,我们在以太网2.0 Medalla测试网络中运行了

硬核,我们在以太网2.0 Medalla测试网络中运行了

作者:高分资讯来源:高分资讯 数字货币 2020年09月29日

拥有少量ETH的普通用户只需要4核8G云服务器就可以顺利运行信标链和认证节点,而专业化的PoS挖掘池需要更高的配置来保证更高的阻塞率。

原标题:《测试了一下以太坊 2.0,硬核的那种》

作者:王泽树

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

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

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

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

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

测试环境:我们用geth搭建私有的ETH1.0网络。像开放测试网络Rinkeby或goerli一样,我们使用“小团体”权威证明算法,因为它比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 Medalla  测试网运行了 14 个测试用例

表1

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

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

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

图1

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

图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 Medalla  测试网运行了 14 个测试用例

图3

另外,在现阶段的测试中,对磁盘I/O性能和外网带宽的要求都很低,可能是由于专网的原因,具体对应的性能要求需要在ETH2.0官方测试网络中进行测试。

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

在测试指标的测试过程中,我们会收集每个实例服务器的CPU、内存、磁盘IO、网络带宽IO、要发出的块数、要见证的实际块数、要见证的实际块数等指标。

测试用例以下是我们的测试用例:

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

表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 Medalla  测试网运行了 14 个测试用例

表3

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

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

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

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

表4

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

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

表5

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

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

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

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

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

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

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

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

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

表6

Beacon Chain Node

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

Validator Node

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

另外,在生成验证器密钥文件方面,我们使用了一个推荐的python命令行工具,生成密钥的效率相对较低。多核机器上只需要一个核,生成2000个密钥对大约需要2.5个小时。另一方面,Validator Node导入密钥对也是单核执行,2000个密钥对的导入时间约为40分钟。

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

后续测试方案和需要优化的步骤在本轮测试中,以下几个方面占用了更多的准备时间:

验证者密钥对生成部署存款合同验证者节点导入密钥对。在后续方案中,计划对上述步骤进行优化,提高测试效率。

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

在同一区域添加多个测试用例,比较是否是区域差异造成的;部署多个ETH1.0节点,使信标链节点能够顺利连接ETH1.0网络,减少影响;增加同区域对比测试,增加验证器数量,控制变量,简单对比验证器数量的影响。在统计数据方面,考虑增加更多维度,比如考虑证人覆盖的距离等。所以请参考这篇关于证人效率的文章。

试题总结GRPC 数据量超过默认大小

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

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

图4

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

Beacon chain node 无法同步

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

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

图5

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

存款金额误报不够

如果下面计算的activeEpoch太大或者存款金额不够,说明Prysm实现有问题。关于此问题,此问题已在本报告的最新版本中得到解决。

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

图6

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

埃瑟伦

以太网的开放分布式区块链应用平台提供分散的虚拟机,并通过其独有的加密货币以太网处理点对点合同。允许任何人在没有任何欺诈、审查或第三方监督的情况下,通过区块链技术构建和使用分散的应用程序。以太网(Ethereum)的概念最初是由Vitalik Buterin Buterin在2013-2014年受比特币的启发而提出的,旨在共同构建一个更加全球化、自由、可靠的互联网。ERC 20 ERC 20 ERC 20 ERC 721 ERC 721查看更多

标签: bitcoin vault