第二槽位的痒点 - 重组的统计分析 - 权益证明

本文分析了以太坊合并后的区块重组(reorgs)现象,重点关注了客户端类型和epoch中特定slot(尤其是第二个slot)的重组情况。通过统计分析,发现Nimbus客户端的区块更容易被重组,且epoch的第二个slot更容易发生重组,Prysm客户端在第二个slot中重组情况最为严重。研究还发现,前一个slot发生重组会显著增加当前slot被重组的可能性。

第二个槽位的痒点

特别感谢 Michael Sproul 提供的宝贵意见。

区块被放入槽位中,如果它们太晚且没有获得足够的证明,则可能会从规范链中被重组出去。在这种情况下,下一个提议者会在具有足够证明的先前区块之上构建。分析重组的动态为 CL 客户端团队提供了宝贵的见解,帮助他们改进其软件。

以下内容涵盖了对重组的简要统计分析,重点关注 CL 客户端和第二个槽位的小故障。有关重组的更多数据和可视化效果,请查看 reorg.pics

数据集 - 快速浏览

以下使用的数据集专门关注重组的区块。 我将重组的区块定义为我在 P2P gossip 网络中看到的有效区块,但未进入规范链的槽位。 错过的槽位 != 重组,以下内容侧重于重组:

  • epoch:epoch 编号。
  • slot:唯一的槽位编号。
  • cl_client:经历重组的客户端的类型。
  • slot_in_epoch:槽位在 epoch 中的位置,从 0 开始。

此分析的数据集包括自合并以来的每个槽位/区块。

它包含 1410 个重组和 17906 个验证者错过的槽位。

重组的区块占该时间段内区块总数的 0.059%,而错过的区块占 0.757%。

后续槽位

自从合并以来,已经发生了 4 次深度为 2 的重组。它们发生在槽位 5528988、5920525、6366357 和 6436520 中。其余的 1406 个是深度为 1 的重组。

重组:

depth occasions example slot(s) example epoch
1 1406 7060699, 7065797, 7070304 220947, 220806
2 4 5920525, 6366357, 6436520 201141, 198948

将错过的槽位和重组放在一起看,我们有 323 次连续的槽位,其中错过的/重组的槽位/区块深度为 2。另一方面,最大的一系列错过的/重组的槽位/区块是 7 个槽位长,发生在 2023 年 5 月 11 日,是由一个 bug 引起的,该错误导致 CL 客户端验证指向旧信标区块的证明(验证需要重新计算旧状态或从缓存中获取 - 有效地对它们进行 DoS 攻击),这导致链在某些 epoch 中停止最终确定。

重组 + 错过槽位:

depth occasions example slot(s) example epoch
1 18936 7059904, 7060399, 7060699 220646, 220637
2 323 6994062, 7020298, 7047834 220244, 219384
3 35 6424316, 6753389, 6753462 211045, 211043
4 12 6424242, 6424261, 6753388 211043, 200758
5 5 6424040, 6424205, 6424260 200758, 200756
6 4 6417737, 6424039, 6424204 200756, 200751
7 1 6417736 200554

观察客户端

下图显示了每个客户端重组区块的相对数量。 例如,自从合并以来,Nimbus 区块的 0.1% 被重组。 值得注意的是,由 Nimbus 客户端构建的区块比其他客户端更频繁地被重组。 假设延迟区块是导致重组的主要原因,这可能表明 Nimbus 客户端存在效率低下,导致验证者在槽位中太晚提出区块。 对于 Nimbus 来说,利用 提议者提升 来“惩罚”先前积累了少于 20% 证明的验证者,并通过重组他们来实施 诚实重组策略 可能不是解释。

Screenshot from 2023-08-09 22-18-28\ Screenshot from 2023-08-09 22-18-28743×281 12.3 KB

棘手的第二个槽位

一个 epoch 的第二个槽位往往最常被重组,其次是第三和第四个槽位中的偶尔重组。 这种现象可能源于复杂的 epoch 边界给第一个验证者带来挑战,导致级联效应。

Screenshot from 2023-08-10 12-34-41\ Screenshot from 2023-08-10 12-34-41759×259 14.6 KB

稍后会有一些统计数据,但这不需要太多说服力就能意识到一个 epoch 的第二个和第三个槽位中的重组显着增加。 原因可能是以下几点:

  • 由于 epoch 转换的计算,槽位 0 的验证者可能会延迟,与其他 epoch 内的槽位相比,这需要更多的工作。
  • 槽位 1 的验证者可能会尝试重组槽位 0 验证者的区块,以惩罚他们的延迟(诚实重组)。
  • 最后,槽位 2 的证明者和提议者可能不同意槽位 1 的验证者,从而将他们重组出去。
  • 最终,这会导致对槽位 2 和 3 的级联效应。

总之,验证者可能要么速度较慢并且没有获得足够的证明 - 因此被下一个重组,要么验证者尝试重组之前的验证者并被下一个重组。

让我们检查一下哪个客户端受影响最大。 我们可以通过绘制客户端在特定槽位中被重组的相对概率来做到这一点。

Screenshot from 2023-08-09 22-54-12\ Screenshot from 2023-08-09 22-54-12799×273 18.8 KB

我们看到 Prysm 似乎是在 epoch 的第二个槽位中遇到最多困难的客户端。 在 epoch 的第二个槽位中,超过 0.8% 的 Prysm 区块被重组。 其次是 Lighthouse,其中几乎 0.6% 的第二槽位区块被重组。 Lodestar 似乎在第三个槽位中略有挣扎。

深入研究概率

为了理解 epoch 中槽位索引对重组可能性的潜在影响,让我们采用一种统计方法——逻辑回归。 这种方法特别适合,因为目标变量“reorged”是二元的,表明一个槽位是否经历了重组(1)或没有(0)。 通过将 slot_in_epoch 列转换为虚拟变量,每个变量代表一个 epoch 中的不同槽位索引,我们可以确定相对于参考槽位(数据集中的最后一个)的各个槽位的影响。

Screenshot from 2023-08-10 13-25-20\ Screenshot from 2023-08-10 13-25-20931×723 35.2 KB

正如在逻辑回归的输出中可见的,

  • const 的系数为 -7.4625。 这是当所有预测变量都为零时,使用 epoch 中的最后一个槽位作为参考类别时,reorged 的对数几率。 简单来说,这只是告诉我们,参考类别的重组概率 - epoch 中的最后一个槽位 - 略低于所有槽位的平均值(e^{-7.4625}=0.057\%)
  • epoch 中第二个槽位(index_of_slot_1)的系数为 2.3426,表明对于此变量的单位增加,reorged 的对数几率增加 2.3426,保持所有其他变量不变。 这意味着在第二个槽位中被重组的可能性是在最后一个槽位中的 10.41 倍 (e^{2.3426}=10.41)。 低于常用阈值 0.05 的 p 值表明具有统计显着性。
  • index_of_slot_2 也是如此,系数为 0.7945。 因此,在第三个槽位中被重组的几率比 epoch 的最后一个槽位高 2.21 倍。
  • 对于 epoch 中的第 7 个槽位index_of_slot_6),我们可以看到,与 index_of_slot_31 的槽位相比,被重组的概率降低了约 39%

级联效应

Screenshot from 2023-08-10 13-21-56\ Screenshot from 2023-08-10 13-21-56745×269 14.2 KB

  1. 常量(截距):-7.4279。 当 prev_reorged 为 0 时(即,之前的槽位没有被重组),这是结果(reorged)发生的对数几率。 从数学上讲,它告诉我们,当之前的槽位未被重组时,一个槽位被重组的几率的自然对数为 -7.4279。
  2. prev_reorged: 1.5650。 该系数代表对数几率比,并描述了对于预测变量(prev_reorged)的单位增加,结果(reorged)的几率如何变化,假设模型中的所有其他变量保持不变。 鉴于 prev_reorged 是一个二元变量(之前的槽位要么被重组,要么没有),该系数告诉我们,与之前的槽位没有被重组相比,当之前的槽位被重组时,一个槽位被重组的对数几率的增加。

为了根据几率解释该系数:

prev_reorged 的几率比为 e^{1.5650} ≈ 4.78。

这意味着,当所有其他预测变量保持不变时,如果之前的槽位被重组,则一个槽位重组的可能性大约是 4.78 倍,而不是之前的槽位没有被重组。 或者,换一种说法,与之前的槽位没有被重组相比,当之前的槽位被重组时,一个槽位被 重组 的几率增加了 378%。

最后,prev_reorgedp 值为 0.002,小于 0.05,表明这种关系在 5% 的水平上具有统计显着性。

每个客户端的重组

对于以下内容,Lighthouse 客户端被用作参考类别。

Screenshot from 2023-08-10 13-38-22\ Screenshot from 2023-08-10 13-38-22943×323 17.5 KB

  • Lodestar(在统计上不显着):

    • 系数:0.0916。 这意味着,在保持所有其他不变的情况下,使用 Lodestar 而不是参考客户端与 reorged 的几率增加 1.0958 (e^{0.0916}) 倍相关。 与参考客户端相比,这大约是几率增加 9.58%。
    • P 值:0.785 表明使用 Lodestar 的影响在传统的显着性水平上在统计上不显着
  • Nimbus(在统计上显着):

    • 系数:0.5593。 使用 Nimbus,在保持所有其他不变的情况下,与 reorged 的几率增加 1.7496 倍相关,或者与参考客户端相比,几率增加 74.96%。
    • P 值:0.000 表明使用 Nimbus 的影响在统计上显着
  • Prysm(在统计上不显着):

    • 系数:0.0185。 使用 Prysm,在保持所有其他不变的情况下,与 reorged 的几率增加 1.0187 倍相关,或者与参考客户端相比,几率大约增加 1.87%。
    • P 值:0.767 表明使用 Prysm 的影响在统计上不显着。
  • Teku(在统计上不显着):

    • 系数:0.0892。 使用 Teku,在保持所有其他不变的情况下,与 reorged 的几率增加 1.0933 倍相关,或者与参考客户端相比,几率增加 9.33%。
    • P 值:0.253 表明使用 Teku 的影响在统计上不显着。

总结

统计数据表明,epoch 中某些槽位索引对被重组的可能性有显着影响。 此外,重组对连续槽位有潜在的级联效应。 虽然单个重组事件非常不频繁,但它们的发生对以下槽位有显着影响。 对于 CL 客户端,似乎存在一些导致槽位被重组的效率低下问题。

此分析的代码可在此处获得 here

特别感谢 Michael Sproul 开源 blockprint 工具,该工具帮助识别重组和受影响的客户端。

  • 原文链接: ethresear.ch/t/the-secon...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文, 用中文传播以太坊的最新进展