验证者与验证者客户端
验证者是信标链相关的概念，一个验证者即是信标链一致进程的一个参与者。验证者之间以公钥来差异身份，而且每个验证者都会在不同时间被分配以验证信标链的使命。成功完成这些使命，就能获得奖赏；反之，假如渎职，不只得不到奖赏，还会受到严峻的赏罚。在 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
翻译: 阿剑
视野开拓
“于是伊斯霍玛霍斯开始讲道：‘苏格拉底，有一天我看她脸上已经化好了妆：她已经擦上了粉，好使她显得更白些，她已经抹上胭脂，好使她的脸蛋更红些。她还穿一双厚底靴子以增加她的高度。于是我和她说“亲爱的，请问你，作为我们财务方面的一个合作者，我怎样才能更值得你爱我：是应该按照真实情况告诉你我们所有的东西，既不虚夸也不隐瞒其中任何部分呢？还是应该设法言过其实地欺骗你，用劣币和镀金的项圈哄骗你，并把会褪色的衣服说成是货真价实的紫袍呢？”’”-《经济论 雅典的收入》
