AD
一文看2020区块链与数字货币：币圈过去一年都发生了什么变化？
在将要过去的2020年，我们看到围绕比特币等数字资产的生态环境（币圈）发生了巨大变化，直接的感受是比特币价格过去一年上涨接近3倍，达到历史新高的2.7万美金，以及稳定币发行规模扩大3.5倍，达到历史新高的270亿美元。
验证者与验证者客户端验证者是信标链相关的观点，一个验证者即是信标链共识历程的一个介入者。验证者之间以公钥来区别身份，而且每个验证者都市在差别时间被分配以验证信标链的义务。乐成完成这些义务，就能获得夸奖；反之，若是失职，不仅得不到奖励，还会受到严肃的责罚。在 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。
加入新手交流群：每天早盘分析、币种行情分析
添加助理微信，一对一专业指导：chengqing930520
上一篇：羁系与去中央化是否有冲突，两者能否共存？
加入新手交流群：每天早盘分析、币种行情分析，添加助理微信
一对一专业指导：chengqing930520
最新资讯
