Vitalik：以太坊 Serenity 设计依据综述 - 区块链前沿 - BitMere

Vitalik 撰文阐述以太坊 Serenity 阶段的设计依据，希望读者们在阅读本文之后，能够更进一步了解以太坊 Serenity 背后的开发者们是如何来设计这个全新的 PoS 区块链网络。以来为正文内容：

阅读本文之前，回顾一下以太坊1.0的设计依据，效果会更佳哦：

https://github.com/ethereum/wiki/wiki/Design-Rationale

1. 设计原则

● 简单性：由于与加密经济学相关的权益证明 (PoS) 和二次分片 (quadratic sharding) 本身就很复杂，所以协议本身的决策过程应该尽可能简化。这一点很重要，因为它不仅能够（i）最小化开发成本，还能（ii）降低我们无法预见的安全风险，并（iii）使用户更容易相信协议设计者，认同某种参数选择是合理的。如果你想要更详细地了解有关（iii）的哲学背景，请参见 https://radicalxchange.org/blog/posts/2018-11-26-4m9b8b/。当我们在具体的功能实现中不可避免要引入复杂性的时候，这种复杂性的首选顺序会是：第2层协议>客户端实现>协议规范。

● 长期稳定性：协议的底层部件在构建时应该尽可能地达到理想状态。如此一来，在相当长的一段时间内我们便无需考虑对底层进行变动，而是把精力集中在更高的层面（比如客户端实现或者第2层协议）上，去进行任意的创新。

● 充足性：从本质上而言，我们应该能够基于协议去构造尽可能多的任意类别的应用。

● 深度防御性：协议应该能够在各种潜在的安全假设（比如网络延迟、故障计数、用户动机等）下尽可能地持续运作

● 完全轻客户端可验证性：给定某个假设（比如网络延迟、攻击者的预算上限，1/N或者M/N的少数参与者是诚实的），验证O©数据（理想情况下只需验证信标链的数据）的客户端应该能够间接保证整个系统中的所有数据都是可用且有效的——即使在发生51％攻击的情况下也是如此（请注意：这里的51%攻击案例是“深度防御性”的一个子集）。

2. 为什么选择“最终化+保证金+罚款”模型呢？

对于诸如 Tendermint / Casper FFG / Casper CBC 这类具备传统 BFT (拜占庭容错) 风格的权益证明共识算法来说，它们与其它共识算法的竞争性及差异在于，这些算法使用的都是基于链的算法，比如点点币 (Peercoin) 和未来币 (NXT) 中都使用了这些算法。

这些算法肯定比工作量证明 (PoW) 更好。除此以外，我们认为传统的 BFT 风格的系列算法具有更强大的属性，这同时也是它们拥有强烈需求的原因。

● 极其高昂的51%攻击成本

我们希望能够建立一个强硬的机制，即任何对权益证明区块链发起51％攻击的攻击者都将要承担昂贵的费用（比如数亿美元），并且遭受攻击的链条能够从攻击中快速恢复。这将使得攻击/防御推演的结果十分不利于攻击者。事实上，发起攻击的结果可能适得其反，因为价格上涨给合法的持币者所带来的收益远远超过了服务中断所带来的损失。

在BFT系列算法中，最终化回滚攻击将产生明确的证据，该证据可用于罚没攻击者的保证金，从而实现这一目标。此外，我们还可以通过在社区中协调发起一次包含诚实验证者的少数软分叉来规避51％审查攻击。考虑到 Casper FFG 的运作机制，一旦少数派对链条发起了软分叉，多数派将必须要作出分叉选择：要么切换到正确的分叉链，并且因为自身曾经的错误选择损失一部分保证金，或者坚守攻击链，并且为此损失绝大部分的保证金。

不具备最终化特性的共识算法无法实现这些属性。

● 验证者在线率超过50%

Serenity 的分片使用了一种机制，即如果随机抽样的验证者委员会中有2/3的成员对来自某个分片中的区块进行签名，那么我们就认为该区块已被接受。这种机制本身要求平均有大于或等于2/3的验证者在线以接受任何分片区块。但如果有超过50％的验证者在线，那么我们就可以得知：除非网络中存在显然会违反协议规则的验证者，否则我们将得到某种程度的保证，即区块不会被回滚。因此，我们没有理由不添加这么一个特性。

● 解决验证者的困境

所有区块链都存在一个共同的问题，即验证者没有足够的动力去实际验证他们正在构建的区块。因为在这个均衡中，如果（几乎）每个人都是诚实的，那么对于验证者来说，这些交易根本不值得他们浪费计算资源去校验。

而在分片链中，这些问题被进一步放大了。我们可以通过（利用保管证明 Proofs of Custody）对签署无效或不可用数据的行为实施大额罚款来缓解这些问题。但是，在实际执行中，实施罚款不仅需要验证者缴纳安全保证金，还要求锁定期限足够长，以允许其他用户校验验证者所声明的数据，并在数据出现错误时对其发起质询。

3. Casper激励机制中的每个参数的设定标准是什么？

● 基础奖励

--证明中指明正确的来源，获得1/4奖励

--证明中指明正确的时期检查点，获得1/4奖励

--证明中指明正确的链头，获得1/4奖励

--证明中指明正确的分片区块，获得1/4奖励

在不同的情况中，实际奖励的计算方式如下：如果 ? 是最大奖励值，并且 ? 是执行所需操作的验证者所占的比例，那么任何执行所需操作的验证者都将获得奖励 ?*?。此外，任何未执行所需操作的验证者将遭受罚款-?。制定这种“集体奖励(即“如果有人表现得更好，那么每个人都会表现得更好”）”方案的目的是设定破坏因子的界限(想了解破坏因子的定义及重要性，请参阅：

https://github.com/ethereum/rese ... /discouragement.pdf)

需要注意的是，我们还要进一步解决两个难题：

1. 如果该证明被包含在区块链内的时间延迟了，那么奖励将减少。这是为了激励验证者及时发布证明。

2. 提议者将获得他们所包含的任意证明的奖励的1/8。这是为了鼓励提议者充分监听消息，并尽可能多地接受这些消息。

● 验证者静止漏洞

如果链条在 ???（time since finality，即达到最终化以后所经历的时间。其中，??? > 4 个时期内未能保持最终化状态，那么参与这个过程的验证者的奖励将降为零，并且第二个惩罚机制将被载入，该惩罚与 ??? 成比例。这确保了如果超过1/3的验证者陷入静止状态，那么不在线的验证者将会受到更严重的惩罚，并且惩罚随着时间的推移呈二次方递增。

► 如果你的离线行为将阻碍区块的最终化进程的话，那么你将会因为离线这一行为遭受更严重的惩罚

► 确保一旦发生超过1/3验证者离线的情况，由于离线验证者的保证金在不断减少，最终验证者的在线率会回升到2/3。

在当前的参数化条件下，如果区块无法被最终敲定，那么验证者在2.6天后将损失1％的保证金，在8.4天后损失10％，在21天后损失50％，以此类推。这意味着，如果发生50％验证者离线的情况，那么区块将在21天后重启最终化进程。

● 罚没和反相关惩罚

如果某个验证者被指证刻意违反 Casper FFG 的罚没条件，那么该验证者所承担的罚款会是在与他们大致相同的时间内受到惩罚的验证者的三倍。这么做是出于以下几个理由：

► 单个验证者作恶只会对网络造成不良影响，但如果他们选择与其他验证者同流合污，那么这些随波逐流的验证者有必要接受严厉的教训

►这一机制会对实际的攻击行为实施严厉惩罚，但对那些可能是诚实的单个孤立故障节点只实施非常轻微的惩罚

►这一机制确保较小的验证者所承担的风险要比较大的验证者的风险更少（在正常情况下，大型验证者发生故障所造成的影响相当于一堆小型验证者同时宕机的结果）

►这一机制能够有效阻止验证者“跟大队走”

● 罚没和反相关惩罚

如果某个验证者被指证刻意违反 Casper FFG 的罚没条件，那么该验证者所承担的罚款会是在与他们大致相同的时间内受到惩罚的验证者的三倍。这么做是出于以下几个理由：

► 单个验证者作恶只会对网络造成不良影响，但如果他们选择与其他验证者同流合污，那么这些随波逐流的验证者有必要接受严厉的教训

► 这一机制会对实际的攻击行为实施严厉惩罚，但对那些可能是诚实的单个孤立故障节点只实施非常轻微的惩罚

► 这一机制确保较小的验证者所承担的风险要比较大的验证者的风险更少（在正常情况下，大型验证者发生故障所造成的影响相当于一堆小型验证者同时宕机的结果）

► 这一机制能够有效阻止验证者“跟大队走”

● 保管证明

当验证者需要对某个数据为?，根为?的分片区块进行证明时，验证者需要计算出?'（其中，?'[?] =???(?[?], ????)）以及新数据?'的根?'。然后，验证者将发布一部分?'作为他们所签署的内容的一部分，并通过发布 ℎ??ℎ(????) 的形式来提交种子。在一定时限内，网络中的其它节点可以对这些信息进行质询，并要求验证者提供他们的????参数、完整的?′值以及 ? 和 ?' 的特定分支，以证明这些数据被正确构造。如果验证者在质询期开始之前提前发布????参数，那么他们将受到罚没惩罚。

构建这种机制是为了缓解验证者的双重困境。在该困境中，验证者可能会出于懒惰而拒绝验证数据，并假设所有其他验证者都是诚实的。如果大多数验证者都这么想的话，那么很可能会导致公地悲剧，最终导致链条接受无效的区块。而在这一机制中，如果验证者试图提交没有经过他们亲自处理的数据的话，那么他们将无法计算出?'（如果他们尝试外包给别人处理，那么外包方可能会背叛他们，并导致他们遭受罚没惩罚）。一旦这时有其它节点提出质询，那么这些验证节点将无法正确回应质询。出于效率原因，验证者首先只提交一部分?'。一旦验证者发布了他们的????参数，那么任何人都可以重做并检验他们的计算结果。如果该?'值不正确，那么检验者将会发动一系列质询来炮轰该数据为?′且计算不正确的区块。

4. 为什么规模是32个ETH验证者？

任何具备可审计容错特性（即如果有两个相互冲突的区块被最终敲定，你可以分辨出是哪1/3节点作恶）的 BFT 共识算法必须让所有验证者都参与其中。此外，由于技术原因，你还需要通过两轮每个验证者都参与的流程来最终敲定某条消息。

这将使我们不得不考虑去中心化/最终化时间/开销三者的权衡（原文详见https://medium.com/@VitalikButer ... adeoff-3f2011672735）：假设?是网络中验证者的数量，?是敲定区块的时间，ω是每秒钟所产生的消息传递开销，那么我们可以得到：

举个例子，如果我们能够容忍每秒钟发送10条消息的开销，那么在一个拥有10000个节点的网络中，其最终化时间至少为2000秒（约为33分钟）。

在以太坊中，如果我们假设总 ETH 供应量约为 2^27 个ETH，那么在 32 ETH 保证金规模的条件下，网络中最多有2^22个验证者（这是在每个参与者都参与验证的情况下；一般来说，我们认为参与验证的 ETH 规模要减少10倍）。如果最终化时间为2个时期（即2 * 64 * 6 = 768秒），那么这意味着每秒钟所产生的最大消息开销将为 (2^22)/768 ≈ 5461。但我们可以容忍如此高的开销。因为借助于BLS聚合方案，我们可以将每个签名的边际大小减少到1比特，并将边际验证复杂度降低到一个 ECADD 操作。

出于另一个原因，64个时隙已经是安全范围内的最小值：如果攻击者操纵用于挑选提议者的随机性，那么这个数字仍然能够提供足够的空间以确保每个时期中至少存在一个诚实的提议者，从而充分确保区块能够实现最终化。我们的计算表明：目前程度的开销是可以接受的，但更高的开销将会增加运行节点的难度。最后，当前的验证者保证金规模是实现分片交联的理想选择（详见下文）。

5. 随机抽样？

在每个时期，每个分片都会产生新的交联。这意味着，在一个由128个验证者组成的随机选择池（即“委员会”）中，有2/3验证者签署了一个表示自最新的交联以来所产生的所有数据都被包含在特定分片的哈希。而之所以选择128，是因为这个数是有效防御攻击的最小规模。我们需要防止占比小于总验证者集合1/3的攻击者在随机选择的过程中占据委员会的2/3（通过二项式定理计算，其概率为5.55∗[10^(−15)]）。

由于网络中存在1024个分片，这意味着在每个时期获取一次交联，我们就需要有131072个验证者，或者大约440万ETH押注（实际上，如果ETH的押注规模小于此数，那么交联发生的概率会降低）。如果我们提高最小保证金规模，比如提高到1024 ETH，那么这将意味着我们无法获得足够的验证者来进行交联，除非所有的ETH都押注进来。

6. LMD GHOST 分叉选择规则

信标链使用的是 LMD GHOST 分叉选择规则，具体的细节请参阅：

https://github.com/ethereum/eth2 ... in-fork-choice-rule

LMD GHOST 分叉选择规则包含来自所有验证者的信息，这些信息在每个时隙内有成百上千条。这意味着在正常情况下，哪怕回滚一个区块也几乎是不可能的。此外，由于分叉选择取决于所有的验证者，因此，除非攻击者控制了接近整个验证者集合的50％比例，否则区块根本不可能发生回滚。再者，攻击者也无法再通过操纵随机性来获得领先的优势。

7. 信标链/分片链结构

分片系统的结构的特点在于其具有一条能够协调所有活动的中央“信标链”，以及分别位于1024个分片内的链条。分片通过“交联”周期性地连接到信标链中。

(1)将分片内的所有区块直接放入信标链中，并由委员会进行签署

(2)不使用信标链，而是采用其它结构将分片链相互连接

第(1)种方案由于效率原因被否决了：我们希望分片内的出块时间是6秒钟，但是在信标链中每6秒进行1024个交联将导致信标链内产生不可接受的高负载。

第(2)种方案由于过于复杂被否决了：具有分层分叉选择特性的中心轮辐型信标链结构（先找到信标头，然后基于信标链来计算哪些分片区块是合格的，并由此确定分片链的头部）在具体实现和推理上远优于任何更复杂的结构。