火星独家 | 如何避免以太坊2.0罚没？这里有份指南

编译 | Bite@火星财经APP

12月1日，以太坊2.0正式顺利上线，在获得收益的同时，也应了解其中的惩罚措施。本篇文章对惩罚做一个详细解读。无论选择运行Prysm、Lighthouse、Teku、Nimbus或其它验证客户端，本文中的大部分信息适用于所有用户。

1. 什么是罚没？

当验证者在太坊网络中存在违反行为时，就会发生罚没。罚没不一定是恶意行为，例如，客户端配置错误也可能导致罚没。验证者的行为可能会混淆或破坏系统的完整性，就会“罚没”违规验证者部分现有质押金额，造成ETH损失，至到验证者被强制驱逐出验证者行列并标记为“SLASHED”。此过程不可逆。

请不要将罚没与怠惰处罚相混淆，怠惰处罚是验证者离线时间长，无法履行职责而产生的正常资金损失。

罚没的目标是阻止那些试图损害以太坊2.0网络的验证者，并反过来奖励那些维护、管理和按预期操作网络的验证者。罚没的主要目的是为了减少在以太坊2.0网络上进行攻击，比如在不同的史检查点视图上创建相互冲突的分叉验证者。

正确遵循协议的验证者在正常操作中永远不会罚没。 验证者不会仅因为离线状态而被罚没。

2. 罚没如何运行？

罚没的目的是为了抑制那些试图损害以太坊2.0网络的人，并通过促进好的行为者来加强链的安全性。虽然罚没是一种惩罚方式，但作为一个善良的验证者，如果客户端配置不当，仍然有可能被罚没。因此，如何了解正确设置和管理验证者客户端和操作系统至关重要，避免在不了解功能的情况下尝试高级指令。

以下情况会发生罚没

（1） 验证者在同一slot提出两个冲突区块，其根数不同（基本上是内部数据的散列）。如果这种行为不受到惩罚，验证者在链中就会制造不必要的分叉和混乱。

（2） 验证者在同一个slot上证明了两个冲突区块，这被称为重复投票，同时也意味着验证者可能试图制造冲突的链上分叉。注意：仅仅对完全相同的区块投了两次票，并不是一种罚没违法行为。

（3） 验证者投出“环绕”票，也就是说验证者是想投出违背史的票，这是一种罚没违法行为。

3. 罚没后会发生什么？

尽管有多种预防罚没机制，但是每个验证者只能对应一个密钥对。这听起来很简单，但当配置了多个验证者时，很容易错误地还原验证者身份并复制一个已经运行的验证者。在进行修改时，一定要确认使用/还原/设置正确的验证者密钥。

如果验证者被罚没，会发生一些事情：

（1） 被罚没的验证者将被迫在未来36天内退出信标链；

（2） 罚没的验证者会有三种惩罚类型；

（3） 当“吹哨人”将检举信息包含在区块中时，就会产生最低限度的惩罚；

（4） 在每个epoch开始时进行惩罚，直到验证者离开退出为止；

（5） 在举报信息被列入区块到违法者退出过程中，中间会有一个特殊的惩罚。这个特殊惩罚与在此期间还有多少其他验证者也被罚没成正比，罚没最高额度可达到违规者的剩余余额。

这意味着，如果验证者被罚没，它将立即接受惩罚，并将继续36天，直到退出结束。在第18天还会收到一次惩罚，罚没的金额还受到同一时间段内同样被发现有违法行为的验证者数量的影响（即是协同攻击还是单个不良行为者）。

最后，值得注意的是，被罚没的验证者不能重新进入验证者队伍行列中。如果想重新参与，需要生成一个新质押和密钥才能继续验证者。 整个罚没过程不可逆！

被罚没的结果基本上就可以看作是质押ETH的缓慢“流血”过程，中途还会“大出血”。就这样等36天后才可以退出信标链，剩余质押的ETH也同时退出，但在这段时间内会有相当一部分ETH流失。

4. 用户常见错误导致罚没

尽管前面提到的罚没场景，一个普通用户似乎是不可能做到，但作为诚实的验证者，很可能一个不恰当的配置就会导致罚没！以下是一些常见的可能出现的情况：

（1） 相同验证密钥同时在两台服务器上运行，其中一台可能作为故障转移，以防第一台服务器宕机。

解释：这是面临罚没最简单的方法。如果故障转移系统错误地认为第一个节点宕机了，那么可能会发现自己陷入了可能被罚没的违法行为中。不要在两台机器同时运行验证者密钥。

（2） 在没有迁移罚没保护史记录情况下，你可以将密钥迁移到另一台机器或另一个eth2客户端。

解释：另一个节点可能存在错误的时钟同步情况，导致触犯罚没的违法行为，如果导入了罚没保护史，就可以轻松避免。

（3） 在验证者客户端中删除或丢失了罚没保护史。

解释：没有罚没保护史可能会导致一些问题，比如时钟被打乱，无法创建罚没区块或投票。

（4） 使用没有持久卷的容器化环境进行验证

解释：如果你正在使用Docker或者可能在Kubernetes等云环境中运行，需要为你的验证者设置持久卷，这样如果重新启动pod或容器，罚没保护史就不会清除。

（5） 可能导致罚没错误的协议bug（这种情况不太可能）

解释：在测试网上发生的大规模罚没事件的催化剂往往是由于错误的操作流程所导致。然而，拥有罚没保护数据库和适当配置的验证者却没有受到影响，例如时间服务器故障的bug，以及对区块ID的不当处理。当Medalla测试网时间服务器发生故障，由于没有罚没史数据库，大多数验证者会被罚没。

在选择验证者时，了解如何设置，配置，升级和排除任何安装软件的故障至关重要。在这里可以找到一个很好的资源来更好地理解质押Eth2的风险。

5. 谁来执行罚没？

（1） Slasher

Slasher指的是一个独立的软件，其主要目的是检测Slasher事件，你可以把Slasher看作是网络“警察”。由于检测恶意消息需要额外的数据和进程，通常它与信标节点分开运行。为了检测可罚没消息，Slasher记录了网络上每个验证者的证明和提议史，并将这些史与广播的内容进行交叉参考，以找到罚没消息，如双块或周围的投票。

网络只需要1个诚实的Slasher客户端来监控网络，任何发现的罚没都会传播到整个网络，以便尽快将其放入一个区块中。

（2） “吹哨人”奖励

为了激励罚没检测，会给予“吹哨人”验证者奖励，即提交一个有任何有效罚没的区块时，在信标链上获得的奖励。这些奖励是给予针对罚没中的验证者，通常每个验证者的奖励约为0.1ETH。

虽然激励检测是有价值，但如果在Prysm中发现了罚没，仅仅运行罚没者客户端并不能让你获得“吹哨人”奖励。默认情况下，发现任何罚没都会传播到网络中，以尽快纳入区块，所以通常在检测到罚没后，奖励会立即给提议者，而不是给运行Slasher的验证者。

运行Slasher并不是为了盈利，而是一种利他行为。再次强调，只需要在网络中正常运作一个诚实的Slashe，就能抓到可罚没的违法行为。值得庆幸的是，这是一个很低的准入门槛，我们设想有相当多的用户和实体会运行Slasher确保网络安全。

6. 防止罚没

罚没是可预防的！有一些最佳做法可以确保不发生罚没事件，但关键是要理解这些做法，使其发挥最佳作用。

（1） 本地罚没保护数据库

一些客户端实现的防罚没方法是本地签名史数据库。这个功能在Prysm的验证者客户端中是默认启用。这个数据库可以确保验证者不会根据史记录来签署被认为是可罚没的消息；更简单地说，验证者在决定是否应该签署一个消息时，将数据库视为唯一的真理来源。这种方法保证了单个验证者不会执行重复的操作。

本地罚没保护并不能防止使用相同的验证者密钥运行多个验证者客户端实例，因为数据库是与其配对的验证者本地数据库。

数据库只跟踪该本地实例中验证者的签名。这也意味着，如果用户将验证者更换为不同的客户端（例如，从Lighthouse转移到Nimbus），或者转移到新硬件设置（安装新linux机器上，转移到托管解决方案），也必须迁移签名史数据库。这将确保在任何新的客户端上，过去的操作史都会被保留下来。

（2） 远程罚没保护

防止罚没的另一种方式是使用Slasher。Slasher记录了所有证明和区块，验证者在同意签署消息之前会引用它。这种方法是一种比本地签名史数据库更强的防罚没保护形式，但是和数据库一样，这种方法不能防止运行同一个验证者的多个实例。

防止罚没的另一种实现是使用slasher本身作为信标节点和验证者客户端之间的中间件。在验证者客户端提交区块或证明之前，它会先询问slasher是否可以罚没。如果通过，数据将通过信标节点。这是最先进的罚没保护形式，因为理想情况下，Slasher知道网络中发生的一切，并且记录了每个验证者的区块和证明史。

7. 迁移罚没保护史

在验证过程中的某一阶段，质押者可能需要执行的一项重要活动是将验证者密钥迁移到不同的机器或eth2客户端上。有时，你可能想更质押客户端以满足需求。无论怎样，你应该始终带着罚没保护史。

罚没保护标准：EIP-3076

在eth2客户端之间迁移罚没保护史的官方标准，称为EIP-3076。这个标准建议用JSON文件表示验证者的罚没保护史。在高层次上，这个文件包含：

1. 验证史所对应链的生成状态信息（以区分测试网和主网）；

2. 关于正在运行的验证者公钥所有签名区块和证明的信息；

通过导出这个文件，并迁移到另一台计算机或eth2客户端时导入它，你会得到很多好处，并且能够保持保护，防止在你没有存储这个本地史记录时可能发生的简单罚没状况。

文章来源：

Eth2 Slashing Prevention Tips：

https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50