以太坊2.0 Staking老司机指南 : 避免罚没的三大技巧

本文讨论了以太坊2.0网络中的罚没（slashing）机制，对于Staking参与者（尤其是自己亲自参与的），你需要了解哪些情况会导致罚没，以及如何避免被罚没。本文档中提供的大多数信息与客户端选择无关，这意味着它将适用于所有用户，而不管他们选择运行Prysm、Lighthouse、Teku、Nimbus还是其他以太坊2.0客户端。

原文作者是Prysmatic Labs联合创始人Raul Jordan。

*重要免责声明*

Prysmatic Labs对用户的资金损失不承担任何责任，无论原因是什么，包括客户端漏洞或文档错误，这种责任的免除延伸到了罚没过程。尽管每个以太坊2.0客户端都尽最大努力确保代码库是安全的，但与其他任何开发项目一样，总是会存在出错的可能性。参与以太坊2.0是一项有风险的活动，重要的是参与者需要研究并理解他们要承担的风险及责任。

什么是罚没（slashing）？

当一个验证者表现出与以太坊网络相争对的行为时，就会发生罚没。罚没不一定是因为有恶意意图，它也有可能是因为错误的配置。验证者的行为可能会使得系统变混乱，或破坏其完整性，因此，这些对网络造成危害的验证者，其质押的ETH就会遭到惩罚，而这是不可逆转的。

不要将罚没和不活动处罚混淆，罚没的目标是抑制那些试图伤害以太坊2.0网络的人，并反过来奖励那些按计划维护、管理和运营以太坊2.0网络的人。罚没的的主要目的是减轻在以太坊2.0网络上执行的攻击，例如在不同的历史检查点视图上创建相互冲突的验证者分支。

正确遵循协议的验证器在正常操作中永远不会发出可遭到罚没的投票，验证器不会因为离线而遭到罚没。

罚没的工作方式

罚没的行为会破坏掉那些伤害以太坊网络的验证者的质押资金，强迫他们离开网络，并通过促进好的参与者来加强区块链的安全性。

尽管罚没是一种惩罚方式，但即便是一个正常用户，如果其验证器配置不正确，仍有可能遭到罚没 。因此，了解如何正确设置和管理验证器客户端和操作系统是至关重要的，用户还应避免在不了解其全部功能的情况下尝试使用高级指令。

在以下情况下，验证者会遭到罚没：

1. 验证器在同一个slot中使用不同的root（本质上内部数据的哈希）提出两个冲突的区块。如果这类操作没有遭到惩罚，那么验证者就很容易创建不必要的分叉，或造成混乱。注：简单地提出相同的区块两次，并不会遭到罚没；
2. 验证器在同一个slot中证明两个冲突的区块。这被称为双重投票，也意味着验证者可能试图创建冲突的链分叉。注：简单地为相同区块投票两次，并不会遭到罚没；
3. 验证器投出的投票“包围”（surround）或被之前的投票“包围”，这意味着验证者试图投票反对历史，这种情况下就会遭到罚没；

（以太坊2.0 surround 投票，来自https://github.com/protolambda/eth2-surround）

遭到罚没后，会发生什么？

尽管存在多个防止罚没的机制，但每个验证器密钥对仅被一个验证器使用是至关重要的。 这听起来很容易，但是当配置了多个验证器时，很容易错误地还原验证器并复制已经运行的验证器。进行更改时，请始终确认正在使用/恢复/设置正确的验证器密钥。

你可以在这里（ 1 、 2 ）找到一些其他资源。

如果验证器遭到罚没，则会发生很多事情：

1. 遭到罚没的验证器被迫在36天内退出信标链；
2. 遭到罚没的验证器会面临三种惩罚类型（ 来源 ）；
3. 当被提议的举报人在一个区块中包含举报信息时，将受到最低处罚；
4. 在每个epoch周期开始进行惩罚，直到验证器离开退出队列；
5. 在举报信息被包括在一个区块内，以及遭罚没的验证器退出之间的中间时间，将实施特别处罚，这一特殊处罚与在此期间有多少其他验证器遭到罚没成比例。所适用的最大值，可达到相关罚没对象的所有有效余额。

这意味着，如果验证器遭到罚没，它会立即受到惩罚，并将持续受到约36天的处罚，直到其可以退出为止，并且在18-36天的时间内，还会受到一次性罚款，而罚没的金额还受到同一epoch时期遭罚没的验证器数量的影响（即判定这是一次次协同攻击，还是单独的攻击） 。有关更详细的说明，请访问 此处 。

最后，值得注意的是，遭到罚没的验证器无法重新进入验证器集。 如果验证者要继续验证，就需要进行新的质押以及生成新的密钥，而罚没是不可逆的！

总的来说，遭到罚没会导致你质押的ETH不断变少，并在中途遭受重大损失。在36天后，你可以退出信标链，也可以撤回所有剩余的ETH，而在这36天的时间段内，你会损失很大一部分的ETH。

会导致罚没的常见用户错误

尽管上面提到的罚没场景对普通用户而言似乎是不可能发生的，但不正确的配置，很可能会导致诚实的验证者也会遭到罚没！以下是一些可能发生这种情况的场景：

1、相同的验证密钥同时运行在两个服务器上，其中一个可能用作故障转移，以防第一个服务器出现故障。

说明：这是最容易让你遭到罚没的方式，如果你的故障转移系统误报第一个节点已关闭，你可能会发现自己处在遭遇罚没的境地。

请不要同时在两个地方运行验证密钥！

2、你把密钥迁移至另一台计算机或另一个以太坊2.0客户端，而没有迁移你的罚没保护历史记录；

说明：你的另一个节点可能有一个不正确同步的时钟，这可能会导致你遭遇罚没，如果你迁移了罚没保护历史记录，就可以轻松避开这种情况。

3、你在验证器客户端中删除或丢失了罚没保护历史记录 ；

说明：失去罚没保护历史记录，可能会导致一些问题，比如你的时钟被弄乱，从而产生会遭到罚没的区块或投票。

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

说明：如果你使用Docker运行，或者可能在云环境（如Kubernetes）中运行，则需要为验证器设置持久卷（PV），这样，如果pod或容器重新启动，则不会清除罚没保护历史。

5、可能导致罚没错误的协议漏洞（这种情况不太可能发生，而它会是最糟糕的情况）

说明：测试网上发生的大规模罚没事件的催化剂，通常是由于客户端实现中的漏洞。但是，具有罚没保护数据库和正确配置的验证器并没有受到影响。这些示例包括时间服务器故障以及区块ID处理不当的错误。当Medalla测试网中发生服务器故障时，大多数验证器都遭到罚没了，因为它们没有一个持久化的罚没历史数据库。

选择验证器时，了解如何设置、配置，升级和排除任何已安装软件的故障是至关重要的。在 这里 （ ethereumprice.org）可以找到一个很好的资源来更好地理解参与以太坊2.0 Staking的风险， 这里 还有另一个解释如何检测罚没条件的资源。

谁在实行罚没？

罚没者（Slasher）

罚没器（Slasher）是指一个单独的软件，其主要目的是检测可罚没的事件。你可以把罚没器（Slasher）想象成以太坊2.0网络的“警察”，由于检测恶意消息所需的额外数据和进程，通常这些罚没器是独立于信标节点运行的。为了检测可罚没的消息，罚没器记录网络上每个验证器的证明和提议历史记录，并将该历史记录与广播的内容交叉引用，以找到可罚没的消息，例如双重区块或surrounding投票。

网络所需要的是一个诚实的罚没器客户端来监视网络，因为发现的任何罚没都会传播到整个网络，以便尽快将其放入一个区块中。

举报人奖励

为了激励罚没检测，验证器将获得一种“举报人奖励”，这是在信标链上对提交具有任何有效罚没的区块的奖励。这些奖励是给予那些参与罚没的验证者的，通常每个验证者大约有0.1 ETH奖励。

虽然激励检测是有价值的，但如果你在Prysm中发现了罚没，仅运行一个罚没器客户端是不会获得举报人奖励的。默认情况下，发现的任何罚没都会广播到网络以尽快包含在区块中，因此，通常在检测到罚没后，奖励会立即发给提议者，而不是发给运行罚没器的验证者。

运营一个罚没器并不意味着有利可图。罚没本就是罕见的，举报人奖励也被设置地很低。本质上，运营罚没器相当于一种利他行为，再次强调，网络中只需激活一个诚实的、功能正常的罚没器，即可捕获到违规行为。幸运的是，这是低门槛的，我们设想会有相当多的用户和实体将运行罚没器来确保网络安全。

罚没预防针

我们有好消息要告诉大家，罚没是可以预防的！有很多最佳实践可确保我们不会遭到罚没，但重要的是要了解它们。

1、本地罚没保护数据库

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

需要注意的是，本地罚没保护无法防止使用相同的验证器密钥运行多个验证器实例。

该数据库仅跟踪该本地实例中验证器的签名事件。这也意味着，如果用户将其验证器更改为其他客户端（例如，从Lighthouse迁移到Nimbus），或转移到新的硬件设置（在新的linux机器上安装，迁移到托管解决方案），那么还必须迁移签名历史数据库。这将确保在任何新客户端上保留过去操作的历史记录。

2、远程罚没保护

防止罚没的另一种替代实现方式是使用罚没器（slasher）。罚没器记录它收到的所有证明和区块，验证器在同意签署消息之前会引用它。与本地签名历史数据库相比，这种方法是一种更强的罚没保护方式，但与数据库一样，此方法无法防止运行同一验证器的多个实例。

防止罚没的另一种实现，是将罚没器本身用作信标节点和验证器客户端之间的中间件。在验证器客户端提交区块或证明之前，它首先询问罚没器这是否是可罚没的。

如果检查通过，数据将通过信标节点。这是最先进的罚没保护形式，因为理想情况下，罚没器了解网络中发生的所有事件，并记录了每个验证器的区块和证明历史。但有一点需要注意的是，在Prysm中，远程罚没保护还没有优化，因为我们的罚没器仍然是资源消耗大户。鉴于我们的罚没器资源消耗很高，这可能会导致你的验证器错过证明或区块。远程罚没保护旨在作为本地罚没保护之上的附加层运行。 出于安全原因，用户无法在Prysm中禁用本地罚没保护。

3、迁移你的罚没保护历史

在验证过程中的某个特定时刻，质押者可能需执行的一个重要活动，是将其验证密钥迁移到另一台机器或不同的以太坊2.0客户端。

有时，你可能希望切换Staking机器，或者你可能希望迁移到适合你的不同的以太坊2.0客户端。无论如何，你都应始终携带好你的罚没保护记录。

罚没保护标准：EIP-3076

目前有一个官方标准用于迁移以太坊2.0客户端之间的罚没保护历史记录，它被称为 EIP-3076 。该标准建议在JSON文件中表示验证器的罚没保护历史记录。该文件包含了：

1. 有关验证历史记录的链的初始状态信息（用于区分测试网和主网）；
2. 有关用户正在运行的验证器公钥的所有签名区块以及签名证明信息；

通过导出此文件，并在迁移到另一台计算机或以太坊2.0客户端时导入它，你将获得大量好处，并能够免受未存储此本地历史记录的情况下的简单罚没条件。

将现有的验证密钥导入Prysm

截至发稿时，在Prysm的v1.0.1版本中，Prysm不允许用户将EIP-3076 罚没保护JSON文件导入验证器客户端。这是Prysm团队的首要任务，可能会在以太坊2.0主网上线后的下一个版本中实现这个功能。

从Prysm导出你的罚没保护历史

截至发稿时，在Prysm的v1.0.1版本中，Prysm不允许用户将罚没保护历史记录导出到EIP-3076 罚没保护JSON文件中，同样的，Prysm团队正在抓紧实现这一目标。

如果你确定希望迁移机器，我们建议你等到Prysm支持导出罚没保护历史记录之后。如果实在等不及，请记住以下一些重要事项：

1. 关闭你的信标节点以及机器1上的验证器，确保它没有作为系统进程运行。你可以使用操作系统的进程监视器工具或命令行工具（例如top或htop）进行检查，并检查是否包含名称“ prysm”，“ validator”或“ beacon”。
2. 请注意你的钱包目录位置。 如果你在启动Prysm时使用默认值，则可以在“验证者帐户列表”输出的顶部查看其路径，该路径因操作系统而异。
3. 获取整个目录并将其迁移至你的下一台计算机。
4. 如果你修改了验证器的datadir，也请将该目录迁移到下一台计算机。
5. 至少等待几个epoch时间段，在第二台机器上同步信标节点，然后在第二台机器上启动验证器客户端。
6. 确保不在机器1或其他任何地方运行相同的密钥 。