至善者，善之敌：评估Eth2验证者风险的正确姿势是什么？

信标链对于验证者行为有多种激励机制，这些机制都由网络的当前状态来决定。因此，在决策如何保障节点的时候，考虑其他验证者可能碰到问题的情况也很重要。

活跃验证者的余额非升即跌，不会保持不变。因此尽量降低风险不失为最大化收益的一种方式。验证者余额被信标链扣除的情形主要有以下三种：

一般惩罚：验证者失职的时候会被施以此种惩罚 (例如离线)

怠工惩罚 (Inactivity Leaks)：当网络处于无法敲定的状态时，验证者失职会受到该惩罚，即和其他处于离线状态的验证者高度相关。

罚没 (Slashing)：当验证者做出矛盾的区块提议或证明时会被罚没 (可能是攻击行为)。

注意：平均来看，单个验证者的余额可能不变，但只要参加了工作，就会获得奖励或是受到惩罚。

相关性

如果整个网络处于健康运行状态，那么单个验证者离线或是触发罚没的影响是很小的，也就是说惩罚力度不会很大。相反，如果网络中有大量验证者离线，那么离线验证者的余额削减速度会快得多。

同理，如果大量验证者同时触发罚没，对于信标链来说会这无异于攻击行为，因此这些验证者 100% 的质押金会被销毁。

由于这些“反相关”激励措施，验证者应该更多地考虑同时会对他人产生影响的问题，而不是从孤立的、个人的角度出发。

故障原因及可能性

让我们仔细通过一些故障案例，然后看看有多少其他验证者会同时受到影响，以及你的验证者将受到多大力度的惩罚。

这里我不同意 @econoar 的说法。这些问题的严重程度算是中等。家用 UPS 和双 WAN 地址故障与其他用户无关，因此从考虑范围中排除。

网络/电力故障

如果你是居家运行验证者，那么将来很可能会遇到这些问题。家用网络和电力连接无法保障正常运行时间。当网络断开连接或是电力中断时，通常是整个片区受到影响，甚至会持续数小时。

除非你的网络或是电力非常稳定，否则因为这个原因遭到惩罚是不太值当的。这几个小时之内你会受到惩罚，但是由于整个网络是正常运行状态，你的惩罚大约等同于该时间段内应得的奖励。也就是说，如果故障时间为 k 小时，那么你的验证者余额可能会回退到故障 k 小时前的数值，然后 k 小时之后你的验证者余额又会恢复到发生故障前的数值。

Validator #12661 的余额回升速度和离线时的降低速度大致相同 - Beaconcha.in

? 硬件故障

类似于网络问题，硬件故障会随机发生，而且在发生故障时，你的节点可能会离线几天。我们很有必要考虑验证者整个生命周期中的预期收益与备用硬件的成本。故障的期望值 (离线罚款乘以发生的几率) 是否大于备用硬件的成本？

就个人而言，如果发生故障的机会很低，且备用硬件的成本较高，这是不值当的。但是话又说回来，我不是巨鲸。你需要根据自己的实际情况来评估所有故障情形。

云服务故障

也许大家可能会为了避免硬件和网络故障而选择使用云服务。如果使用云服务的话，就引入了上面所说的相关性风险。有多少其他验证者和你使用相同的云服务商？

在创世前一周，亚马逊的 AWS 长时间停运，对网络了很大影响。现在如果发生类似的事件，导致大量验证者同时离线，就会触发怠工惩罚 (inactivity penalties)。

更坏的情况是，如果云服务商使用新的虚拟机运行你的节点，却意外地没有停止运行旧节点，这可能导致你被罚没 (如果这也对其他验证者造成了影响，那么惩罚力度会尤其大)。

如果你坚持要使用云服务，可以考虑切换到比较小的服务商，可能会减少损失。

质押服务

目前主网有多种质押服务 可以选择，并且去中心化程度都不尽相同，但是把你的 ETH 托付给服务商都多少增加了相关性风险。这些服务无疑是 eth2 生态系统中不可或缺的部分，对于持有低于 32 ETH 或是缺乏质押所需技术知识的用户来说更甚。但这些服务都是人为设计的，因此会存在缺陷。

如果质押池的规模最终会增长得和 eth1 矿池一样大，那么一个漏洞可能会导致其用户被大规模罚没或是怠工惩罚。

故障

上个月 Infura 宕机了六个小时，导致了以太坊生态系统的停滞。同理，这也是 Eth2 验证者可能面临的相关性风险。

另外，第三方 eth1 API 提供者必须对服务的调用进行速率限制：过去这导致了验证者无法生产有效块 (Medalla测试网)。

最好的解决方式就是运行你自己的 eth1 节点：你不会遇到速率限制，从而降低你的相关性风险，并且有助于提升整个网络的去中心化程度。

Eth2 客户端已经开始加入指定多个 eth1 节点的可能性。其好处在于，主要终端发生故障时能够轻松切换备用终端 (Lighthouse: --eth1-endpoints， Prysm: PR#8062，Nimbus 和 Teku 之后可能会加入支持)。

我高度建议添加成本较低或是免费的备用 API (EthereumNodes.com 中有免费和付费的 API 终端及其当前状态)。无论你是否运行自己的 eth1 节点，这个措施都很有必要。

某个 eth2 客户端故障

尽管进行了代码审核、审计和测试，但 eth2 客户端的 bug 都隐藏在某个地方。他们中的大多数都是次要的问题，并且会在产品发布前被发现，但是你所选择的客户端存在离线或者导致你被罚没的可能。如果发生这种情况，你将不会希望运行多数人 (＞1/3) 使用的客户端。

你必须在你认为最合适的客户端和其受欢迎程度之间做出权衡。可以考虑通读另一个客户端的文档，从而在你的节点发生意外时，知道如何安装和配置一个不同的客户端。

如果你质押了大量 ETH，运行不同的客户端是很有必要的，避免把鸡蛋都放在一个篮子里。 Vouch 是一个能够提供多节点质押的基础设施，目前秘密共享验证者 (Secret Shared Validators) 也迎来了飞速进展。

黑天鹅事件

当然了，也有许多可能性不大、不可预测但影响颇大的事件会带来风险。这无关你的质押设置和决策。例如在硬件层面的 Spectre 和 Meltdown，或是内核漏洞 (BleedingTooth提示整个硬件堆栈中存在某些危险)。也就是说，我们无法完全预测和避免这些问题，而是在问题发生后采取相应措施。

我需要担心什么？

归根结底，这取决于计算给定故障的期望值 E(X)：事件发生的可能性以及该事件的代价。由于相关性因素会对惩罚力度造成相当大的影响，因此在 eth2 网络其他成员的语境下考虑这些故障事件至关重要。将故障的预期成本与稀释故障的成本进行比较，你将得到一个合理的答案，以判断是否值得一试。

没有人知道节点可能发生故障的所有情形，也不知道每种故障发生的可能性，但是通过对每种故障类型的可能性进行独立估算并稀释最大风险，“群体智慧”将发挥作用。此外，由于每个验证者面临的风险不同，并且对这些风险的评估也不同，你没有考虑到的风险可能会被他人碰到，因此相关性将降低。去中心化的力量！

莫要惊慌

最后，如果你的节点真的发生了什么意外，别要惊慌！即使是遭到怠工惩罚 ( inactivity leaks)，在短时间内惩罚数额也不大。冷静下来思考一下发生了什么，为什么会发生，然后制定计划来解决问题。在上手之前深呼吸一下！比起慌忙做出错误决定导致被罚没，给自己多五分钟的思考时间更为可取。

重中之重：不要使用同一个验证密钥运行两个节点！

感谢Danny Ryan、Joseph Schweitzer 和 Sacha Yves Saint-Leger 对本文的审校