实例 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

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

(责任编辑：admin)