共识机制

区块链中最重要的便是共识算法，

比特币使用的是POW（Proof of Work，工作量证明），

以太币使用的是POS（Proof of Stake，股权证明）使得算力变的不怎么重要了。

而今POS的变体DPOS（Delegated Proof of Stake，股份授权证明）进一步削减算力的浪费，同时也加强了区块链的安全性。

不过，对于不需要货币体系的许可链或者私有链而言，绝对信任的节点，以及高效的需求。

上述共识算法并不能够提供，因此对于这样的区块链，传统的一致性算法成为首选，PBFT（拜占庭容错）、PAXOS、RAFT。

由于私有链是封闭生态的存储系统，因此采用Paxos类系统可以达到最优的性能；

联盟链有半公开半开放特性，因此拜占庭容错是适合选择之一，例如IBM超级账本项目；

对于公有链来说，这种共识算法的要求已经超出了普通分布式系统构建的范畴，再加上交易的特性，因此需要引入更多的安全考虑。

1、Pow工作量证明

就是大家熟悉的挖矿，通过与或运算，计算出一个满足规则的随机数，

即获得本次记账权，发出本轮需要记录的数据，全网其它节点验证后一起存储；

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

缺点：目前bitcoin已经吸引全球大部分的算力，其它再用Pow共识机制的区块链应用很难获得相同的算力来保障自身的安全；

挖矿造成大量的资源浪费；共识达成的周期较长，不适合商业应用

应用案例：比特币

2、Pos权益证明

Pow的一种升级共识机制；根据每个节点所占代币的比例和时间；等比例的降低挖矿难度，从而加快找随机数的速度。

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

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

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

3、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效率更高结果也更好。

pbft特点

pbft可以解决消息数据篡改和消息传输异常的问题。

是找出应该是正确的数据。
有不可信任和异常的节点。
与所有节点通信，大于2/3节点确认的数据才是结果。
由于所有节点需要互相通信，所有节点的数据就是相同的，根据相同的机制就会得到一致的结果。

PAXOS特点

PAXOS是用来解决消息传输异常的问题，他的前提是消息数据都是正确的，没有篡改。
是找出应该是最新的数据。节点都可信，有异常的节点。
proposer与acceptors之间互相通信，proposer得到全部数据，
其中一个proposer会得到结果，得到结果的proposer将结果通知大家。

Raft特点

Raft协议比paxos的优点是 容易理解，容易实现。

它强化了leader的地位，把整个协议可以清楚的分割成两个部分，并利用日志的连续性做了一些简化：

（1）Leader在时。由Leader向Follower同步日志

（2）Leader挂掉了，选一个新Leader，Leader选举算法。

但是本质上来说，它容易的地方在于流程清晰，描述更清晰，关键之处都给出了伪代码级别的描述，可以直接用于实现，

而paxos最初的描述是针对非常理论的一致性问题，真正能应用于工程实现的mulit-paxos，Lamport就提了个大概，

之后也有人尝试对multi-paxos做出更为完整详细的描述，但是每个人描述的都不大一样。

我们假定 Paxos 的晦涩来源于它将单决策子集作为它的基础。

单决策（Single-decree）Paxos 是晦涩且微妙的：它被划分为两个没有简单直观解释的阶段，并且难以独立理解。

正因为如此，它不能很直观的让我们知道为什么单一决策协议能够工作。为多决策 Paxos 设计的规则又添加了额外的复杂性和精巧性。

Paxos 的第二个缺点是它难以在实际环境中实现。其中一个原因是，对于多决策 Paxos （multi-Paxos） ，大家还没有一个一致同意的算法。

Lamport 的描述大部分都是有关于单决策 Paxos （single-decree Paxos）；他仅仅描述了实现多决策的可能的方法，缺少许多细节。

有许多实现 Paxos 和优化 Paxos 的尝试，但是他们都和 Lamport 的描述有些出入。

另外，Paxos 的结构也是不容易在一个实际系统中进行实现的，这是单决策问题分解带来的又一个问题。

例如，从许多日志条目中选出条目然后把它们融合到一个序列化的日志中并没有带来什么好处，它仅仅增加了复杂性。

围绕着日志来设计一个系统是更简单、更高效的：新日志按照严格的顺序添加到日志中去。

另一个问题是，Paxos 使用对等的点对点的实现作为它的核心（尽管它最终提出了一种弱领导者的形式来优化性能）。

这种方法在只有一个决策被制定的情况下才显得有效，但是很少有现实中的系统使用它。

如果要做许多的决策，选择一个领导人，由领带人来协调是更简单有效的方法。