以太坊合并：请自行承担运行多个客户端的后果

出于安全性和活跃性的考虑，Etherum选择了多客户端架构。为了鼓励质押者将他们的设置多样化，对相关的失败处罚更高。所以，运行少数客户端的质押者通常只会在客户端出现错误的情况下损失适度的金额，但运行多个客户端可能会导致全盘亏损。因此，负责任的质押者应该着眼于客户端环境，而选择一个不太受欢迎的客户端。

为什么我们需要多个客户端？

对于为什么单一客户端体系的结构更可取是存在争议的。而开发多个客户端会产生相当大的开销，这就是为什么我们没有看到任何其他区块链网络认真地追求多客户端选项的原因。
那么，为什么Etherum的目标是成为多客户端？客户端是非常复杂的代码片段，很可能包含错误。其中最糟糕的是所谓的“共识错误”，即区块链核心状态转换逻辑中的错误。一个经常被引用的例子是所谓的“无限货币供应”漏洞，在这个漏洞中，有漏洞的客户端接受打印任意数量的以太的交易。如果有人发现了这样的漏洞，但在他们到达出口之前没有被阻止(即通过混合器或交易所来利用资金)，这将导致Ether的价值大幅崩溃。
如果每个人都运行相同的客户端，停止需要人工干预，因为链、所有智能合约和交易所都将照常运行。即使是几分钟的时间也足以执行一次成功的攻击，并充分分散资金，使其不可能只回滚攻击者的交易。根据打印的ETH数量，社区可能会协调将链回滚到利用漏洞之前(在识别并修复错误之后)。

现在，让我们来看看当我们有多个客户端时会发生什么。有两种可能的情况：
1. 有漏洞的客户端只占不到50%的质押份额，客户端将使用利用该错误的事务生成一个块，打印ETH，让我们称这条链为A。
然而，运行无故障客户端的大多数质押将忽略此块，因为它是无效的(对他们来说，打印ETH操作就是无效的)。它们将构建不包含无效块的备用链B。
由于正确的客户端占多数，B链将积累更多的证明。因此，即使是有问题的客户端也会投票给链B；结果就是链B将积累100%的选票，链A将死亡。链条将继续，就像错误从未发生过一样。
2. 大部分质押份额使用的是有问题的用户端，在这种情况下，链A将积累多数选票。但是，由于B拥有不到50%的所有证明，违规的客户端将永远看不到从链A切换到链B的理由。因此，我们将看到链分裂。

情况 1 是最理想的情况。因为这很可能会导致一个孤立的块，而大多数用户甚至都不会注意到。开发人员则可以调试客户端，修复错误，一切安好。相反，案例 2 显然不那么理想。但仍然比只有一个客户端的情况要好--大多数人会很快检测到链条分裂(您可以通过运行多个客户端自动完成这一点)，交易所会迅速暂停存款，Defi用户可以在分裂解决时谨慎行事。基本上，与单客户端体系结构相比，这仍然给我们提供了一个闪烁的红色警示灯，从而免受最坏结果的影响。
如果有错误的客户端由超过2/3的质押运行，情况2将会更糟。在这种情况下，它将最终确定无效的链。稍后会详细介绍这一点。
一些人认为链分裂是如此灾难性，以至于它本身就是单客户端体系结构的一个论点。但请注意，链分裂只是因为客户端中的错误而发生的。对于单个客户端，如果您希望修复此问题并将链恢复到原来的状态，则必须回滚到错误发生之前的块-这与链分裂一样糟糕！因此，尽管链拆分听起来很糟糕，但在客户端存在关键错误的情况下，它实际上是一个功能，而不是一个错误。至少你可以看到有些地方出了严重的问题。

激励客户端多样性：反相关性惩罚

如果质押分散在多个客户端，最好的情况是每个客户端拥有不到总质押的三分之一，这显然对网络有利。这将使其对任何单个客户端中的错误具有弹性。但质押者为什么会在乎呢？如果网络没有任何激励措施，他们就不太可能承担转向少数派客户端的成本。
不幸的是，我们不能让奖励直接依赖于验证器运行的客户端。没有不能被欺骗的客观方法来衡量这一点。
然而，当您的客户端有错误时，您无法隐藏。这就是反相关惩罚的用武之地：其思想是，如果您的验证器做了一些不好的事情，那么如果更多的验证器几乎在同一时间犯了错误，那么惩罚就会更高。换句话说，你会因为相关的失败而受到惩罚。

在以太，你目前可能会因为两种行为而被砍掉：

1. 在相同高度的两个区块上签名。
2. 创建一对可删减的证明(环绕投票或双倍投票)。

当你被大幅削减时，你通常不会失去所有的资金。在撰写本文时(Altair Fork)，默认惩罚实际上非常小：您只会损失0.5ETH，或您所赌注的以太的1.5%(最终将增加到1ETH或3%)。
然而，有一个问题：还有一个额外的惩罚，它取决于在您的验证器被砍掉之前和之后的4096个时期(18天)内发生的所有其他砍掉。你被进一步处罚的金额与这段时间内被削减的总金额成比例。
这可能是比最初的惩罚要大得多的惩罚，目前(Altair 分叉)它的设置是，如果超过一半的全部质押余额在这段时间内被削减，那么你将失去所有的资金。最终，这将被设置为：如果其他验证者的1/3被砍掉，您将失去所有质押。之所以选择1/3，是因为产生共识失败而必须模棱两可的最小权益数量。

另一个反相关性惩罚：二次无活动泄漏

验证器失败的另一种方式是离线，同样，这是有惩罚的，但其机制非常不同。我们不称之为削减，而且通常很小：在正常操作下，离线的验证器受到的惩罚与他们在完全验证时将获得的惩罚相同。在撰写本文时，这是每年4.8%的增长率。如果您的验证器有几个小时或几天处于离线状态，例如由于临时的互联网中断，那么可能不值得出一身冷汗。
当超过1/3的验证器处于离线状态时，情况会变得非常不同。然后，信标链无法最终敲定，这威胁到协商一致议定书的一个基本属性，即活跃性。
为了在这样的情况下恢复活力，所谓的 “ 二次无活动泄漏 ” 开始发挥作用。如果验证器在链未完成时继续脱机，则总罚款额随时间呈二次曲线上升。最初是非常低的；大约4.5天后，离线验证者将失去1%的质押。然而，它在~10天后增加到5%，在~21天后增加到20%(这是Altair 的值，未来将翻一番)。

该机制的设计是为了在发生导致大量验证器操作失效的灾难性事件的情况下，链最终能够再次完成。随着离线验证器失去越来越多的质押，他们在总质押中的份额将越来越小，当他们的质押降至1/3以下时，剩余的在线验证器获得所需的2/3多数，从而使他们能够最终确定链。
然而，还有另一种情况与此相关：在某些情况下，验证器不能再投票给有效链，因为它们意外地将自己锁定在无效链中，下面是关于这一点的更多信息。

运行多数用户端有多糟糕？

为了了解危险是什么，让我们来看看三种失败类型：
1. 大规模削减事件：由于错误，大多数客户端验证器签署了可大幅削减的证明。

2. 大量离线事件：由于错误，所有多数客户端验证器都离线。

3. 无效区块事件：由于错误，多数用户端验证器都证明存在无效块。

还可能发生其他类型的大规模失败和砍杀，但我仅限于与客户端错误相关的错误(在选择运行哪个客户端时应该考虑这些错误)。

场景1：双重签名

这可能是大多数验证器操作员最害怕的场景：导致验证器客户端签署可删除证明的错误。一个例子是两个证明人投票给相同的目标时期，但具有不同的有效负载。因为这是一个客户端错误，所以关注的不只是一个质押者，而是运行这个特定客户端的所有质押者。一旦发现这些含糊其辞行为，这将是一场大屠杀：所有相关的质押者都将失去100%的质押资金。这是因为我们正在考虑多个客户端：如果相关客户端的质押比例只有10%，那么“只有”20%的质押比例将被削减(在Altair；30%，并设定最终的处罚参数)。
在这种情况下，损害显然是极端的，但我也认为极不可能。可删除证明的条件很简单，这就是为什么构建验证器客户端(VCs)来强制执行它们的原因。验证器客户端是一个很小的、经过良好审核的软件，这种规模的漏洞不太可能出现。
到目前为止，我们已经看到了一些削减，但据我所知，所有这些都是由于操作员故障-几乎所有这些都是由于操作员在几个位置运行相同的验证器造成的。由于这些都不相关，因此削减的金额很小。

场景2：大规模离线活动

对于此场景，我们假设大多数客户端有一个错误，当触发该错误时，会导致客户端崩溃。有问题的块已经被集成到链中，每当客户端遇到该块时，它就会离线，从而无法进一步参与协商。大多数客户端现在处于离线状态，因此开始出现非活动泄漏。
客户端开发人员将争先恐后地将一切重新组合在一起。现实地说，在几个小时内，最多几天，他们将发布一个错误修复程序，以消除崩溃。
与此同时，订货商也可以选择简单地切换到另一个客户端。只要这样做足以让超过2/3的验证器在线，二次无活动泄漏就会停止。在有错误的客户端得到修复之前，这并不是不可能发生。
这种情况并不是不可能(导致崩溃的错误是最常见的类型之一)，但总的惩罚可能不到受影响质押的1%。

场景3：无效数据区块

对于这个场景，我们考虑这样的情况：大多数客户端有一个错误，会产生无效的块，并且也接受它为有效的--也就是说，当使用同一客户端的其他验证器看到无效的块时，它们将认为它是有效的，从而证明它。
让我们调用包含无效区块链A的链，一旦产生无效区块，就会发生两件事：

1. 所有正常工作的客户端都将忽略无效块，而是在生成单独链B的最新有效磁头上构建。所有正常工作的客户端都将投票并在链B上构建。

2. 故障客户端认为链A和B都有效，因此，它将投票给目前认为最重的两条链中的任何一条。

我们需要区分三种情况：

1. 有漏洞的客户端持有的质押不到总质押的一半。在这种情况下，所有正确的客户端都投票并建立在B链上，最终使其成为最重的链。在这一点上，即使是有错误的客户端也会切换到链B。除了一个或几个孤立的块之外，不会发生任何糟糕的事情。这就是令人欣慰的情况，也是为什么只有多数用户是很棒的原因。

2. 有漏洞的客户端持有超过一半但不到三分之二的质押。在本例中，我们将看到正在构建两个链--A由有错误的客户端构建，B由所有其他客户端构建。这两条链都没有三分之二的多数，因此他们无法最终敲定。当这种情况发生时，开发人员将争先恐后地理解为什么会有两条链。当他们发现链A中存在无效块时，他们可以继续修复有错误的客户端。一旦修复，它会将链A识别为无效。因此，它将开始建立在B链的基础上，这将使它能够最终敲定。这对用户来说是非常具有破坏性的。虽然希望哪一条链有效之间的混淆将是短暂的，不到一小时，但链可能在几个小时内甚至一天内都不会最终确定。但对于制片人来说，即使是那些运行有问题的客户端的人，处罚仍然相对较轻。如果他们在构建无效的链A时没有参与链B，他们将受到 “ 非活动泄漏 ” 的惩罚。然而，由于这可能不到一天，我们谈论的惩罚不到1%的质押。

3. 有问题的客户端持有超过三分之二的质押。在这种情况下，有错误的客户端将不只是构建链A—它实际上将拥有足够的质押来 “终结” 它。请注意，它将是唯一会认为链A已完成的客户端。最终确定的条件之一是链是有效的，而对于所有其他正确操作的客户端来说，链A将无效。然而，由于Casper FFG协议的工作方式，当验证器最终确定链A时，他们永远不能在不被砍掉的情况下参与与A冲突的另一个链，除非该链最终确定(对于任何对细节感兴趣的人，请参阅附录2)。因此，一旦链A被最终确定，运行有错误的客户端的验证器就陷入了可怕的困境：他们已经提交了链A，但链A是无效的。他们不能对B做出贡献，因为它还没有最终敲定。即使是他们的验证器软件的错误修复也帮不了他们-他们已经发送了违规的选票。现在会发生什么是非常痛苦的：尚未敲定的B链将进入二次无活动泄漏。在几周的时间里，违规的验证者将泄露他们的质押，直到损失足够多的质押，以便B再次敲定。假设他们一开始持有70%的质押--那么他们将失去79%的质押，因为这是他们需要损失的金额，才能代表不到总质押的三分之一。在这一点上，链B将再次敲定，所有质押者都可以切换到它。链条将再次恢复健康，但中断将持续数周，数百万ETH在此过程中被摧毁。

显然，案例3简直就是一场灾难。这就是为什么我们极其热衷于不让任何客户端持有超过三分之二的质押。那么任何无效的块都不能被最终确定，这永远不会发生。

风险分析

那么，我们如何评估这些情景呢？典型的风险分析策略是评估事件发生的可能性(1-极不可能，5-非常可能)以及影响(1-非常低，5-灾难性)。需要关注的最重要风险是那些在两个指标上得分都很高的风险，以影响和可能性的乘积为代表。

考虑到这一点，到目前为止最优先的是情景3。当一个客户端处于三分之二的绝对多数时，影响是相当灾难性的，这也是一个相对可能的情景。为了强调这样的漏洞很容易发生，最近在Kiln Testnet上发生了这样的错误(参见Kiln Testnet阻止提案失败)。在这种情况下，Prysm在提出后确实检测到了积木有缺陷，并且没有证明这一点。如果Prysm认为该阻塞有效，并且这种情况发生在Mainnet上，那么我们处于场景3的情况3中描述的灾难性情况-因为Prysm目前在Mainnet拥有2/3的多数。因此，如果你目前正在运营Prysm，那么你可能会损失所有资金，这是一个非常真实的风险，你应该考虑更换客户端。

情景1可能是人们最担心的，得到的评级相对较低。这样做的原因是，我认为发生这种情况的可能性相当低，因为我认为Validator客户端软件在所有客户端上都实现得很好，它不太可能生成可倾斜的证明或块。

如果我目前运行的是多个客户端，并且我担心切换，我还有什么选择？

更换客户端可能是一项重大任务，这也伴随着一些风险。如果斜切数据库未正确迁移到新设置，该怎么办？可能会有被砍掉的风险，这完全违背了目的。

我会向任何担心这一点的人建议另一种选择。也可以让您的验证器设置保持原样(不需要取出密钥等)，并且只切换信标节点。这是非常低的风险，因为只要验证器客户端按预期工作，它就永远不会重复签名，因此不能被砍掉。特别是如果您有大型操作，其中更改验证器客户端(或远程签名者)基础设施将非常昂贵，并且可能需要审核，这可能是一个很好的选择。如果设置的性能不如预期，也可以很容易地切换回原始客户端，或者尝试其他少数客户端。

好消息是，在切换信标节点时，您几乎不用担心：它对您造成的最坏影响就是暂时脱机。这是因为信标节点本身永远不能自己产生可切削消息。如果您运行的是少数派客户端，则不可能最终进入场景3，因为即使您投票支持无效的区块，该区块也不会获得足够的票数来最终确定。

那被惩罚客户端的呢？

我在上面写的内容适用于Consensus客户端-Prysm、LighTower、Nimbus、Loestar和Teku，在撰写本文时，Prysm可能在网络上拥有三分之二的多数。
所有这些都以相同的方式适用于执行客户端。Go-Etherum很可能是合并后的大多数执行客户端，如果它产生无效的块，它可能会最终确定，从而导致场景3中描述的灾难性故障。
幸运的是，我们现在已经有另外三个执行客户端准备好投入生产--Nethermind、Besu和Erigon。如果你是一名质押者，我强烈建议你运行其中的一个。如果你经营的是少数派客户端，则风险非常低！但如果你经营多数客户端，你就面临着损失所有资金的严重风险。

附录

附录1：为什么不对无效的区块进行大幅削减？

在场景3中，我们必须依靠二次无活动泄漏来惩罚提出和投票给无效块的验证器。这很奇怪，为什么我们不直接惩罚他们呢？这样看起来会更快，也不会那么痛苦。
事实上，我们不这么做的原因有两个--一个是我们目前不能这么做，但即使我们可以，我们也很可能不会这么做：

1. 目前，几乎不可能对无效数据块引入惩罚(“大幅削减”)。这是因为信标链和执行链目前都不是 “ 无状态 ” ——即为了检查区块是否有效，您需要一个大小为100s MB(信标链)或GB(执行链)的上下文(“状态”)。这意味着没有 “ 简明的证据 ” 来证明区块是无效的。我们需要这样的证据来削减验证器：“削减”验证器的块需要包括验证器已经犯法的证据。在没有无国籍共识的情况下，有一些方法可以绕过这个问题，但它将涉及更复杂的结构，如多轮欺诈证据，如Arbitrum目前用于汇总的证据。

2. 我们可能不那么急于引入这种类型的削减的第二个原因是，即使我们可以这样做，也是因为产生无效块比目前的削减条件更难防止。目前的条件非常简单，验证器客户端只需几行代码就可以轻松地进行验证。这就是为什么我认为上面的情景1不太可能--到目前为止，可删减的消息只是由运营商的失误产生的，我认为这种情况可能会继续下去。添加用于产生无效区块(或证明它们)的斜切会增加投币者的风险。现在，即使是那些经营少数派客户端的人也可能面临严重处罚。

总而言之，在接下来的几年里，我们不太可能看到对无效块和/或对它们的证明进行直接惩罚。

附录2：为什么有缺陷的客户端在最终确定链A后不能切换到链B？

这一节是为那些想要更详细地了解为什么有错误的客户端不能简单地切换回来而不得不遭受可怕的无活动泄漏的人而设计的。为此，我们必须看看Casper FFG最终确定是如何工作的。
每个证明都包含一个源检查点和一个目标检查点。检查站是一个纪元（Epoch）的第一个区块。如果存在从一个纪元到另一个纪元的链接，而该链接的投票总数超过所有利害关系的2/3(即，有如此多的证明，其中第一个检查点为“源”，第二个检查点为“目标”)，则我们将其称为“超级多数链接”。

一个纪元可以是“合理的”，也可以是“确定的”，它们的定义如下：

1. 纪元0是对齐的。

2. 如果与一个合理的纪元有绝对多数的联系，那么一个纪元就是合理的。

3. 如果(1)纪元X是对齐的，并且(2)下一个纪元也是对齐的，且绝大多数链接的源是纪元X，则纪元X被最终确定。

规则3略有简化(有更多的条件可以最终确定一个纪元，但它们对本讨论并不重要)。现在，让我们来看看大幅削减的条件。大幅削减证明有两条规则。两者都比较一对证明V和W：

1. 如果V和W的目标是相同的纪元(即相同的高度)，但它们不投票给相同的检查点(双重投票)，则它们是可以砍掉的。

2. 这意味着(1)V的源早于W的源和(2)V的目标晚于W的目标(环绕投票)。

第一个条件是显而易见的：它防止简单地投票给同一高度的两个不同的链。但是第二个条件有什么作用呢？
它的功能是削减参与最终确定两个冲突链的所有验证器(这永远不应该发生)。要了解原因，让我们再次查看我们的场景3，在最糟糕的情况下，有错误的客户端占绝对多数(>2/3的质押)。当它继续投票给有故障的链时，它将最终确定具有无效块的纪元，如下所示：

这张图片中的圆角方框代表的是纪元，而不是区块。绿色箭头是所有验证器创建的最后一个超级多数链接。红色箭头是仅由有错误的客户端支持的超级多数链接。正常工作的客户端忽略带有无效区块(红色)纪元。第一个红色箭头将证明无效的纪元是正确的，第二个箭头将确定无效纪元。
现在让我们假设错误已经修复，并且最终确定无效纪元的验证器想要重新加入正确的链B。为了能够终止链，第一步是调整纪元X：

然而，为了参与纪元X的调整(它需要一个由虚线绿色箭头指示的绝对多数链接)，他们将不得不“跳过”第二个红色箭头--那个最终确定无效纪元的箭头。投票支持这两个链接是一种可以砍掉的进攻。
对于任何后来的时代来说，这一点都将继续适用。修复它的唯一方法是通过二次无活动泄漏：随着链B的增长，锁定的验证器将泄漏他们的资金，直到链B可以被正常工作的客户端证明合理并最终确定为止。

[注：本文部分图片来自互联网！未经授权，不得转载！每天跟着我们读更多的书]

互推传媒文章转载自第三方或本站原创生产，如需转载，请联系版权方授权，如有内容如侵犯了你的权益，请联系我们进行删除！

如若转载，请注明出处：http://www.hfwlcm.com/info/282307.html