【摘要】 编者注：本文为 Taipei Ethereum Meetup 社区成员邱骏的译作，译自 2018 年 8 月 Vitalik 介绍 Casper 发展历程的长推特。一年过
编者注：本文为 Taipei Ethereum Meetup 社区成员邱骏的译作，译自 2018 年 8 月 Vitalik 介绍 Casper 发展历程的长推特。一年过去，Eth2.0 的分叉选择规则已确定为 LMD Ghost，而非 Vitalik 在该长推特中表示偏爱的 IMD Ghost，但文中提到的 Casper 的观念演变史，仍足一观。
前言
以太坊针对 PoS 共识模型的研究最早始于 2014 年，这些研究后来演变成目前广为人知的 Casper the Fridenly Finality Gadget(FFG) / Correct by Construction(CBC)两种共识模型，它们分别由两个不同的团队开发且存有不少差异。
Vitalik 用一系列推文简述了从 2014 以来 Casper 的开发脉络，由于中文社群仍缺乏针对 Casper 开发路线相关的总结，因此译者特将此系列推文翻译成中文并且补上一些注解，希望可以成为开发者或研究员在学习 Casper 时的重要文献，并期望读者对 Casper 设计理念有更直觉的理解。
为了避免读来生硬，建议读者先大略掌握 PBFT / Casper FFG / GHOST 的重要概念，PBFT 的部分可以参考译者的这篇文章：若想搞懂区块链就不能忽视的经典：PBFT。最后要特别感谢以太坊基金会研究员梁智程(Chih-Cheng Liang)提供诸多素材与协助校阅。
以下正文开始。
简介
我将要用一系列的推文来解释以太坊 Casper 共识协定的研究历史/脉络/进展，包括 FFG vs CBC 的争论、混合模型到完全 PoS 的转换、随机性扮演的角色、共识机制的设计考量以及其他议题。
无利害关系问题与远程攻击
以太坊的权益证明研究始于 2014 年 1 月的 Slasher 协定。虽然 Slasher 演算法并不是非常理想，但它引入了一些重要观念，特别是利用罚金来解决「无利害关系问题(Nothing-at-Stake Problem)」。然而，我所使用的罚金相当少，单只取消投票奖励。Vlad Zamfir 于 2014 年中加入了，他迅速引入验证者必须押金的方法。押金是比奖励还大的数字，做出错误的行为将会使押金被取走(这里是 Vlad 的覆述)。
我们花了 2014 下半年的大部分时间试着解决「远程攻击(Long-Range Attack)」，攻击者可以将他们的押金从主链提领出来，并且形成另一条具有更多签名的攻击链，如此欺骗新加入的节点，让他们以为攻击链是一条主链。如果攻击链与主链分叉的时间点距离当前相当近，攻击链不会造成问题，因为验证者若在两条链上同时对两个互相抵触的讯息签名，则这个签名可以当成惩罚验证者的证据来没收押金;但是若分叉发生在很久之前(因此被称为远程攻击)，攻击者可以取出押金以避免被没收。
我们最后得出：远程攻击是无法避免的，原因大致跟 PoW 拥护者所说的差不多。然而，我们没有接受他们的结论。因为我们发现：我们可以引入两个额外的安全假设来解决远程攻击：1.节点至少每 4 个月要登入一次(押金要花 4 个月提领);2.节点直接拒绝 4 个月以上的回溯。
这对 PoW 拥护者来说是个令人厌恶的肉中刺，因为这感觉是一个「信任假设」：每一次同步区块时，你必须先信任某个来源以取得区块链。但是对我们这些龌龊的主观主义者来说，这不是大问题：不管在哪一种情况，你都需要某个可信来源告诉你区块链所使用的共识规则(也别忘了软件更新)，所以 PoS 所需的额外信任并不大(这里是 Vlad 的覆述)。
确立了押金及罚金的使用后，我们接下来要决定它们「是什么」。我们知道我们希望的是「经济敲定性」，验证者将会基于以下方式对区块签名：一旦一个区块被敲定，如果要敲定一个冲突的区块，则必须要有大部分的验证者签出与自己先前讯息冲突的讯息。但对于这样的讯息，可以被链侦测并惩罚。
我写了一篇又臭又长又离题的「赌注共识」文章。赌注共识是一个有趣的提案：验证者下注哪一个区块会被敲定，而赌注决定了哪一个链会形成共识。PoW 也具有这样的性质，因为挖矿是一种赌注。如果你赌注在对的链上，你会获得奖励;如果你赌注在错的链上，你失去挖矿成本。
但在 PoS 我们可以有更高的赔率：验证者的赔率一开始很低，但是随着验证者看到彼此对于某个区块的信心逐渐增加，所有人的赔率都会平行地指数上升，直到所有人都赌注同一个区块，这就是敲定。
Casper CBC
同时，Vlad 开始大量研究机制设计，特别是让 Casper 更能抵抗寡占。我们也开始研究受到古典拜占庭容错(BFT)启发的共识，例如 Tendermint。Vlad 认为古典 BFT 并没有说服力(他特别不喜欢 BFT 当中的硬门槛，例如 2/3 的 PBFT 节点必须为诚实节点)，他想透过一个他称为「正确建构(Correct by Construction, CBC)」的方法尝试重新发明 BFT( Vlad 的原话：连结 1 / 连结 2 / 连结 3)。
正确建构的哲学与传统 BFT 相当不同的点在于「敲定」是完全主观的。CBC 的哲学是，验证节点对讯息签名，且若他们签了与他们先前的讯息相抵触的讯息，则他们必须提交一个「辩护(Justification)」以证明他们投票的新讯息与旧讯息相比之下有较多的支持，以取得「转换」的权利。
为了侦测敲定性，节点寻求讯息的模式。这些讯息可以证明，多数验证节点以一种方式可靠地对某区块 B 投票，且偏离 B 必须大部分验证者非法转换投票。例如，若所有节点投给 B，则所有节点都投给「包含所有人对 B 的投票的区块」，这证明了他们支持 B 且知道其他所有人都支持 B，因此他们不会有转换的合法理由。
最后我放弃了赌注共识，因为这个方法似乎有根本上的风险。我也回头试着理解 PBFT 是怎么运作的。虽然这花了一点时间，但过了几个月后我搞懂了。
Casper FFG
我试着简化了 PBFT，将其放入区块链的脉络，并把它描述为 4 个「砍押金条件(Slashing Condition)」，这些规则阐述哪些讯息的组合是自我抵触因此违反规则的。我定义了决定区块是否敲定的规则并且证明了最关键的「安全性(Safety)」与「可行活跃性(Plausible Liveness)」：1.若某区块被敲定了，则无法在不少于 1/3 验证者违反砍押金条件下敲定另一个抵触的区块;2.若某区块被敲定了，2/3 诚实的验证者总是可以合作以敲定新的区块。
因此只要有 2/3 诚实的验证者，演算法就不会推翻之前的决定(安全性)或卡住(活跃性)。最后我将砍押金条件从 4 条简化成 2 条，并发展成 Casper FFG —— 被设计成为任何 PoW/PoS/ 其他类型区块链提供敲定性的覆盖层。
敲定性是一个非常重要的进展：一旦区块被敲定，无论网络怎么延迟都能保证安全(不像 PoW 需要多个区块确认)，而且回溯区块需要超过 1/3 验证者作弊，且可被检测出来且并销毁押金。因此，回溯敲定性的成本可能会高达数亿美元。透过不同的方式，Casper CBC 以及 FFG 都达到了这个特性。
要注意的是：Casper CBC 和 FFG 都是抽象的覆盖层，他们都需要建立在某个现有的分叉选择规则之上。用大白话讲，Casper CBC 是敲定覆盖层(上层)适应分叉选择规则(下层);而 Casper FFG 是分叉选择规则(下层)适应敲定覆盖层(上层)。
FFG vs CBC
Vlad 最初对分叉选择规则的偏好是「最新讯息驱动 GHOST(Latest Message-Driven GHOST, LMD GHOST)」 ——一种针对 PoS 的改版 GHOST;而我最初的偏好是先采取「混合式 PoS(Hybrid PoS) 」，使用 PoW 作为基底的分叉选择规则。
在最初版的 FFG 当中，PoW 将会逐个区块地运作一条链，而 PoS 将会紧随在后敲定区块;Casper CBC 从一开始就是完整的 PoS。同时，Vlad 跟我各自提出了共识诱因的理论。
这里有一个非常重要的区别是「唯一可归责错误(Uniquely Attributable Faults)」——你可以知道出错时谁应该负责而被惩罚，以及「非唯一可归责错误(Non-uniquely Attributable Faults)」——一个错误可能是多方中的一方造成的。一个非唯一可归责错误的经典案例是离线 vs 屏蔽(Censorship)，也称为「言者-听者错误等效性」(译按：到底是言者没讲，还是听者没听到，无法判定是谁的错)。
惩罚唯一可归责错误(Casper FFG 砍押金条件)是容易的;惩罚非唯一可归责错误则是困难的。如果你无法分辨区块停止敲定是因为少数的节点离线或是因为多数的节点正在屏蔽少数会怎么样?针对这个议题目前有三种解法：1.轻微地惩罚两边;2.严厉地惩罚两边(Vlad 的偏好);3.将链一分为二，各自惩罚两条链的其中一边，且让市场决定哪条链较有价值(我的偏好)。或者可以参考我写的这篇。
2017 年 11 月，我把 Casper FFG 砍押金条件以及对由于「平方溢金(Quadratic Leak)」(译按：随着离线时间增加，对押金的少量扣减会平方增加)导致的 1/3 节点离线的问题的解法写成论文。
当然，我非常清楚诉诸社交层面来解决 51% 攻击并不是很好，因此我开始寻求至少能让链上节点能自动侦测「合法链」与「攻击链」的方法。这是一个早期的想法。这想法还不错，但是仍不是最理想的，除非网络毫无延迟，否则它只能保证节点之间嫌疑分数差异的上限，而并非所有节点完全同意。
同时，我对 Vlad 的模型的主要批判与「泄气攻击(Discouragement Attacks)」有关，攻击者可以有效威胁要制造 51% 攻击来造成所有人损失金钱，因而驱使所有其他人退出，因此只用极低的成本便能主导链。Vlad(以及 Georgios Piliouras)开始建立经济模型以评估在他的模型之下进行上述攻击的实际成本。
值得一提的是，上述所有的议题并非为 PoS 独有。事实上在 PoW 中，人们倾向直接放弃且假设预防 51% 攻击几乎不可能，且 51% 攻击是必须不计代价避免的末日。但是，如同以太坊的传统，Vlad 与我误把「有野心的」这个词当成赞美，而继续研究减缓以及恢复 51% 攻击的不同方法。
2018 年初，Vlad 在 CBC 的研究开始快速推进，包括安全性证明的进展。—看这个史诗般的 2 小时简报以跟上 2018 年 3 月为止的研究进度同时，Casper FFG 也有了重大进展，以合约的方式实现的决定使开发工作变得容易。2017 年 12 月 31 日，我们发布了 Python 版的测试网。
Casper 与分片开发路线的整合
不幸的是，FFG 的开发慢了下来。以合约实现 FFG 虽然把一些事情变得更容易，却让未来要从 EVM 转到 EWASM 以及从单链 Casper 转到分片 Casper 的工作变得更困难。此外，团队的研发工作被分成「主链 Casper」和「分片链 Casper」，可想而知在这两个团队之间产生了大量不必要的重复工作。
2018 年 6 月，我们做了一个重大的决定：放弃以合约实现的 Casper FFG，取而代之的是追求以一条独立链运作的 Casper，如此的设计将使分片变得更加容易。
完全 PoS 的转换导致我开始更认真思考 PoS 的分叉选择规则。Casper FFG 与 CBC 都需要全部的验证节点在每个「时期(Epoch)」投票以敲定区块，这代表每秒将会数以万计的签章传向每个验证节点。BLS 签名聚合使其在计算成本上是可行的。但是我想试着利用这些额外的签名以让链更加稳固，在几秒内取得等同于「100 个确认」的安全性。这里是我初步的想法(连结 1/ 连结 2)。
然而，所有这些分叉选择的方法都有一个缺点：它们都将验证节点分为「见证节点(Attesters)」与「出块节点(Proposers)」，而这些负责产生区块的出块节点拥有过大的权力。这样做不太好，主要是因为它需要我们有一个很安全的链上随机数生成器以公平地挑选出块节点，而链上随机数生成器很困难，而且一些简单的方法例如 RANDAO 似乎有愈来愈多问题。
Justin Drake 跟我开始解决这个问题：Justin 使用 VDF，这是一个输出具有确定性与可验证的函数，但需要大量不可平行化处理的序列时间进行运算，使提前窜改变得不可能;而我对 Vlad 教妥协，使用基于 GHOST 的分叉选择规则以大幅减少对出块节点的依赖，允许在恶意出块节点大于 90% 且诚实见证节点大于 50% 的状况下，链仍能不受干扰地成长。Vlad 很开心，但还没开心到极点：他偏好 LMD GHOST，而我偏好 IMD GHOST。
大约同一时间，我也试着想出一个方法来「流水线化」(Pipelining)Casper FFG，将敲定时间从 2.5 个时期减至理论上最佳的 2 个时期。我对 RPJ 分叉选择规则(后来更名为 IMD GHOST)能够很好地相容于 FFG 这件事感到开心。它还有一个很重要的「稳定性」：分叉选择是一个对未来分叉选择的好预测。
这看起来很明显，但我们却很容易做出不具有这种特性的分叉规则。最近的进展是：LMD GHOST 可能由于技术细节只能在 2 回合中有 25% 容错，但是 IMD GHOST 仍可以有完整的 33% 容错(目前没有文件)。(译按：在译文完成时，以太坊 2.0 采用的是LMD GHOST)
FFG 与 CBC 之间主要的取舍是：CBC 似乎有较好的理论性质;而 FFG 似乎比较容易实现。同时，VDF 也取得了许多进展。
还有，我最近决定研究 Leslie Lamport 1982 年的老论文，在这边论文中他提出了一个共识演算法：若假设所有节点，包括观察者，皆在线上且具有很低的网络延迟，则具有 99% 容错。网络延迟的假设按理来说会使其不适合作为主要的共识算法。
然而，它可以在某一个情境运作相当良好：作为 51% 屏蔽侦测的嫌疑分数替代方案：基本上，如果 51% 共谋团体开始屏蔽区块，其他验证节点以及一般节点可以侦测到屏蔽的发生，并且使用 99% 容错的共识演算法来达成屏蔽正在发生的共识，并协调少数分叉。关于这个研究的长期目标就是要尽可能减少对社交层的依赖，并将破坏链稳定的成本最大化，使其利用社交层回溯的可能性最小化。
还有什么?FFG 的部分还有形式化证明，规格的完善，以及实现的持续进展(已经有超过 3 个团队开始着手了!)，并着眼于安全及迅速的开发。CBC 的部分也差不多。接下来让我们勇往直前吧!（Juin Chiu）
