共识算法设计

介绍

Posted by Emo on May 14, 2022

共识算法

EMO’s Blog

共识算法分类

在我个人的理解里面,共识算法一开始分为两类,一类是在中心化异步系统中解决CFT问题的算法,如Raft,Paxos,我把他们叫做CFT Consensus Algorithm。另一类是解决BFT问题的共识算法。起初在区块链未大火之前,Raft等CFT共识算法是主流的保障异步系统中的一致性的算法。而后区块链的出现,赋予了BFT共识算法发挥的场景。

而在BFT共识领域,最早比较出名的是PBFT算法,而后在比特币的论文当中中本聪又提出了POW算法。虽然这两个算法都是在解决BFT问题,但是两者之间的区别是挺大的。所以在这里我个人将他们分为了两类,一类是中本聪共识,另一类是BFT共识。而后虽然出现了很多新的共识算法,但是我个人认为都没有超出这两个共识算法的范畴。

BFT共识:

  1. 基于投票的共识,也可以说是基于消息传递的共识。这一特性带来的优点就是不会出现分叉,缺点就是消息复杂度高,很难扩展为大规模的网路。
  2. 基于身份验证的共识,因为BFT的共识是通过投票并通过观察投票的票型来实现共识的。所以网络中的所有节点都需要对于参与投票的人数和身份有一个统一的认知。这个特性带来的缺点就是:节点的加入与退出的灵活性低而且需要对节点的加入退出有一个良好的设计,以防止女巫攻击来影响网络整体的Liveness和Safety。
  3. 对作恶节点的识别以及惩罚机制
  4. 出块节点/Leader节点的选举机制
  5. 如何尽量保证节点在线

中本聪共识:

  1. 基于离线竞争的模式保证一个比较松散的一致性,通过将竞争与一些稀缺的且不太具备复制性的东西绑定,来防止女巫攻击。优点是:不需要大规模的消息IO,缺点是允许分叉的出现。
  2. 不需要身份验证,所有节点可以十分自由的加入和退出。而且也不存在2/3投票的要求,网络的Liveness得到的极大的保证,但相应的Safety上做出了妥协,提供一种比较弱的最终一致性。

基于两段式共识/两段式提交的PBFT算是很早且实用的共识算法了,我们可以看到这类算法最本质的一点就是,他们对于一个事务的共识是通过投票来决定的,通俗点来讲也可以说是通过消息传递来实现共识的。在Raft当中也有两段式提交的过程,只不过Raft中不存在Byzantine节点,所以不用怀疑Leader节点在请求上作假(给不同的节点传递不一样的请求,从而破坏一致性)。BFT问题中的Leader节点是不可信的,所以当Leader节点将请求发送给所有Replica节点后,这些节点需要判断Leader节点的诚实性,所以需要将收到的来自Leader的请求广播给网络中的其他节点,并以此保证网络当中的非拜占庭节点对于请求的内容达成一致,这便是prepare过程。当prepare过程完成后(收到了2f+1个请求相同的prepare消息),节点需要将自己已经知道达成一致的请求这一消息告诉其他节点。只有当网络中绝大部分非拜占庭节点都知道其他节点已经知道了大家对于某一个请求达成一致了后,就可以commit请求内容了。所以我们可以看到,BFT问题当中

设计PoS+BFT共识需要考虑的要点

  1. 投票者集合构建(投票者的加入退出规则或者投票者集合的选举过程)。
  2. 出块节点的选择机制。
  3. 投票节点的在线要求。
  4. 投票节点的作恶识别机制以及惩罚机制。
  5. 正向奖励机制。
  6. 投票共识的流程设计。

{ % if page.mermaid % } { % endif % }