比较各种共识算法的Finality和Liveness_MIN:TEN

原作者:灵魂机器由于FLPImposibility原理,Nocompletelyasynchronousconsensusprotocolcantolerateevenasingleunannouncedprocessdeath因此不要浪费时间为纯异步网络设计共识算法。解决办法就是,要么加强对网络的要求,要求网络是Synchronous或者PartiallySynchronous的,或者放松对finality的要求,不要求Deterministicfinality,只要求Probabilisticfinality即可。两者同时进行也可以。表1各种共识算法比较下面详细讲解一下上面表格中的内容。Finality

Finality看起来和Safety,Consistency很相似,又似乎有所不同,非常容易让人困惑。简单的理解,你可以认为Finality,Safety,Consistency是同义词,即Finality=Safety=Consistency。更深入理解,我认为Finality是一个综合体,Finality>Safety>Consistency。Consistency适用于所有分布式系统的,包括可信环境例如Hadoop和不可信环境例如Bitcoin;Safety适用于拜占庭环境下;Finality是在区块链这个场景下的术语,区块链是拜占庭场景下的一个子集。Consistency是CAP理论中的C,更加general,要求没有Finality那么多。Finality包含的含义比Consistency更多更强。Finality包含了下面所有含义:所有节点的数据应是一致的。客户端发出一个读操作到任意一个节点,得到的结果应该是一样的。这个就是CAP里所说的Consistency.这个术语是适用于所有的分布式系统的,包括可信环境例如Hadoop和不可信环境例如Bitcoin。所有节点要确保不进入互相冲突,分裂的状态,即safety。这个术语是适用于Byzantinefaulttolerance这个领域的,在拜占庭这种开放环境里,有恶意节点会广播两个互相冲突的消息,导致全网所有节点陷入分裂状态,达不成一直,这就破坏了Safety这个性质。所有拜占庭下的共识算法,都需要处理好恶意节点的问题,保证全网的safety。交易一旦进入区块,应该不可撤销,即Immutability。在区块链场景下,要保证Safety,不仅需要处理好恶意节点发出双花交易这种问题,而且还要防止恶意节点撤销已经打包进区块的交易。因为区块链是一个单链表,是一个线性结构,恶意节点理论上可以从旧的一个区块出发,分叉处一个更长的新链,把自己已经发出去的交易全部撤销掉,把自己的钱再花一遍综上,Finality=Consistency+Safety+Immutability。Liveness

Liveness可以认为与CAP中的Availability等价。当网络出现partition时,比如海底光缆断裂,将全球互联网分割成两个部分,整个区块链系统是否能正常写入新的交易?喜欢Finality的共识算法,这时候会选择无限等待,新的transaction无法写入,直到海底光缆修复,两边的互联网互通;喜欢Availabilty的共识算法,这时候两边网络会独立运作,数据分家了,两边的全节点中的数据变得不一致。比如Tendermint就是这类,牺牲Liveness追求DeterministicFinality。假设海底光缆断裂将网络分为两边,那么每一边都有一半的validator,于是在vote和commit阶段,每一边的所有validator,100%全部投票赞成某个proposalblock,最多只能收到50%的投票,达不到2/3,于是整个区块链网络会无限等待,直到收集到2/3投票为止。在这个等待期间,无法出下一个块,新的交易也无法写入,整个网络陷入瘫痪。比特币在碰到这种网络分割的时候,两部分的比特币系统会继续向前走,依旧可以写入新的transaction,产生新的区块,当海底光缆修复后,两边互联网连通后,再选择合并。在海底光缆没断之前,全球所有全节点的状态是一致的,如下图:当海底光缆断裂后,全球网络被分割为两部分,两个部分都会独立出块,这时候两边已经不一致了,但是两边各自是感知不到的,以为自己依旧是一条线性的区块链,如下图:左边和右边,虽然依旧每10分钟挖出一个新块,但是左边的block07和右边的block07,blockhash是不相等的。这时候比特币网络还是available的,只是Finality破坏了。当海底光缆修复后,这时候,两边互相同步block,会意识到出现了分叉,如下图:现在全球所有全节点的状态,变成上图,有分叉了,由于两边的高度都是8,无法决定哪个分叉是正确的,这时候,就看矿工支持哪边了,哪边的算力高,哪边先出了新块,那么哪边就胜出了,短的那条链会被抛弃,比如假设右边抢先新出了一个块,那么右边胜出,左边分叉被抛弃,所有全节点中的数据又变成一条线性区块链,达成一致了,如下图:其实即使海底光缆不断,网络没有partition,也会经常发生两个miner各自同时挖出一个新块的情况,这时候就比拼谁运气好,下一个新块继承哪一个分叉哪一个就胜出。也就说比特币理论上永远没有一个确定性的一致性状态,分叉随时会在任意高度上出现,因此比特币牺牲了一点Finality,换取更强的Liveness。NetworkAssumption

所有分布式共识算法都对网络有一个隐含的假设前提。先说一下网络的分类:同步:消息一定会在某个的时间T内被送达,这个上限(upperbound)的值T,是已知的常量,所有节点都是知道的。如果消息在T时间内没有送达,就不对这个消息作指望了,节点认为该消息已经丢失,不会继续等它。所有节点都有条不紊的,每经过一个时间T,就往前进一步,非常整齐。半同步:消息一定会在某个的时间T内被送达,但这个T的值,不是固定的值,而是动态变化的,例如是根据网络状况动态计算出来的。所有节点异步:消息会在任意时间到达,可能很快,也可能很慢,总之没有一个明确的上限(upperbound)甚至无限期延迟,无论多晚到达,节点都要接受并处理这个消息,不能简单的因为超时就丢弃消息比特币对网络的假设就是网络是同步的,时间上限是10分钟左右,一个Miner挖出一个block后,向全网广播,这时候整个比特币系统,期望就是这个block在10分钟内会被所有在线的全节点fullnode收到,意思就是说每隔10分钟,所有全节点都会整整齐齐地往前走一步,即往自己的区块链尾部追加一个block。即使网速很快,例如3分钟不到,这个新block已经被所有全节点收到了,比特币还是会每隔10分钟往前走一步(出一个新块)。以太坊类似,不过时间上限是15秒。Tendermint在propose阶段假设网络是半同步的,因为在这一步会有一个超时时间,如果超过时间还没收到一个proposal新块,那么其他validator就会认为proposer节点已经挂了,于是出一个空块,直到round-robin到下一个proposer。Tendermint在prevote和precommit都需要收集超过2/3的投票,是无限等待的,也就是在这两个阶段是假设网络是异步的。最终,Tendermint对网络的要求是半同步的。pBFT在pre-prepare,prepare,commit三个阶段全部是异步的,既然是异步的,没有超时机制,那怎么往前进展呢?收集到了超过2/3就能继续往前进。不过所有节点在收到一个客户端的请求,都会启动一个定时器,如果在某个时间内该请求还没有执行完毕,就会触发ViewChange。ViewChange这个部分是半同步的。在这里可以体会到Tendermint相比pBFT的简化之处了。Tendermint把超时机制挪动到了propose阶段,如果proposer在规定时间内,广播出了一个proposalblock,那么就前进到下一步,如果超时了,也前进到下一步,不过这个是proposalblock是一个空块。也就是无论如何,propose阶段都会往前进入到下一步。但是Tendermint的pre-prepare是异步的,有可能永远卡主。pBFT把超时机制挪动到了ViewChange这一部分,因此pBFT就多出来一个ViewChange步骤,比Tendermint复杂了一些。Tendermint通过提交空块和round-robin更换proposer节点,而pBFT则是通过ViewChange来更换primary节点。Tendermint消除了复杂的ViewChange这一步骤。除了消除ViewChange这一点,Tendermint还在另一个地方有所简化,Tendermint的所有信息都存储在blockchain里。而pBFT是1999年提出来的,那时候还没有blockchain这个东西,因此pBFT的所有节点虽有有一致的数据,但数据是分散存放的。pBFT的每个节点的数据包括:Thestateofeachreplicaincludesthestateoftheservice,amessagelogcontainingmessagesthereplicahasaccepted,andanintegerdenotingthereplica’scurrentview.Blockchain就是一个分布式数据库,好比在MySQL这类DBMS数据库没出现之前,人们都是把数据写入文件然后存在硬盘上,发明出各种奇怪的文件格式和组织方式。有了MySQL后,管理数据就方便多了。同理,Tendermint把数据全部存入blockchain,pBFT没有blockchain这样一个分布式数据库,所有节点需要自己在硬盘上管理数据,比如为了压缩消息日志,丢弃老的消息,节省硬盘空间,引入了checkpoint的概念。Tendermint和pBFT关系类似于Raft和Paxos的关系,Tendermint是pBFT的简化版,是针对blockchain这个场景下的简化版pBFT下图是Tendermint的算法流程图:下图是pBFT的算法流程图:未完待续。。。参考资料

1999.Castro.PracticalByzantineFaultToleranceTendermint:ByzantineFaultToleranceintheAgeofBlockchainsConsensusCompare:Caspervs.TendermintAProofofStakeoverviewComparedwithtraditionalPBFT,whatadvantagedoesTendermintalgorithmhas?Synchronous,partiallysynchronousandasynchronousconsensusalgorithmsGRANDPABlockFinalityinPolkadot:AnIntroduction(Part1)FinalityinBlockchainConsensus

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金智博客

[0:15ms0-4:295ms