共识机制是什么？
区块链是伴随比特币诞生的，是比特币的基础技术架构。可以将区块链理解为一个基于互联网的去中心化记账系统。
类似比特币这样的去中心化数字货币系统，要求在没有中心节点的情况下保证各个诚实节点记账的一致性，就需要区块链来完成。
所以区块链技术的核心是在没有中心控制的情况下，在互相没有信任基础的个体之间就交易的合法性等达成共识的共识机制。
区块链为什么需要共识机制？
分布式系统中，多个主机通过异步通信方式组成网络集群。在这样的一个异步系统中，需要主机之间进行状态复制，以保证每个主机达成一致的状态共识。
异步系统中，可能出现无法通信的故障主机，而主机的性能可能下降，网络可能拥塞，这些可能导致错误信息在系统内传播。因此需要在默认不可靠的异步网络中定义容错协议，以确保各主机达成安全可靠的状态共识。
利用区块链构造基于互联网的去中心化账本，需要解决的首要问题是如何实现不同账本节点上的账本数据的一致性和正确性。
这就需要借鉴已有的在分布式系统中实现状态共识的算法，确定网络中选择记账节点的机制，以及如何保障账本数据在全网中形成正确、一致的共识。
算法的假设条件
在实际情况下，根据不同的假设条件，有很多不同的共识算法被设计出来。这些算法各有优势和局限。算法的假设条件有以下几种情况：
1）故障模型：非拜占庭故障/拜占庭故障。
2）通信类型：同步/异步。
3）通信网络连接：节点间直连数。
4）信息发送者身份：实名/匿名。
5）通信通道稳定性：通道可靠/不可靠。
6）消息认证性：认证消息/非认证消息。
在区块链网络中，由于应用场景的不同，所设计的目标各异，不同的区块链系统采用了不同的共识算法。
一般来说，在私有链和联盟链情况下，对一致性、正确性有很强的要求。一般来说要采用强一致性的共识算法。而在公有链情况下，对一致性和正确性通常没法做到百分之百，通常采用最终一致性（Eventual Consistency）的共识算法。
区块链的共识机制目前主要有4类：PoW、PoS、DPoS、分布式一致性算法
PoW
PoW（工作量证明），也就是像比特币的挖矿机制，矿工通过把网络尚未记录的现有交易打包到一个区块，然后不断遍历尝试来寻找一个随机数，使得新区块加上随机数的哈希值满足一定的难度条件，例如前面10位是零。
找到满足条件的随机数，就相当于确定了区块链最新的一个区块，也相当于获得了区块链的本轮记账权。
矿工把满足挖矿难度条件的区块在网络中广播出去，全网其他节点在验证该区块满足挖矿难度条件，同时区块里的交易数据符合协议规范后，将各自把该区块链接到自己版本的区块链上，从而在全网形成对当前网络状态的共识。
比特币和以太坊都是基于PoW的共识机制。
优点：
完全去中心化，节点自由进出，避免了建立和维护中心化信用机构的成本。
只要网络破坏者的算力不超过网络总算力的50%，网络的交易状态就能达成一致。
缺点：
目前比特币挖矿造成大量的资源浪费。
挖矿的激励机制也造成矿池算力的高度集中，背离了当初去中心化设计的初衷。
更大的问题是PoW机制的共识达成的周期较长，每秒只能最多做7笔交易，不适合商业应用。
PoS
PoS权益证明，要求节点提供拥有一定数量的代币证明来获取竞争区块链记账权的一种分布式共识机制。
如果单纯依靠代币余额来决定记账者必然使得富有者胜出，导致记账权的中心化，降低共识的公正性，因此不同的PoS机制在权益证明的基础上，采用不同方式来增加记账权的随机性来避免中心化。
例如点点币（PeerCoin）PoS机制中，拥有最多链龄长的比特币获得记账权的几率就越大。NXT和Blackcoin则采用一个公式来预测下一个记账的节点。拥有多的代币被选为记账节点的概率就会大。
以太坊将会从目前的PoW机制转换到PoS机制，从目前看到的资料看，以太坊的PoS机制将采用节点下赌注来赌下一个区块，赌中者有额外以太币奖，赌不中者会被扣以太币的方式来达成下一区块的共识。
优点：
在一定程度上缩短了共识达成的时间，降低了PoW机制的资源浪费。
缺点：
破坏者对网络攻击的成本低，网络的安全性有待验证。
拥有代币数量大的节点获得记账权的几率更大，会使得网络的共识受少数富裕账户支配，从而失去公正性。
DPoS
DPoS（股份授权证明）机制，类似于董事会投票。
比特股（bitshares）和steem采用的DPoS机制是持股者投票选出一定数量的见证人，每个见证人按序有两秒的权限时间生成区块，若见证人在给定的时间片不能生成区块，区块生成权限交给下一个时间片对应的见证人。
持股人可以随时通过投票更换这些见证人。DPoS的这种设计使得区块的生成更为快速，也更加节能。
优点：
大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证。
缺点：
选举固定数量的见证人作为记账候选人有可能不适合于完全去中心化的场景。
在网络节点数少的场景，选举的见证人的代表性也不强。
以上三种算法多用于共有链。
分布式一致性算法
分布式一致性算法是基于传统的分布式一致性技术。其中又分为解决拜占庭将军问题的拜占庭容错算法，如PBFT。
另外解决非拜占庭问题的分布式一致性算法（Pasox、Raft），该类算法目前是联盟链和私有链链场景中常用的共识机制。
拜占庭问题讨论的是允许存在少数节点作恶（消息可能被伪造）场景下的一致性达成问题。拜占庭算法讨论的是最坏情况下的保障。
Paxos问题是指分布式的系统中存在故障，但不存在恶意节点（无伪造消息，但可能丢失或重复）场景下的一致性问题。
优点：实现秒级的快速共识机制，保证一致性。
缺点：去中心化程度不如公有链上的共识机制；更适合多方参与的多中心商业模式。
PBFT ：Practical Byzantine Fault Tolerance，实用拜占庭容错
在保证活性和安全性（liveness & safety）的前提下提供了(n-1)/3的容错性。在分布式计算上，不同的计算机透过讯息交换，尝试达成共识；但有时候，系统上协调计算机（Coordinator / Commander）或成员计算机 （Member /Lieutanent）可能因系统错误并交换错的讯息，导致影响最终的系统一致性。
拜占庭将军问题就根据错误计算机的数量，寻找可能的解决办法，这无法找到一个绝对的答案，但只可以用来验证一个机制的有效程度。
而拜占庭问题的可能解决方法为：
在 N ≥ 3F + 1 的情况下一致性是可能解决。其中，N为计算机总数，F为有问题计算机总数。信息在计算机间互相交换后，各计算机列出所有得到的信息，以大多数的结果作为解决办法。
优点：
系统运转可以脱离币的存在，pbft算法共识各节点由业务的参与方或者监管方组成，安全性与稳定性由业务相关方保证。
共识的时延大约在2~5秒钟，基本达到商用实时处理的要求。
共识效率高，可满足高频交易量的需求。
缺点：
- 当有1/3或以上记账人停止工作后，系统将无法提供服务。
- 当有1/3或以上记账人联合作恶，且其它所有的记账人被恰好分割为两个网络孤岛时，恶意记账人可以使系统出现分叉，但是会留下密码学证据。
Paxos
1990 年由 Leslie Lamport 提出的 Paxos 一致性算法，在工程角度实现了一种最大化保障一致性（存在极小的概率无法实现一致性）的机制。Paxos 被广泛应用在 Chubby、ZooKeeper这样的系统中，Leslie Lamport 因此获得了 2013 年度图灵奖。
故事背景是古希腊 Paxon 岛上的多个法官在一个大厅内对一个议案进行表决，如何达成统一的结果。他们之间通过服务人员来传递纸条，但法官可能离开或进入大厅，服务人员可能偷懒去睡觉。
Paxos 是第一个被证明的一致性算法，其原理基于两阶段提交 并进行扩展。
作为现在一致性算法设计的鼻祖，以最初论文的难懂（算法本身并不复杂）出名。算法中将节点分为三种类型：
proposer：提出一个提案，等待大家批准为结案；
acceptor：负责对提案进行投票；
learner：被告知结案结果，并与之统一，不参与投票过程。
并满足三点约束要求：
决议（value）只有在被 proposers 提出的 proposal 才能被最终批准；
在一次执行实例中，只批准（chosen）一个最终决议，意味着多数接受（accept）的结果能成为决议；
learners 只能获得被批准（chosen）的决议。
算法本身用语言描述极其精简：
阶段 1
proposer向网络内超过半数的acceptor发送prepare消息；
acceptor正常情况下回复promise消息。
阶段 2
在有足够多acceptor回复promise消息时，proposer发送accept消息；
正常情况下acceptor回复accepted消息。
基本过程包括 proposer 提出提案，先争取大多数 acceptor 的支持，超过一半支持时，则发送结案结果给所有人进行确认。一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的 proposer 都恰好故障，系统则永远无法达成一致（概率很小）。
Paxos 能保证在超过一半的正常节点存在时，系统能达成一致。
单个提案者
如果系统中限定只有某个特定节点是提案者，那么一致性肯定能达成（只有一个方案，要么达成，要么失败）。
但一旦提案者故障，则系统无法工作。
多个提案者
问题一下子变得复杂了。
一种情况是同一时间片段（如一个提案周期）内只有一个提案者。这需要设计一种机制来保障提案者的正确产生，例如按照时间、序列、或者大家猜拳（出一个数字来比较）之类。考虑到分布式系统要处理的工作量很大，这个过程要尽量高效，满足这一条件的机制非常难设计。
另一种情况是允许同一时间片段内可以出现两个提案者。那同一个节点可能收到两份提案，怎么对他们进行区分呢？很自然的，提案需要带上不同的序号。节点需要根据提案序号来判断接受哪个。比如接受其中序号较大（往往意味着是接受新提出的，因为旧提案者故障概率更大）的提案。
如何为提案分配序号呢？一种可能方案是每个节点的提案数字区间彼此隔离开，互相不冲突。为了满足递增的需求可以配合用时间戳作为高位字段。
两阶段的提交
提案者发出提案之后，收到一些反馈。这个时候得知的一种结果是自己的提案被大多数接受了，一种结果是没被接受。没被接受的话好说，过会再试试。
即便受到来自大多数的接受反馈，也不能认为就最终确认了。因为这些接收者自己并不知道自己刚反馈的提案就恰好是全局的绝大多数。
很自然的，引入了新的一个阶段，即提案者在前一阶段拿到所有的反馈后，判断这个提案是可能被大多数接受的提案，需要对其进行最终确认。
Paxos 里面对这两个阶段分别命名为准备（prepare）和提交（commit）。
准备阶段解决大家对哪个提案进行投票的问题，提交阶段解决确认最终值的问题。
下面，我们简化认为更大的提案号意味着更新的提案。
准备阶段，比较简单，多个提案者可以发送提案： <id, value> ，接收者收到提案就返回收到消息，并且只保留最新的提案。如果收到一个请求的提案号比目前保留的小，则返回保留的提案给提案者，告诉它已经有其它人发出更新的提案了。
提交阶段，如果一个提案者在准备阶段收到大多数的回复（表示大部分人听到它的请求，可能做好了最终确认的准备了），则再次发出确认消息。如果再次收到大多数的回复，并且大家都返回空，则带上原来的提案号和内容；如果返回中有更新的提案，则替换提案值为更新
提案的值。如果没收到足够多的回复，则需要再次发出请求。
接收者如果发现这个提案号跟自己目前保留的一致，则确认该提案。
Raft
Raft 是对 Paxos 的重新设计和实现。
Raft 算法是Paxos 算法的一种简化实现。
RAFT核心思想很容易理解，如果数个数据库，初始状态一致，只要之后的进行的操作一致，就能保证之后的数据一致。由此RAFT使用的是Log进行同步，并且将服务器分为三中角色：Leader，Follower，Candidate，相互可以互相转换。
RAFT从大的角度看，分为两个过程：
- 选举Leader
- Leader生成Log，并与Follower进行Headbeats同步
注：此处 log 并非是指日志消息，而是各种事件的发生记录。
选举Leader
Follower自增当前任期，转换为Candidate，对自己投票，并发起RequestVote RPC，等待下面三种情形发生；
获得超过半数服务器的投票，赢得选举，成为Leader
另一台服务器赢得选举，并接收到对应的心跳，成为Follower
选举超时，没有任何一台服务器赢得选举，自增当前任期，重新发起选举
同步日志
Leader接受客户端请求，Leader更新日志，并向所有Follower发送Heatbeats，同步日志。所有Follwer都有ElectionTimeout，如果在ElectionTimeout时间之内，没有收到Leader的Headbeats，则认为Leader失效，重新选举Leader。
安全性保证
日志的流向只有Leader到Follower，并且Leader不能覆盖日志
日志不是最新者不能成为Candidate
一个生动的演示动画：
http://thesecretlivesofdata.com/raft/
dBFT： delegated BFT 授权拜占庭容错算法
小蚁采用的dBFT机制，是由权益来选出记账人，然后记账人之间通过拜占庭容错算法来达成共识。
此算法在PBFT基础上进行了以下改进：
将C/S架构的请求响应模式，改进为适合P2P网络的对等节点模式；
将静态的共识参与节点改进为可动态进入、退出的动态共识参与节点；
为共识参与节点的产生设计了一套基于持有权益比例的投票机制，通过投票决定共识参与节点（记账节点）；
在区块链中引入数字证书，解决了投票中对记账节点真实身份的认证问题。
优点：
专业化的记账人；
可以容忍任何类型的错误；
记账由多人协同完成，每一个区块都有最终性，不会分叉；
算法的可靠性有严格的数学证明；
缺点：
- 当有1/3或以上记账人停止工作后，系统将无法提供服务；
- 当有1/3或以上记账人联合作恶，且其它所有的记账人被恰好分割为两个网络孤岛时，恶意记账人可以使系统出现分叉，但是会留下密码学证据；
以上总结来说，dBFT机制最核心的一点，就是最大限度地确保系统的最终性，使区块链能够适用于真正的金融应用场景。
POOL验证池
基于传统的分布式一致性技术，加上数据验证机制。
优点：
不需要代币也可以工作，在成熟的分布式一致性算法（Pasox、Raft）基础上，实现秒级共识验证。
缺点：
去中心化程度不如bitcoin；更适合多方参与的多中心商业模式。
参考
原文：区块链共识机制有哪些？
作者：李爱林
