Combining GHOST and Casper以太坊2.0共识机制Gasper：part 1

共识机制设计理念

正如以太坊基金会成员Vald zamfir， 所说的Casper的设计出发点，源于对系统 最差情况的经济分析， [...

共识机制设计理念

正如以太坊基金会成员Vald zamfir， 所说的Casper的设计出发点，源于对系统 最差情况的经济分析， 这也是是公链PoS共识算法的 唯一路径 。也因此，Casper希望通过引入惩罚措施来最大化拜占庭容错。

并且，Casper是为轻节点而生，为此需要提供两大特性：

• 最终性（敲定的块就不能再改了）
• 低延迟

那么针对这些特性，就需要在指定分叉规则的同时，还要有最终性的共识算法，那么这该如何解决呢？

在2020年5月修改版的《 Combining GHOST and Casper 》一文中，V神的团队给出了详细的答案及解释。

设计目标

Eth2.0的共识算法设计目标就是让PoS就有 一定的安全性和可用性 (certain safety and liveness claims).

对应着这个目标，提出了两大组件来定义分叉规则和最终性：

1 最终性规则Casper FFG

Buterin 和Griffith提出了Casper the Friendly Finality Gadget (FFG)，引入**验证和敲定（**justification and finalization)来定义最终性，什么意思呢？其实有点像检查点，简单来说就是，在特定的区块高度需要有验证节点的签名信息A->B（其中A，B代表检查点区块），表明我A举手赞成B成为下一任党委书记，也就是赞成B成为下一个检查点，这样就不要再从创世区块去算状态保证安全性了，因为检查点之后的就改不了了。道理其实很简单，当上了党委书记就有话语权了，政策就不能再由着下面的人乱改了嘛。

同时，Casper也引入了 惩罚条件 (slashing conditions),来判定谁是坏人谁是好人，违反这两个规则的人就得被开罚单：

1. 验证者对同一个高度的检查点，只能给一个完全一致的证明
2. 验证者在两个不相邻的检查点之间只能给一个完全一致的证明，也就是说这两个检查点之间的检查点不能再给不一样的证明了

可以看出，Casper只是规定了检查点是怎么确定下来的，也就是说最终性是如何确定的，而把分叉规则单独最为一个组件，这么做也是为了解耦这两部分。

2 分叉规则LMD GHOST

LMD由Sompolinsky等人提出的The Greediest Heaviest Observed SubTree rule (参见通俗的解释 GHOST )改进而来，由于PoS的共识算法需要消息驱动来获取投票的权重，因此称之为Latest Message Driven Greediest Heaviest Observed SubTree(LMD GHOST).

算法如下所示：

LMD GHOST算法规则

举例来说就是，假设每个人拥有一个stake代表一票的权重（下图中用圆圈表示），那么按照这个算法就确定了途中蓝色的主链：

LMD GHOST举例

那么这两个协议是如何结合到一起的呢，以太坊提出了Gasper(Ghost第一个字母G+Casper的后四个字母）协议：

Gasper

为了理解Gasper，我们先要了解三个基本概念：

• 纪元边界(Epoch boundary):Gasper把12秒定义为了一个基本 时间槽(slot) ,然后把64个slot定义为一个**纪元(epoch).**那么每个纪元开始的那个区块就成为边界区块，用EBB(B,j)=C表示，第j个epoch的区块B的边界区块是区块C
• 委员会：所有的验证者被分配到每一个epoch中，构成了一个大的委员会，并且对于每一个slot从这个大的委员会选出 一个特定 的委员会。再每一个slot中，由一个验证者来打包出块，该委员会的其他成员使用HLMD GHOST（LMD GHOST的一个轻微变种，后面会讲）附上认可这个区块的证明。
• 验证和敲定(Justification and Finalization)：这个其实和Casper FFG很像，不过这里不是对单个检查点操作，而是对所有的纪元边界区块进行操作。

纪元边界区块验证

验证规则定义，如果这个投票的总和大于总staking的2/3，那么就认为边界区块被验证了。

具体而言，对于下面的例子：

这是一个验证者的视图，由于网路延迟等问题，他之前很多区块没收到，因此64号区块就是193号区块Epoch1和Epoch2的边界区块，因此他再这里写入投票 α **，表示(64,2)是(180,3)的边界区块。同时根据GHOST规则可以看出需要投193号区块为当前的链头。

敲定

而敲定相对于验证是一个更强一点的概念，如果说区块B0构成的边界区块(B0,j)被敲定了，那么要么他是创世区块，要么存在一个k>=1的数满足以下三个条件：

1. (B0, j), (B1, j + 1), . . . , (Bk, j + k) 是相邻的epoch边界
2. (B0, j), (B1, j + 1), . . . , (Bk−1, j + k − 1) 都已经被验证了
3. (B0, j)被 (Bk, j + k)验证了

其实总的来说就是B0，需要被其他区块验证！

举个例子：

蓝色的区块代表被敲定了，带箭头的边表示被验证了（思考k=2时，B1为什么没有被敲定？）

分叉规则Hybrid LMD GHOST（HLMD）

验证了边界区块之后，只要没有超过1/3的攻击者stake就不能篡改这个区块，在这个假设基础上就能唯一确定边界区块，从而定义epoch内部的分叉规则了，算法如下：

这个算法思路其实表简单，就是先选取最新验证的epoch边界区块Bj，然后再根据GHOST规则来找到当前主链的链头区块。

细心的你可能发现这里有个问题就是，最新被验证的区块可能会变，因为 被验证了不等于finalize了 ，只要还没被完全敲定就有可能会变；同时， 每个验证节点的视图可能不一致 ，就导致我们自己的这个区块Bj可能跟别人的不一样！

那么对于这两个问题如何解决呢？还有整个系统的安全性和可用性如何呢？且听下回分解...

共识机制设计理念

正如以太坊基金会成员Vald zamfir， 所说的Casper的设计出发点，源于对系统 最差情况的经济分析， 这也是是公链PoS共识算法的 唯一路径 。也因此，Casper希望通过引入惩罚措施来最大化拜占庭容错。

并且，Casper是为轻节点而生，为此需要提供两大特性：

• 最终性（敲定的块就不能再改了）
• 低延迟

那么针对这些特性，就需要在指定分叉规则的同时，还要有最终性的共识算法，那么这该如何解决呢？

在2020年5月修改版的《 Combining GHOST and Casper 》一文中，V神的团队给出了详细的答案及解释。

设计目标

Eth2.0的共识算法设计目标就是让PoS就有 一定的安全性和可用性 (certain safety and liveness claims).

对应着这个目标，提出了两大组件来定义分叉规则和最终性：

1 最终性规则Casper FFG

Buterin 和Griffith提出了Casper the Friendly Finality Gadget (FFG)，引入 验证和敲定（ justification and finalization)来定义最终性，什么意思呢？其实有点像检查点，简单来说就是，在特定的区块高度需要有验证节点的签名信息A->B（其中A，B代表检查点区块），表明我A举手赞成B成为下一任党委书记，也就是赞成B成为下一个检查点，这样就不要再从创世区块去算状态保证安全性了，因为检查点之后的就改不了了。道理其实很简单，当上了党委书记就有话语权了，政策就不能再由着下面的人乱改了嘛。

同时，Casper也引入了 惩罚条件 (slashing conditions),来判定谁是坏人谁是好人，违反这两个规则的人就得被开罚单：

1. 验证者对同一个高度的检查点，只能给一个完全一致的证明
2. 验证者在两个不相邻的检查点之间只能给一个完全一致的证明，也就是说这两个检查点之间的检查点不能再给不一样的证明了

可以看出，Casper只是规定了检查点是怎么确定下来的，也就是说最终性是如何确定的，而把分叉规则单独最为一个组件，这么做也是为了解耦这两部分。

2 分叉规则LMD GHOST

LMD由Sompolinsky等人提出的The Greediest Heaviest Observed SubTree rule (参见通俗的解释 GHOST )改进而来，由于PoS的共识算法需要消息驱动来获取投票的权重，因此称之为Latest Message Driven Greediest Heaviest Observed SubTree(LMD GHOST).

算法如下所示：

LMD GHOST算法规则

举例来说就是，假设每个人拥有一个stake代表一票的权重（下图中用圆圈表示），那么按照这个算法就确定了途中蓝色的主链：

LMD GHOST举例

那么这两个协议是如何结合到一起的呢，以太坊提出了Gasper(Ghost第一个字母G+Casper的后四个字母）协议：

Gasper

为了理解Gasper，我们先要了解三个基本概念：

• 纪元边界(Epoch boundary):Gasper把12秒定义为了一个基本 时间槽(slot) ,然后把64个slot定义为一个 纪元(epoch). 那么每个纪元开始的那个区块就成为边界区块，用EBB(B,j)=C表示，第j个epoch的区块B的边界区块是区块C
• 委员会：所有的验证者被分配到每一个epoch中，构成了一个大的委员会，并且对于每一个slot从这个大的委员会选出 一个特定 的委员会。再每一个slot中，由一个验证者来打包出块，该委员会的其他成员使用HLMD GHOST（LMD GHOST的一个轻微变种，后面会讲）附上认可这个区块的证明。
• 验证和敲定(Justification and Finalization)：这个其实和Casper FFG很像，不过这里不是对单个检查点操作，而是对所有的纪元边界区块进行操作。

  纪元边界区块验证

验证规则定义，如果这个投票的总和大于总staking的2/3，那么就认为边界区块被验证了。

具体而言，对于下面的例子：

*这是一个验证者的视图，由于网路延迟等问题，他之前很多区块没收到，因此64号区块就是193号区块Epoch1和Epoch2的边界区块，因此他再这里写入投票 α ，表示(64,2)是(180,3)的边界区块。同时根据GHOST规则可以看出需要投193号区块为当前的链头。*

敲定

而敲定相对于验证是一个更强一点的概念，如果说区块B0构成的边界区块(B0,j)被敲定了，那么要么他是创世区块，要么存在一个k>=1的数满足以下三个条件：

1. (B0, j), (B1, j + 1), . . . , (Bk, j + k) 是相邻的epoch边界
2. (B0, j), (B1, j + 1), . . . , (Bk−1, j + k − 1) 都已经被验证了
3. (B0, j)被 (Bk, j + k)验证了

其实总的来说就是B0，需要被其他区块验证！

举个例子：

蓝色的区块代表被敲定了，带箭头的边表示被验证了（思考k=2时，B1为什么没有被敲定？）

分叉规则Hybrid LMD GHOST（HLMD）

验证了边界区块之后，只要没有超过1/3的攻击者stake就不能篡改这个区块，在这个假设基础上就能唯一确定边界区块，从而定义epoch内部的分叉规则了，算法如下：

这个算法思路其实表简单，就是先选取最新验证的epoch边界区块Bj，然后再根据GHOST规则来找到当前主链的链头区块。

细心的你可能发现这里有个问题就是，最新被验证的区块可能会变，因为 被验证了不等于finalize了 ，只要还没被完全敲定就有可能会变；同时， 每个验证节点的视图可能不一致 ，就导致我们自己的这个区块Bj可能跟别人的不一样！

那么对于这两个问题如何解决呢？还有整个系统的安全性和可用性如何呢？且听下回分解...