信标链验证者：冗余风险和故障转移

曾汨   |   30. Dec, 2020   |   308 次阅读

验证者与验证者客户端

验证者是信标链相关的概念，一个验证者即是信标链共识过程的一个参与者。验证者之间以公钥来区别身份，而且每个验证者都会在不同时间被分配以验证信标链的任务。成功完成这些任务，就能获得奖赏；反之，如果失职，不仅得不到奖励，还会受到严厉的惩罚。在 Phase 0 阶段，这些指责仅限于在信标链上提议区块和提交见证消息。

验证者们需要使用一种叫 验证者客户端（VC）的软件来执行其职责 1。所有的信标链客户端团队都将 VC 作为他们的客户端套装软件之一。

毋庸置疑，验证者肯定希望自己的客户端能全时在线，这样才能获得最大收益、避免所有惩罚。实现高可用的常见方法是设置冗余和故障转移机制。本文会解释冗余机制给验证者带来的危险，并为信标链的 VC 提议一种合理的故障转移措施。

损失/惩罚 的类型

验证者会面临三种类型的损失，严重程度从小到大排列如下：

• 奖励落空：当一个验证者在被分配到任务时没能执行，TA 就不能获得与该任务对应的奖励。验证者的权益（本金）不会减少，只不过失去了一次获得奖励的机会。
• 怠工惩罚：如果一个验证者没有发出见证消息，而那时候信标链又不能敲定区块 2，那验证者的权益就会减少很小的一个数额（当然相关的奖励也拿不到了）。
• 罚没惩罚：若一个验证者发出了违反 Casper FFG 规则的见证消息，则该验证者会立即被 罚没 —— 该验证者的权益会减少一定的比例 3，而且该验证者会被踢出，不能再参与共识（因此也与未来的奖励无缘）。而且，因为现在信标链还不能转让和取回质押的 ETH，所以验证者剩下的钱会全部锁在信标链上、无法动用（直到信标链开启相关功能）。

（译者注：作者在此处遗漏了一种损失：当信标链无法获得终局性的时候，不仅没有发出见证消息的验证者会受到怠工惩罚，发出了消息的见证者也会有所损失，只是损失比前者更小；不过，作者在本文里主要讨论的是与验证者离线相关的损失，所以也情有可原。）

前两种损失类型是 VC 掉线的验证者可能会遭遇到的，但第三种，是只有不正确设置 VC（或者是信标链遭遇明确攻击时）的验证者才会遇到的。

那么谈到故障转移和冗余措施，最要紧的应该是尽一切可能避免罚没，然后才是提高在线时间，以减少奖励落空和怠工惩罚的概率。

冗余 VC 设施的危险性

有些质押者可能认为，运行冗余的 VC 是对某一个 VC 掉线的保险。但实际上，冗余的 VC 设施是不安全的，最终很有可能导致验证者被罚没！

来看一个实际的例子：

- 冗余的 VC 导致罚没！ -

这个验证者运行了两个客户端实例 C1 和 C2，两个都配有在线的 VC。不稳定的网络条件（对等节点/链接 问题、消息传递延迟、网络分区，等等），导致两个客户端实例对哪条分叉才是主链没有形成一致，C1 和 C2 分别以 B1 和 B2 为当前的顶端检查点（注意，是顶端检查点，而不是顶端区块，这种顶端检查点的不一致可以在没有任何恶意行为时发生）。轮到该验证者执行其验证者任务时，两个客户端实例各自发出了一条以自己所认定主链检查点为目标检查点的投票消息。结果就是这两条见证消息的目标检查点不同（但都是同一个高度）。这就是双重投票，违反了 Casper FFG 的规则，会导致该验证者被罚没。

VC 的故障转移协议

注意：我说 “故障转移”，指的是在一个 VC 停止之后手动或者自动地重启一个新的 VC 实例，但是，我不建议使用自动化的故障转移机制，因为如果实现不好，就会导致你有两个 VC 挂在线上！

上一节的要点是，验证者在任何时候都只应该部署一个在线的 VC 实例。但是， VC 总有出错的时候，怎么应对这种风险呢？质押者应该提前定义好自己的故障转移协议（决定什么使用应该重启一个新的验证者客户端实例），来应对这种情况。在开发安全可靠的故障转移协议之前，我们先来了解一种验证者客户端内置的安全特性：罚没保护措施。

- 罚没保护机制 -

罚没保护机制：所有信标链客户端团队开发的 VC 软件都有罚没保护机制，作为应对意外事件的自动防故障装置。根据罚没规则，只有成对的见证消息才会导致罚没，只需检查这一对消息就可判断结果。那么，VC 可以存储自己所签名过的所有消息和区块，存储在本地的 罚没保护数据库 里面。在签名任何新的见证消息/区块时，VC 只需检查新消息与数据库中的旧消息是否冲突（是否会形成被罚没的消息对），并且只签名不会冲突的新消息即可。

因此，VC 需要三项机制来保证正确和安全的运营：

• 完全同步的信标链节点（BN），来获得关于信标链的信息
• 验证者签名私钥，来实际签署消息
• 及时的罚没保护数据库，作为防故障装置

良好的故障转移协议必须把任一机制出错的场景都考虑进去。前两者是很容易保证的 —— 可以维护冗余的 BN 以备新的 VC 连接，而签名密钥也可以作为只读文件，从备份文件夹中复制出来。

但最后一项 —— 及时（up-to-date）的罚没保护数据 —— 不容易备份及保证可用！有很多种可能发生的错误都会导致数据库完全丢失：文件系统崩溃、硬盘故障、不可抗力造成的硬件丢失，等等。数据备份和可用性是一个价值数十亿美元的问题，现在也已经有很多方案了，例如，逐个区块/逐个文件 监控备份，RAID 可用性，等等。不过，我们有一个小技巧，可以用来重建丢失的罚没保护数据库！数据库可以按 最小化 格式重建出来，并不需要所有已签名消息的完整历史。此种重建方法的实用程序可以在 adiasg/eth2-slashing-protection-rebuild 代码库中找到。

注意：SD 卡不是可靠的存储设备，所以，在树莓派上运行 VC 的质押者特别容易丢失自己的罚没保护数据库！

我所建议的故障转移方案

一个简单但有用的办法是：维护一个冗余的 BN，并保证冗余的验证者密钥容易取得。

- 初始化的 VC 设置与多场景的故障转移协议 -

在这种设置下，多种错误都有分布对应的处理方案：

• BN 出错 —— 那就迁移到冗余的 BN 上
• 验证者密钥文件丢失 —— 从冷存储被封的密钥文件中复制出来
• 罚没保护数据库丢失 —— 重建该数据库，或者 从实时备份中恢复

密钥分割验证者

（即：实现弹性验证者设施的正确方法）

最理想的弹性设施需要密钥分割技术 —— 讲起来需要另写一篇文章了。更多信息可以在这个演讲视频中找到：https://youtu.be/awBX1SrXOhk 。

注 1：验证者 和 验证者客户端 两个概念的区别亦见于 Jim McDonald 的博客

注 2： 在当前的规范中，如果超过 4 个时段没有敲定的检查点，怠工惩罚就会出现。

注 3： 在当前规范的参数设置中，这个比例等于验证者有效余额的 1/128 ，如果验证者的有效余额为 32 ETH，则具体数额为 0.25 ETH。

---

原文链接: https://www.adiasg.me/2020/12/11/eth2-staking-failover-redundancy.html
作者: Aditya Asgaonkar
翻译: 阿剑

本文原文遵守 CC4.0 自由创作署名协议，EthFans 的译本将遵循同样的协议内容：仅保留署名权，允许自由分享和改编，不对后续使用附加其他任何条件。

---

你可能还会喜欢：

信标链 Staking 常见问题

Eth2 Staking 指南 #4：密钥

以太坊 2.0 Phase 0 的奖惩力度模拟