在以太坊信标链上可视化7个区块的重组

1

在2022年5月25日，UTC时间08:55时，信标链发生了7个区块的重组。我们在这里旨在提供可视化指南，以理解以太坊的Proof-of-Stake协议以及重组发生的原因。

简而言之，重组 不是 信标链的预期行为。 它是由于三种不同原因的不幸组合而发生的：

• 一个迟到的区块提案由于最近的分叉选择更新_提议者增强_而分裂了验证者的视图。

• 提议者增强更新作为一种软分叉发布，被视为仅是本地更改，可以以网络自己的步伐进行推送。这创造了一种情况，即某些验证者正在使用提议者增强，而某些则没有，导致视图的分裂。

• 在某些客户端中，_何时_期望运行分叉选择的已知错误实现持续存在，导致故障的持续存在。

重要的是，重组并未导致最终性的丧失。最终性甚至没有延迟。 因此，我们在讨论到底是什么被重组时需要更精确。

接下来，我们回顾一下Proof-of-Stake以太坊的基础知识，并深入了解重组是如何发生的。

以太坊中Proof-of-Stake 101

Proof-of-Stake以太坊具有两个共识机制并行运行：

• 首先，FFG Casper负责为链提供经济最终性。每个纪元，“源”和“目标”来自_验证者_的投票被统计。当某个检查点区块（一个纪元的开始）积累足够的目标投票时，它将变为证明合理性。当最近的证明合理性的源用于证明目标检查点时，目标检查点被证明合理，源将被最终确定。大意是，没有相互冲突的检查点区块可以在不削减至少1/3的活跃权益的情况下被最终确定。因此，在没有某一方大规模损失ETH的情况下，不能对最终确定的链进行重组。但目前的重组与共识的这一部分无关。

• 第二个组件，LMD GHOST，旨在提供一个_动态可用_的账本，即在最终性进行时扩展链。该链上的区块通过来自验证者的“头部”投票聚集权重。该权重用于在发生分叉时确定验证者应遵循哪个分支。由于预计权重在区块发布后会迅速累积，因此分叉预计是稀有的，并且及时的区块不应期望被重组。

在PoS以太坊中，时间被划分为时隙，每个时隙长度为12秒。在每个时隙，选择一个提议者，他们在基于LMD-GHOST分叉选择规则（以下简称为分叉选择）的信头链上构建其区块。提议者预计在时隙开始时发布他们的区块，而_验证者_预计在时隙开始后的4秒内或在接收到其区块后发布其源/目标/头部投票，以留出充分的时间让提议者让他们的区块被自己时隙的验证者看到。

尽管有缓冲，最近发现一个迟到的提议者可以恶意地“事先”重组下一时隙的提议者。同时，_提议者增强_被提出以解决平衡攻击的视图分裂的可能性，并也被应用于事先重组。使用提议者增强，验证者在他们所验证的当前时隙中给予提议者权重增强，本质上偏向及时的提议。我们将在接下来的部分看到这在实践中的效果。

那么它是如何分叉的？

让我们先看看分叉是如何发生的，然后再逐步分析。我们用矩形表示区块，用圆表示验证（投票），圆越大，对特定区块投票的验证越多。你可以看到，随着区块收到越来越多的验证，投票权重是如何随时间累积的。

大致上，区块74和75同时出现，形成一个分叉。一串提议者基于75构建了区块，而区块74的分叉累积的权重超过了竞争分支。最终，提议者82基于74构建了区块，结束了分叉，代价是重组了区块75到81。每一步现在都被仔细分析，以查看这是如何发生的。

步骤解析

在时隙73，时隙73的验证者为按时到达的区块73投票。到目前为止，一切都很好。

在时隙74，没有区块出现，因此时隙74的验证者投票支持时隙73的区块，从而增加其权重。

区块74和75在时隙75开始时大约同时出现，因为区块74迟到了。提议者增强旨在给予75更大的权重，以便时隙75的验证者更倾向于区块75，而不是区块74，因为从他们的视角来看，区块75是及时的。然而，并非所有的验证者都在使用提议者增强，因此投票几乎是50-50的分裂。

• 运行未启用提议者增强的客户端的验证者更喜欢区块74。

• 运行已启用提议者增强的客户端的验证者更喜欢区块75。

我们可以清楚地看到分裂，因为两个分叉两侧的投票权重在累积，没有增强的验证者更倾向于时隙74，而获得增强的验证者更倾向于时隙75。事实证明，略多的验证者_没有_启用提议者增强，因此上方分叉的权重略大于下方分叉。

那么问题是：既然区块74的权重大于区块75，为什么提议者76会在75之上构建他们的区块？

原因是微妙的，并与当前更新的客户行为有关。提议者预计在提议之前运行分叉选择，在他们的时隙时设置。然而，提议者76使用的是他们在_先前时隙时运行的分叉选择计算。因此，提议者增强适用于当前_分叉选择_时隙的提议者。因此，提议者76在其对当前头部的视角下错误地增强了提议者75，选择区块75作为其区块的父区块。从提议者76的观点来看：

75上的验证者 + 75上的提议者增强 > 74上的验证者

与此同时，时隙76的验证者继续在没有增强的最重链（以74区块为首）和有增强的最重链（以76区块为首）之间分裂他们的投票。

这一情况一直重复到时隙81。注意，从75到81的所有验证者_不使用提议者增强_仍在为区块74投票，从而增加其权重。

最后，出现了一位不在上一时隙上应用提议者增强来决定其区块构建位置的提议者。提议者82发现区块74比区块81重。虽然区块81继承了其后所有区块的权重，但请记住，总是稍微更多的投票权重对74而不是75到81中的任何区块投票……

在这里，时隙82的验证者没有混淆：

• 那些不使用提议者增强的验证者显然看到82获胜，正因为区块74比区块81重的同样理由，区块82是在区块74上构建的。

• 使用提议者增强的验证者_更是如此_看到区块82获胜。投票不再分裂。

• • *

最后，链条恢复了其进程，提议者83在区块82上构建。到此时，区块75到81已经有效地被重组显而易见。

收获

重组突显了动态可用链的一个失败案例，这种情况在理论上是可能的但在实践中难以想象，就像在工作量证明中，长重组是可能的，但在实际中很少见（排除敌对行为）。因此，识别导致此次重组的因素纯粹是偶然的很重要：

• 迟到的区块总是可能发生，没有任何办法避免。动态可用链原则上旨在公平应对这种偶然性，以便更及时的提议者看到他们的区块被接受到规范链中。

• 但显然，即使是看起来仅“局部”的更改（就像分叉选择计算）也需要在共识的更大格局中考虑。以太坊协议研究人员已经熟悉“分视图”的概念，其中一组验证者局部看到一些东西，而另一组则看到其他东西，以及这些分视图如何可能导致延迟存活性。应该认识到提议者增强的不均匀推广具有产生这种分视图的潜力。这一点被已知的实现故障进一步恶化。

• 如果所有验证者运行相同的配置，这个问题就不会发生！特别是，在合并后不会发生，因为所有验证者必须硬分叉以推送合并更新，否则将被完全踢出共识。

PoS以太坊是一个混合共识，旨在在对抗性环境中保持健壮。Sreeram Kannan最近的一篇帖子很好地突出体现了此类挑战：

\ \ Sreeram Kannan @sreeramkannan\ \ 这是对以太坊PoS协议的一篇赞美文章，背景是最近提出的问题。 @VitalikButerin@dannyryan@drakefjustin@dankrad@casparschwa@zmanian@barnabemonnot\ \ \ \ Georgios Konstantopoulos @gakonst\ \ 我认为人们没有意识到以太坊基于链的PoS是多么大的创新 [2022年5月28日 09:03 AM\ \

• • *\ \ 117 Likes 30 Retweets](https://twitter.com/sreeramkannan/status/1530474715990478848)

共识的已知局限性，也在Sreeram在其线程中链接的研究中提到，正在推动协议变化。尽管当这种失败发生时是极度不满意的，但在我个人观点中，这并不能否定以太坊所采取的方法。但它确实要求我们小心行事，并创建一个不仅在理论上而且在实践中也稳健的协议。

非常感谢所有帮助澄清此问题的研究人员和开发人员。特别感谢Paul Hauner在几分钟内检测到重组，然后在与其他共识客户端开发者的群聊中在接下来的一个小时内进行分诊和诊断问题原因。感谢Martin Köppelmann公开提出这一问题，感谢Jacek Sieka提供我支持本分析的数据，感谢Potuz进行他的分析，感谢Terence Tsao为社区迅速提供的见解，感谢Michael Sproul提供的额外数据，以及感谢Caspar和Francesco在一个星期三晚上进行的头脑风暴。

绘图代码可在此处获取。

订阅《代理的代价》

作者：Barnabé Monnot · 发起于4年前

以太坊，激励和其他事情

订阅

通过订阅，我同意Substack的使用条款，并承认其信息收集通知和隐私政策。

• 原文链接： barnabe.substack.com/p/p...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～