常见共识算法简介

1、Pow工作量证明

本质是谁做的工作多，谁就更有机会获得额外奖励。就是大家熟悉的挖矿，通过与或运算，计算出一个满足规则的随机数，即获得本次记账权，发出本轮需要记录的数据，全网其它节点验证后一起存储；

优点：完全去中心化，节点自由进出；

缺点：目前bitcoin已经吸引全球大部分的算力，其它再用Pow共识机制的区块链应用很难获得相同的算力来保障自身的安全；挖矿造成大量的资源浪费；共识达成的周期较长，不适合商业应用

应用案例：比特币

2、Pos权益证明

Pow的一种升级共识机制；谁持有的币龄时间越长（币龄=持有币的数量*持有币的时间），谁更有机会获取区块的记账权。根据每个节点所占代币的比例和时间；等比例的降低挖矿难度，从而加快找随机数的速度。

优点：在一定程度上缩短了共识达成的时间

缺点：还是需要挖矿，本质上没有解决商业应用的痛点

应用案例：未来币，以太坊采用了Pow+POS的混合机制

3、DPos股份授权证明机制

委托权益证明是让每一个持有比特股的人进行投票，由此产生101位代表 , 我们可以将其理解为101个超级节点或者矿池，而这101个超级节点彼此的权利是完全相等的。持币者投出一定数量的节点，代理他们进行验证和记账。从某种角度来看，DPOS有点像是议会制度或人民代表大会制度。如果代表不能履行他们的职责（当轮到他们时，没能生成区块），他们会被除名，网络会选出新的超级节点来取代他们。

优点：大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证

缺点：整个共识机制还是依赖于代币，很多商业应用是不需要代币存在的

应用案例：比特股

4、PBFT拜占庭容错算法

这是一种基于消息传递的一致性算法，算法经过三个阶段达成一致性，这些阶段可能因为失败而重复进行。

假设节点总数为3f+1，f为拜赞庭错误节点：

1、当节点发现leader作恶时，通过算法选举其他的replica为leader。

2、leader通过pre-prepare 消息把它选择的 value广播给其他replica节点，其他的replica节点如果接受则发送 prepare，如果失败则不发送。

3、一旦2f个节点接受prepare消息，则节点发送commit消息。

4、当2f+1个节点接受commit消息后，代表该value值被确定

优点：上述共识算法都脱离不了币的存在，系统的正常运转必须有币的奖励机制，系统的安全性实际上是由系统币的持有者维护保证。当我们区块链系统实际运用到商业应用时，由其承载的资产价值可能远远超出系统发行的币的价值，如果由币的持有者保证系统的安全及稳定性将是不可靠的 。

1）系统运转可以脱离币的存在，pbft算法共识各节点由业务的参与方或者监管方组成，安全性与稳定性由业务相关方保证。

2）共识的时延大约在2~5秒钟，基本达到商用实时处理的要求。

3）共识效率高，可满足高频交易量的需求。

应用：央行的数字货币、联盟和私有区块链。

PBFT的限制：

很难支持大规模网络节点。

在区块链中，相较于传统的pow等，pbft这种通过投票来达成共识的机制可以很好的解决包括分叉等问题的同时提升效率。但这仅仅比较适合于联盟链私有链，因为pbft的机制要求是一个封闭的集群，两两节点需要进行通信，通信量是O(n^2)（通过优化可以减少通信量），在公有链这种全球性的大环境下，既不符合封闭性的原则，同样无法达成这种巨大的通信量。现阶段大部分创业公司采用pbft的也基本上是联盟链私有链，节点数量并不是很多，采用pbft效率更高结果也更好。

5、Paxos算法

Paxos算法是一种两阶段算法，主要有三类角色，proposer、acceptor、learner，proposer提出议案，acceptor同意或拒绝，learner则是获取达成共识后的最终值。

准备阶段：

proposer 选择一个提案编号 n 并将 prepare 请求发送给 acceptors 中的一个多数派；

acceptor 收到 prepare 消息后，如果提案的编号大于它已经回复的所有 prepare 消息，则 acceptor 将自己上次接受的提案回复给 proposer，并承诺不再回复小于 n 的提案；

批准阶段：

当一个 proposor 收到了多数 acceptors 对 prepare 的回复后，就进入批准阶段。它要向回复 prepare 请求的 acceptors 发送 accept 请求，包括编号 n 和value（如果没有已经接受的 value，那么它可以自由决定 value）。

在不违背自己向其他 proposer 的承诺的前提下，acceptor 收到 accept 请求后即接受这个请求。

Paxos算法适用于简单容错模型，即系统中只可能存在失效或故障节点，不存在恶意节点，如果失效节点数为x，则只需要未失效节点数为x+1就能维持系统的正常工作。

6、Raft算法

　　Raft算法包含三种角色，分别是：跟随者（follower），候选人（candidate）和领导者（leader）。一个节点在某一时刻只能是这三种状态的其中一种，这三种角色是可以随着时间和条件的变化而互相转换的。

　　所有的节点初始状态都为follower，超时未收到心跳包的follower将变身candidate并广播投票请求，获得多数投票的节点将化身leader，这一轮投票的过程是谁先发出谁有利，每个节点只会给出一次投票。leader节点周期性给其他节点发送心跳包，leader节点失效将会引发新一轮的投票过程。

 

 

上图描述了一个Raft提案的执行过程：

　　leader收到客户端发来的请求，写入本地日志，但写入日志的条目在提交状态机之前需要将请求发给所有follower请求验证；

　　follower对收到的信息进行验证，验证成功后写入本地日志并返回leader验证成功标识；

　　leader收到大部分的follower节点验证信息后，就会将当前的日志提交，更新节点的值，并广播更新所有follower节点的值，从而再一次达成共识；

　　Raft算法从节点不会拒绝主节点的请求，并且和Paxos一样只能容错故障或失效节点。