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

一时失言乱红尘 2023-01-22 03:51 143阅读 0赞

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

由于 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_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包含了下面所有含义：

*  所有节点的数据应是一致的。客户端发出一个读操作到任意一个节点，得到的结果应该是一样的。这个就是CAP里所说的Consistency. 这个术语是适用于所有的分布式系统的，包括可信环境例如Hadoop和不可信环境例如Bitcoin。
 *  所有节点要确保不进入互相冲突，分裂的状态，即safety。这个术语是适用于 Byzantine fault tolerance这个领域的，在拜占庭这种开放环境里，有恶意节点会广播两个互相冲突的消息（例如双花交易），导致全网所有节点陷入分裂状态，达不成一直，这就破坏了Safety这个性质。所有拜占庭下的共识算法，都需要处理好恶意节点的问题，保证全网的safety。
 *  交易一旦进入区块，应该不可撤销，即 Immutability。在区块链场景下，要保证Safety，不仅需要处理好恶意节点发出双花交易这种问题，而且还要防止恶意节点撤销已经打包进区块的交易。因为区块链是一个单链表，是一个线性结构，恶意节点理论上可以从旧的一个区块出发，分叉处一个更长的新链，把自己已经发出去的交易全部撤销掉，把自己的钱再花一遍（是另一种形式的双花）

综上，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][Finality_Liveness 1]

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

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

![比较各种共识算法的Finality和Liveness][Finality_Liveness 2]

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

![比较各种共识算法的Finality和Liveness][Finality_Liveness 3]

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

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

![比较各种共识算法的Finality和Liveness][Finality_Liveness 4]

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

![比较各种共识算法的Finality和Liveness][Finality_Liveness 5]

其实即使海底光缆不断，网络没有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][Finality_Liveness 6]

下图是pBFT的算法流程图：

![比较各种共识算法的Finality和Liveness][Finality_Liveness 7]

未完待续。。。

## 参考资料 ##

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

[Finality_Liveness]: /images/20221020/8506f8dabe3243cda38a37c42e4cffef.png
[Finality_Liveness 1]: /images/20221020/ac2e40da65874ad8bbea7d14535c84c5.png
[Finality_Liveness 2]: /images/20221020/b970b7b5c37248ca958b1f601c629ce1.png
[Finality_Liveness 3]: /images/20221020/745ed49b53a84e8882b7956a64577c4f.png
[Finality_Liveness 4]: /images/20221020/381b53ee7f2b4da0a40df8572268ccd0.png
[Finality_Liveness 5]: /images/20221020/6429221e3385471b97540dd12d70b4e8.png
[Finality_Liveness 6]: /images/20221020/eff7d8b75be644e1bcb2bc46bdf05723.png
[Finality_Liveness 7]: /images/20221020/226c9875ccc7421bb5a9a2b57a8c5c02.png