Eth2.0的共识算法设计目标就是让PoS就有一定的安全性和可用性(certain safety and liveness claims).对应着这个目标,提出了两大组件来定义分叉规则和最终性
正如以太坊基金会成员Vald zamfir,所说的Casper的设计出发点,源于对系统 最差情况的经济分析,这也是是公链PoS共识算法的 唯一路径。也因此,Casper希望通过引入惩罚措施来最大化拜占庭容错。
并且,Casper是为轻节点而生,为此需要提供两大特性:
那么针对这些特性,就需要在指定分叉规则的同时,还要有最终性的共识算法,那么这该如何解决呢?
在2020年5月修改版的《Combining GHOST and Casper》一文中,V神的团队给出了详细的答案及解释。
Eth2.0的共识算法设计目标就是让PoS就有一定的安全性和可用性(certain safety and liveness claims).
对应着这个目标,提出了两大组件来定义分叉规则和最终性:
Buterin 和Griffith提出了Casper the Friendly Finality Gadget (FFG),引入验证和敲定(justification and finalization)来定义最终性,什么意思呢?其实有点像检查点,简单来说就是,在特定的区块高度需要有验证节点的签名信息A->B(其中A,B代表检查点区块),表明我A举手赞成B成为下一任党委书记,也就是赞成B成为下一个检查点,这样就不要再从创世区块去算状态保证安全性了,因为检查点之后的就改不了了。道理其实很简单,当上了党委书记就有话语权了,政策就不能再由着下面的人乱改了嘛。
同时,Casper也引入了惩罚条件(slashing conditions),来判定谁是坏人谁是好人,违反这两个规则的人就得被开罚单:
可以看出,Casper只是规定了检查点是怎么确定下来的,也就是说最终性是如何确定的,而把分叉规则单独最为一个组件,这么做也是为了解耦这两部分。
LMD由Sompolinsky等人提出的The Greediest Heaviest Observed SubTree rule (参见通俗的解释GHOST)改进而来,由于PoS的共识算法需要消息驱动来获取投票的权重,因此称之为Latest Message Driven Greediest Heaviest Observed SubTree(LMD GHOST).
算法如下所示:
<center>LMD GHOST算法规则</center>
举例来说就是,假设每个人拥有一个stake代表一票的权重(下图中用圆圈表示),那么按照这个算法就确定了途中蓝色的主链:
<center> LMD GHOST举例 </center> 那么这两个协议是如何结合到一起的呢,以太坊提出了Gasper(Ghost第一个字母G+Casper的后四个字母)协议:
为了理解Gasper,我们先要了解三个基本概念:
验证规则定义,如果这个投票的总和大于总staking的2/3,那么就认为边界区块被验证了。
具体而言,对于下面的例子:
*这是一个验证者的视图,由于网路延迟等问题,他之前很多区块没收到,因此64号区块就是193号区块Epoch1和Epoch2的边界区块,因此他再这里写入投票α,表示(64,2)是(180,3)的边界区块。同时根据GHOST规则可以看出需要投193号区块为当前的链头。*
而敲定相对于验证是一个更强一点的概念,如果说区块B0构成的边界区块(B0,j)被敲定了,那么要么他是创世区块,要么存在一个k>=1的数满足以下三个条件:
其实总的来说就是B0,需要被其他区块验证!
举个例子:
蓝色的区块代表被敲定了,带箭头的边表示被验证了(思考k=2时,B1为什么没有被敲定?)
验证了边界区块之后,只要没有超过1/3的攻击者stake就不能篡改这个区块,在这个假设基础上就能唯一确定边界区块,从而定义epoch内部的分叉规则了,算法如下:
这个算法思路其实表简单,就是先选取最新验证的epoch边界区块Bj,然后再根据GHOST规则来找到当前主链的链头区块。
细心的你可能发现这里有个问题就是,最新被验证的区块可能会变,因为被验证了不等于finalize了,只要还没被完全敲定就有可能会变;同时,每个验证节点的视图可能不一致,就导致我们自己的这个区块Bj可能跟别人的不一样!
那么对于这两个问题如何解决呢?还有整个系统的安全性和可用性如何呢?且听下回分解...
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!