《求真区块链》是 Fractal 思想库倾力打造的系列科普栏目,抱诚守真地输出科普内容,旨在让更多人的了解各项区块链技术的内在价值与差异。
今年年初,以太坊进行了君士坦丁堡升级,伴随着升级,以太坊何时能切换成 PoS 再次成为了大家热切关注的一个问题。众所周知,PoW 算法存在大量资源浪费,算力集中等问题,以太坊从17年开始就一直想要切换到 PoS 算法。但是由于种种客观条件的限制,一直没有实质性的发展。在放了广大区块链爱好者几年鸽子后,以太坊 2.0 终于要使用 PoS 算法了。本着独乐乐不如众乐乐的中国传统美德,Fractal 的技工们决定跟大家分享一下,我们关于下一代以太坊共识协议——Casper 的看法。
本系列文章将会分为多个部分,这篇文章首先为大家解读一下 Vitalik 关于 Casper FFG 的论文,既如何在现有以太坊的 PoW 协议上叠加一个 PoS,在减少矿工挖矿奖励的同时提高系统的安全性。
Casper 其实有两个版本,一个是 Vitalik 领导的 Casper FFG,另一个是 Vlad 领导的 Casper CBC,他们的不同之处就在于 FFG 更多的是作为一个过渡协议,使得以太坊能够从 PoW 成功过渡到PoS;而 CBC 则是以太坊切换到 PoS 后一个更好的版本,但从目前来看 CBC 仍有很多细节需要进一步研究和探讨。
FFG 的主要思想是借助 PoS 帮助 PoW 产生的区块最终确认,进而在减少矿工奖励的情况下来提高系统的安全性。
参与者通过抵押一定量的 stake 成为 Validator,Validator 负责运行 PoS 协议,为描述的便利性,假设在协议的过程中 Validator 保持不变。PoW 的以太坊会产生一棵树,如果 Validator 对每一个区块进行投票,会增加网络传播开销,为了减少 Casper 中投票的数量,将 100 个区块压缩成一个 checkpoint,如图1所示:
将区块压缩之后我们得到了图2,并且为每一个 checkpoint 提供了一个高度函数h(bi):区块 bi 到根结点 r 的跳数。
首先,我们从整体上描述一下 Casper 的共识过程。参与共识的 Validator 会对上文中所述的 checkpoint 进行投票。每个 Validator 投的是一段 checkpoint,从 justified checkpoint 开始到若干个 checkpoint 之后的一个 checkpoint。我们规定第一个 justified checkpoint 是创世区块,当一个 checkpoint 收到了超过 2/3 的从 justified checkpoint 到它的投票,那么这个区块就变成了justified。
例如,在图2中存在超过了2/3的从创世块 r 到 b1 的投票,那么 b1 就变成 justified;当存在超过 2/3 从 b1 到 b2 的投票,那么 b2 就是justified,以此类推。当一个 justified checkpoint ,收到了超过 2/3 从它出发到它的某个子 checkpoint 的投票时,那么这个 checkpoint 以及其之前到所有的 checkpoint 都已经被确认。
在将 PoW 产生的区块压缩成 checkpoint 之后,Validator 对于这棵树进行投票,投票规则如下:
vote=<v , s , t , h(s) , h(t)>
其中:
v :Validator的身份信息;
s :任意一个justified的checkpoint的hash,可以理解为源checkpoint。关于justified的定义我们之后会详细讲解;
t :任意一个 的子孙节点的hash,可以理解为目标checkpoint;
h(s) : s的高度;
h(t) : t的高度;
在定义了投票规则之后,定义任意两个checkpoint之间的关系:
supermajority link:对于一对checkpoint (a , b),写作(a→b),如果有超过 2/3 的 validator 投票 vote= , 可称作(a→b)是一条supermajority link,并且h(b)≥h(a)+1
conflicting:如果两个checkpoint在不同的分支上称之为conflicting。
如图3所示,其中, (r→b1)(b1→b2)(b2→b3)是supermajority link,b2,a3是conflicting。
在有了 checkpoint 之间关系的定义之后,定义 checkpoint——c 的两种状态:
- c是 justified:
1)c = root :checkpoint c是根;
2)或 存在(c'→c),即 c' 到 c 的 supermajority link,并且c'是 justified;
-c 是finalized:
a)c 是justified;
b)存在(c'→c) , c' 到 c 的supermajority link;
c) c , c' not conflicting;
d) h(c')=h(c)+1;
在图3中, (r , b1 , b2 , b3)是 justified,(a2 , b3) 是 finalized。如果一个 checkpoint 状态是 finalized,那么它以及它之前所有的 block 都会确认。
为了防止 Validator 在运行的过程中作恶,Casper 制定了一套惩罚机制如下:对于相同的 Validator,发布了两个不同的投票vote=<v , s1 , t1 , h(s1) , h(t1)> 和vote=<v , s2 , t2 , h(s2) , h(t2)> ,如果存在以下两种情况则罚抵押的 stake。
1、h(t1)=h(t2):对于同一个目标高度,不能发起两个不同的投票。
2、h(s1)<h(s2)<h(t2)<h(t1):两个投票的投票范围不能存在一个包含一个。
我们来看一下在合法的交易的情况下,justified 和 finalized 是如何保证 checkpoint 的安全性的。当一个 checkpoint : c 成为了 justified,说明有超过2/3的 Validator 支持 c 之前所有的 checkpoint,配合着第一个惩罚条件,在h(c)有超过2/3的 Validator 唯一支持 checkpoint c。对于 finalized 的checkpoint : f,他会有一个从f出发,连接到f的子节点的 supermajority link。配合第二个惩罚条件,当一个 checkpoint f 成为了 finalized,说明全网超过2/3的Validator不能发出跨越f的投票,这2/3的 Validator 只能对f之后的checkpoint 进行投票。如图4所示:对于任意一个 Validator,在投出了 vote1之后就无法投 vote2,因此 f 之前的 checkpoint 将不会被改变,因为任意对于f之前 checkpoint 的投票都无法获得超过2/3的投票。
为了让 PoS 能够提高 PoW 链的安全性,在如何进行分叉选择的时候,FFG 对最重链进行了些许的修改:首先在视图中找到高度最高的 justified checkpoint,并在该 checkpoint 之后的区块上进行最重链选择。这样做有两个好处,第一个是相比于原有的 ghost 算法,区块的确认是概率性的,等了足够多的高度之后,只有很低的概率颠覆之前的区块,虽然概率很低,但是还是有这种可能性;FFG 中只要是在 finalized 之前的区块都是被确认的,没有被颠覆的可能性。
第二点是一个确认的区块的安全性是需要矿工不断将自己的工作量提供给该区块的,因此为了激励矿工需要更多的挖矿奖励;FFG中,只要是 finalized 的区块都是被确认了的,无需后续的矿工用工作量为已经确认的区块增加安全性,因此可以降低挖矿奖励,降低通胀率。
我们刚开始说过,先假定 Validator 是固定的,但是一个真正的区块链系统肯定是能够让参与者自由进出的,因此 FFG 有一套自己的 Validator 出入原则。首先,定义区块b的 dynasty 为:从创始区块到b的父区块之间 finalized checkpoint 的数量。
抵押:
用户想要成为 Validator 需要抵押一定的 stake,当用户v的抵押交易被包含在一个dynasty=d的区块中,那么定义一个Start Dynasty,写作SD(v) = d+2。
赎回:
Validator v想要取回抵押的 stake,需要发起一个赎回交易,当这个交易信息被包含在一个 dynasty为 的区块中, 那么定义一个End Dynasty,写作ED(v) = +2。为了避免处理多个 SD 和 ED,一个用户在赎回之后不能再抵押成为 Validator。同时为了避免坏人作恶后立刻赎回 stake,在赎回交易执行后stake 仍需要锁定一定时间。
对于一个区块 b,假设其 dynasty 为 d,只有 d 在 ED 和 SD 之间的 Validator 才可以进行投票。
本篇介绍到这里结束,如果大家觉得有疑惑的地方可以扫描下方二维码加入 Fractal 官方群讨论,Fractal 的技工们在线解疑,在下篇文章中,我们将为大家介绍一下以太坊 2.0 中将要使用的 Casper 主要的协议过程。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。