考虑到安全性和活动性，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 分叉)它的设置是，如果超过一半的质押余额在这段时间内减少，你将失去所有的资金。最后，这将被设置为:如果其他验证人的三分之一被切断，你将失去所有的质押。选择三分之一是因为共识失败，必须模棱两可。

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

验证器失败的另一种方法是离线。同样，也有惩罚，但其机制非常不同。我们不称之为削减，而且通常很小：在正常操作下，离线验证器的惩罚与他们在完全验证时获得的惩罚相同。写这篇文章时，事4.8%增长率。如果您的验证器离线几个小时或几天，例如，由于临时互联网中断，可能不值得出冷汗。

当超过三分之一的验证器处于离线状态时，情况会变得非常不同。然后，信标链无法最终确定，这威胁到协商协议的基本属性，即活动。

为了在这种情况下恢复活力，所谓的 二次无活动泄漏 开始发挥作用。如果验证器在链未完成时继续脱机，总罚款金额随时间呈二次曲线上升。一开始很低；关于4.5天后，离线验证者将失去1%的质押。然而，它在那里~10天后增加到5%，在~21天后增加到20%(这是Altair未来将翻一番)。

该机制的设计是为了在灾难性事件中再次完成链，导致大量验证器操作失败。随着离线验证器失去越来越多的质押，他们在总质押中的份额将越来越小。当他们的质押降至1/3以下时，剩余的在线验证器将获得所需的2/3以上，以便他们最终确定链。

然而，还有另一种情况与此相关：在某些情况下，验证器不能向有效链投票，因为它们意外地将自己锁定在无效链中。以下是关于这一点的更多信息。

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

让我们来看看三种失败类型，以了解危险是什么：

1.大规模减少事件：由于错误，大多数客户端验证器签署了可以大幅减少的证书。

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

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

其他类型的大规模失败和杀戮也可能发生，但我仅限于与客户端错误相关的错误（在选择运行哪个客户端时应考虑）。

场景1：双重签名

这可能是大多数验证器操作员最害怕的场景：导致验证器客户端签署可删除证书的错误。一个例子是，两个证人向相同的目标期投票，但有不同的有效负载。因为这是客户端的错误，我们不仅关注质押方，而且关注运行特定客户端的所有质押方。一旦发现这些模糊行为，这将是一场大屠杀：所有相关质押方将失去100%的质押资金。这是因为我们正在考虑多个客户：如果相关客户端的质押比例只有10%，那么只有20%的质押比例将被削减（在）Altair；30%，并设置最终处罚参数)。

在这种情况下，损坏显然是极端的，但我认为这是极其不可能的。删除证书的条件非常简单，这就是为什么构建验证器客户端(VCs)强制执行它们的原因。验证器客户端是一个经过良好审核的小软件，不太可能出现这种规模的漏洞。

到目前为止，我们已经看到了一些削减，但据我所知，所有这些都是由于操作员故障-几乎所有这些都是由操作员在几个位置操作相同的验证器造成的。因为这些都不相关，减少的金额很小。

场景2：大规模离线活动

对于这个场景，我们假设大多数客户端都有错误，当触发错误时，会导致客户端崩溃。有问题的块已经集成到链中，每当客户端遇到这个块时，它就会离线，因此无法进一步参与谈判。大多数客户端现在都离线了，所以非活动泄漏开始出现。

客户端开发人员将争相重新组合一切。现实地说，他们将在几个小时内发布错误的修复程序，以消除崩溃。

同时，订货商也可以选择简单地将其切换到另一个客户端。只要这足以让超过三分之二的验证器在线，二次无活动泄漏就会停止。在修复错误的客户端之前，这并非不可能。

这种情况并非不可能(崩溃的错误是最常见的类型之一)，但总的惩罚可能不到受质押影响的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它是对齐的，下一个时代也是对齐的，绝大多数链接的来源是时代X，则纪元X最终确定。

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

1. 如果V和W目标是相同的时间(即相同的高度)，但如果不投票给相同的检查点(双重投票)，就可以切断。

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

第一个条件是显而易见的：它可以防止简单地投票给两个不同高度的链。但第二个条件是什么呢？

它的功能是减少参与，最终确定两个冲突链的所有验证器（这永远不会发生）。为了解原因，让我们再次查看我们的场景3。在最糟糕的情况下，绝对大多数客户都有错误(>2/3质押)。当它继续向故障链投票时，它最终将确定无效块的时代，如下所示:

这张照片中的圆角框代表了一个时代，而不是一个块。绿色箭头是所有验证器创建的最后一个超级多数链接。红色箭头是大多数只有错误客户端支持的链接。正常工作的客户忽略了无效块（红色）时代。第一个红色箭头将证明无效时代是正确的，第二个箭头将确定无效时代。

现在让我们假设错误已经修复，最终确定无效时间的验证器想要添加正确的链B。为了终止链条，第一步是调整时间X：

然而，为了参与纪元X它需要一个绝对多数的链接，由虚线绿色箭头指示)，他们必须跳过第二个红色箭头--最终确定无效时间的箭头。投票支持这两个链接是一种可以切断的进攻。

这将继续适用于任何后来的时代。修复它的唯一方法是通过二次无活动泄漏：随着链条B锁定的验证器在链条之前，会泄露他们的资金B正常工作的客户端可以证明合理，最终确定。