编程语言
首页 > 编程语言> > 比较各种共识算法的Finality和Liveness

比较各种共识算法的Finality和Liveness

作者:互联网

不要浪费时间为纯异步网络设计共识算法。

由于 FLP Imposibility 原理, 

No completely asynchronous consensus protocol can tolerate even a single unannounced process death

因此不要浪费时间为纯异步网络设计共识算法。解决办法就是,要么加强对网络的要求,要求网络是Synchronous或者Partially Synchronous的(从异步到同步或者半同步,网络状态变好了),或者放松对finality的要求,不要求Deterministic finality,只要求Probabilistic finality 即可。两者同时进行也可以。 

表1 各种共识算法比较比较各种共识算法的Finality和Liveness

下面详细讲解一下上面表格中的内容。

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包含了下面所有含义:


综上,Finality=Consistency + Safety + Immutability。 

Liveness

Liveness可以认为与CAP中的Availability等价。当网络出现partition时,比如海底光缆断裂,将全球互联网分割成两个部分,整个区块链系统是否能正常写入新的交易?喜欢Finality的共识算法,这时候会选择无限等待,新的transaction无法写入,直到海底光缆修复,两边的互联网互通;喜欢Availabilty的共识算法,这时候两边网络会独立运作,数据分家了,两边的全节点中的数据变得不一致。 

比如Tendermint就是这类,牺牲Liveness追求Deterministic Finality。假设海底光缆断裂将网络分为两边,那么每一边都有一半的validator, 于是在vote和commit阶段,每一边的所有validator, 100%全部投票赞成某个proposal block,最多只能收到50%的投票,达不到2/3,于是整个区块链网络会无限等待,直到收集到2/3投票为止。在这个等待期间,无法出下一个块,新的交易也无法写入,整个网络陷入瘫痪。

比较各种共识算法的Finality和Liveness

比特币在碰到这种网络分割的时候,两部分的比特币系统会继续向前走,依旧可以写入新的transaction, 产生新的区块,当海底光缆修复后,两边互联网连通后,再选择合并。 

在海底光缆没断之前,全球所有全节点的状态是一致的,如下图:

比较各种共识算法的Finality和Liveness

当海底光缆断裂后,全球网络被分割为两部分,两个部分都会独立出块,这时候两边已经不一致了,但是两边各自是感知不到的,以为自己依旧是一条线性的区块链,如下图:

比较各种共识算法的Finality和Liveness

左边和右边,虽然依旧每10分钟挖出一个新块,但是左边的 block07和右边的block07,block hash 是不相等的。这时候比特币网络还是available的,只是Finality破坏了。 

当海底光缆修复后,这时候,两边互相同步block,会意识到出现了分叉,如下图:

比较各种共识算法的Finality和Liveness

现在全球所有全节点的状态,变成上图,有分叉了,由于两边的高度都是8,无法决定哪个分叉是正确的,这时候,就看矿工支持哪边了,哪边的算力高,哪边先出了新块,那么哪边就胜出了,短的那条链会被抛弃,比如假设右边抢先新出了一个块,那么右边胜出,左边分叉被抛弃,所有全节点中的数据又变成一条线性区块链,达成一致了,如下图:

比较各种共识算法的Finality和Liveness

其实即使海底光缆不断,网络没有partition, 也会经常发生两个miner各自同时挖出一个新块的情况,这时候就比拼谁运气好,下一个新块继承哪一个分叉哪一个就胜出。也就说比特币理论上永远没有一个确定性的一致性状态,分叉随时会在任意高度上出现,因此比特币牺牲了一点Finality, 换取更强的Liveness。 

Network Assumption

所有分布式共识算法都对网络有一个隐含的假设前提。 
先说一下网络的分类: 

同步:消息一定会在某个的时间T内被送达,这个上限(upper bound)的值T,是已知的常量,所有节点都是知道的。如果消息在T时间内没有送达,就不对这个消息作指望了,节点认为该消息已经丢失,不会继续等它。所有节点都有条不紊的,每经过一个时间T,就往前进一步,非常整齐。 

半同步:消息一定会在某个的时间T内被送达,但这个T的值,不是固定的值,而是动态变化的,例如是根据网络状况动态计算出来的。所有节点 

异步:消息会在任意时间到达,可能很快,也可能很慢,总之没有一个明确的上限(upper bound)甚至无限期延迟,无论多晚到达,节点都要接受并处理这个消息,不能简单的因为超时就丢弃消息

比特币对网络的假设就是网络是同步的,时间上限是10分钟左右,一个Miner 挖出一个block后,向全网广播,这时候整个比特币系统,期望就是这个block 在10分钟内会被所有在线的全节点full node收到,意思就是说每隔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就能继续往前进。不过所有节点在收到一个客户端的请求,都会启动一个定时器,如果在某个时间内该请求还没有执行完毕,就会触发 View Change。View Change 这个部分是半同步的。 

在这里可以体会到Tendermint相比pBFT的简化之处了。Tendermint 把超时机制挪动到了propose阶段(相当于pBFT的pre-prepare阶段),如果proposer在规定时间内,广播出了一个proposal block,那么就前进到下一步,如果超时了,也前进到下一步,不过这个是proposal block是一个空块(空块时也会完整走一遍pre-vote和pre-commit流程,不过block height不会自增1,相当于网络在空转,一直到round-robin到下一个新的proposer节点,重新广播新的proposal block)。也就是无论如何,propose阶段都会往前进入到下一步。但是 Tendermint的pre-prepare是异步的,有可能永远卡主。pBFT把超时机制挪动到了View Change 这一部分,因此pBFT就多出来一个View Change 步骤,比 Tendermint复杂了一些。Tendermint通过提交空块和round-robin更换proposer 节点, 而 pBFT则是通过 View Change 来更换primary节点。Tendermint消除了复杂的View Change这一步骤。 

除了消除View Change这一点,Tendermint还在另一个地方有所简化,Tendermint的所有信息都存储在blockchain里。而pBFT是1999年提出来的,那时候还没有blockchain这个东西,因此 pBFT的所有节点虽有有一致的数据,但数据是分散存放的。pBFT的每个节点的数据包括: 

The state of each replica includes the state of the service, a message log containing messages the replica has accepted, and an integer denoting the replica’s current view.

Blockchain就是一个分布式数据库,好比在MySQL这类DBMS数据库没出现之前,人们都是把数据写入文件然后存在硬盘上,发明出各种奇怪的文件格式和组织方式。有了MySQL后,管理数据就方便多了。同理,Tendermint 把数据全部存入blockchain, pBFT没有blockchain这样一个分布式数据库,所有节点需要自己在硬盘上管理数据,比如为了压缩消息日志,丢弃老的消息,节省硬盘空间,引入了checkpoint的概念。 

Tendermint和pBFT关系类似于Raft和Paxos的关系,Tendermint是pBFT的简化版,是针对blockchain这个场景下的简化版pBFT

下图是Tendermint的算法流程图:

比较各种共识算法的Finality和Liveness

下图是pBFT的算法流程图:

比较各种共识算法的Finality和Liveness

未完待续。。。 

参考资料

  1. 1999.Castro.  Practical Byzantine Fault Tolerance

  2. Tendermint: Byzantine Fault Tolerance in the Age of Blockchains

  3. Consensus Compare: Casper vs. Tendermint

  4. A Proof of Stake overview

  5. Compared with traditional PBFT, what advantage does Tendermint algorithm has?

  6. Synchronous, partially synchronous and asynchronous consensus algorithms

  7. GRANDPA Block Finality in Polkadot: An Introduction (Part 1)

  8. Finality in Blockchain Consensus

标签:Tendermint,pBFT,Liveness,网络,算法,Finality,区块,节点
来源: https://blog.csdn.net/shangsongwww/article/details/116929860