1.1 共识机制1.1.1 核心定义区块链上的共识机制主要解决谁构建区块以及如何维护区块链统一性的问题

1.1.2 共识机制分类共识机制分类

1.1.3 共识算法1.1.3.1 POW（Proof of Work）代表项目：BTC

由于不同的节点接受不同的数据，为了保证数据的一致性，每个区块数据只能由一个节点记录。 BTC通过“工作量证明”（PoW）来确认记账节点。如果每个节点想要生成一个新的区块并将其写入区块链，就必须解决比特币网络的PoW 问题。关键要素是工作量证明函数、区块信息和难度值。工作量证明函数是这道题的计算方式，区块决定了这道题的输入数据，难度值决定了这道题需要的计算量。可以简单理解，成就就是以不同的nonce值作为输入，尝试进行SHA256哈希运算，找到一个满足给定个数前导0的哈希值的过程。需要的前导0 越多，难度就越大。

比特币节点解决工作量证明问题的步骤大致概括如下：

生成造币交易并与所有其他准备打包入块的交易组成交易列表，通过默克尔树算法生成默克尔根哈希；将Merkle根哈希等相关字段组装成区块头，并将区块头的80字节数据作为工作量证明的输入；块头中的随机数不断变化，即nonce的值，对每一个变化的块头（即SHA256(SHA256(Block_Header))）进行双重SHA256运算，并将结果与值进行比较与当前网络的目标值。如果小于目标值，则问题成功解决，工作量证明完成。 1.1.3.2 POS（Proof of Equity）代表项目：目前以太坊的共识机制正在向POS方向迭代

由于PoW方式需要消耗大量算力，大家陷入算力竞争，导致算力集中在顶级矿场存在安全隐患。同时，挖矿过程没有实用价值，于是出现了POS机制。

目前PoS机制还有待解决的问题，仍在开发中。目前比较普遍的方法是第一个Peercoin采用的方法。

在以Peercoin为代表的PoW+PoS混合共识中，采用的权益证明PoS模式下，有一个词叫币龄，每个币每天产生1个币龄，难度与交易输入相关哈希计算。币龄成反比。同时，出块后清零币龄。但参与出块的节点仍然需要进行一定量的哈希值计算，即以类似工作量的方式出块，但每个节点通过计算找到合法区块的概率为与节点持有的权益相关。即根据权益选择生产者，采用基于权益的激励方式。只是在一定程度上解决了POW机制带来的大量能源消耗和浪费问题。

以以太坊Casper为代表的新PoS共识

验证者将他们拥有的以太币的一定百分比作为保证金。然后，开始在每个区块高度验证每个候选区块（由支付押金的验证者提交的区块）。也就是说，当他们找到一个他们认为可以添加到链中的区块时，他们将通过下注来验证它。通过多个验证者的押注，为每个高度选出唯一获胜的区块。如果将区块添加到链中，则验证者将获得与其股份成比例的奖励。但是，如果验证者恶意行为，试图做“无抵押”（比如多次下注，重复下注），他们将立即受到惩罚。 1.1.3.3 DPOS（Delegated Proof of Stake）代表项目：EOS 为PoS机制的加密货币，每个节点可以创建一个区块。 DPoS 是由社区选举产生的可信账户（超级账户）来创建区块。 DPoS机制类似于股份制公司。普通股东不能进入董事会，必须投票选出代表（受托人）代表他们做决定。

1.1.3.4 PBFT（Practical Byzantine Fault Tolerant Algorithm） PBFT的设计思想被很多共识机制借鉴，也被很多联盟链采用。

除了支持容错故障节点外，还支持容错恶意节点。假设集群节点数为N，问题节点数为f。 pbft 算法的最大容错节点数为(n-1)/3。在问题节点中，既可以是故障节点又可以是恶意节点，也可以只是故障节点或恶意节点。

假设故障节点和恶意节点是不同的节点。那么就会有f个问题节点和f个故障节点。当发现一个节点是有问题的节点时，它将被排除在集群之外，留下f 个故障节点。根据小数服从多数的原则，集群中正常的节点只需要比较f 个节点是否多了一个节点，即f+1 个节点，则正确节点的数量会多于故障节点的数量，然后集群才能达成共识。所以，所有

有类型的节点数量加起来就是 f+1 个正确节点，f个故障节点和f个问题节点，即 3f+1=n

pbft 算法的基本流程主要有以下四步：

1. 客户端发送请求给主节点
2. 主节点广播请求给其它节点，节点执行 pbft 算法的三阶段共识流程。
3. 节点处理完三阶段流程后，返回消息给客户端。
4. 客户端收到来自 f+1 个节点的相同消息后，代表共识已经正确完成。为什么收到 f+1 个节点的相同消息后就代表共识已经正确完成？从上一小节的推导里可知，无论是最好的情况还是最坏的情况，如果客户端收到 f+1 个节点的相同消息，那么就代表有足够多的正确节点已全部达成共识并处理完毕了。

1.1.3.5 RAFT

Fabric：已实现了raft算法与PBFT不同，RAFT不支持作恶节点，因此更多的用于私链中。raft 算法包含三种角色，分别是：跟随者（ follower ），候选人（candidate ）和领导者（ leader ）。集群中的一个节点在某一时刻只能是这三种状态的其中一种，这三种角色是可以随着时间和条件的变化而互相转换的。

raft 算法主要有两个过程：一个过程是领导者选举，另一个过程是日志复制，其中日志复制过程会分记录日志和提交数据两个阶段。raft 算法支持最大的容错故障节点是（N-1）/2，其中 N 为 集群中总的节点数量。

在Raft中，每个结点会处于下面三种状态中的一种：

1. follower：所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态
2. candidate：会向其他结点“拉选票”，如果得到大部分的票则成为leader。这个过程就叫做Leader选举(Leader Election)
3. leader：所有对系统的修改都会先经过leader。每个修改都会写一条日志(log entry)leader收到修改请求后的过程如下，这个过程叫做日志复制(Log Replication)：
4. 复制日志到所有follower结点(replicate entry)
5. 大部分结点响应时才提交日志
6. 通知所有follower结点日志已提交
7. 所有follower也提交日志
8. 整个系统处于一致的状态

Raft算法动画： http://link.zhihu.com/?target=http%3A//thesecretlivesofdata.com/raft/

1.1.4共识算法对比1.1.4.1 PBFT VS RAFT

PBFT vs RAFT

1.1.4.2 主流算法对比

共识算法

1.1.4.3 ZAB协议与Raft协议比较

ZAB 是通过“一切以领导者为准”的强领导者模型和严格按照顺序处理、提交提案，来实现操作的顺序性的。主节点是基于 TCP 协议来广播消息的，并保证了消息接收的顺序性。出来的比较早。

Raft协议是Raft协议就是一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致性。通过日志的连续性来保证消息或者说是数据的顺序性以及完整性。Raft协议中日志不仅是数据的载体，同时，日志的完整性还会影响领导者选举的结果（注：选举的因素不仅仅只有日志的完整性来保证，还有任期等其他因素）。

Raft目前是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。在这里强调了是在工程上，因为在学术理论界，最耀眼的还是大名鼎鼎的Paxos。

异同点：

1. 领导者选举：ZAB 采用的“见贤思齐、相互推荐”的快速领导者选举（Fast Leader Election），节点间通过PK竞争（资本是所持有的信息）看哪个节点更适合做Leader，一个节点PK后，会将选票信息广播出去，最终选举出了大多数节点中数据最完整的节点。Raft 采用的是“一张选票、先到先得”的自定义算法（注：里面包含了一个随机等待时间的概念，来保证最多几次选举就能完整选举过程。），这里简单说一下就是一个节点发现leader挂了，就选举自己为leader，然后通知其他节点，其他节点把选票投给第一个通知它的节点。（注：这里其实也会涉及到PK，根据数据的完整性以及任期等信息，如果通知它的节点 没有当前节点的数据完整等那么 当前节点是不会将选票投给该节点）以上看来，Raft 的领导者选举，需要通讯的消息数更少，选举也更快。
2. 日志复制：Raft 和 ZAB 相同，都是以领导者的日志为准来实现日志一致，而且日志必须是连续的，也必须按照顺序提交。ZAB通过TCP来保证操作的顺序性。Raft协议通过Log Entry 加自己的校验来实现日志的连续性。建议看上面的博客文章
3. 读操作和一致性：ZAB 的设计目标是操作的顺序性，在 ZooKeeper 中默认实现的是最终一致性，读操作可以在任何节点上执行；（注：很多地方说ZK是CP这没有毛病，但是并不是指ZK中的读写时强一致性，是指在发生P的时候，ZK是C，或者看到这个很懵，看下上面的博客，以及仔细看下CAP理论的图，里面也清晰的标记着在没发生P的时候，AC是可以共存的）而 Raft 的设计目标是强一致性（也就是线性一致性），所以 Raft 更灵活（可以自己配置），Raft 系统既可以提供强一致性，也可以提供最终一致性，但是一般为了保证性能，默认提供的也是最终一致性。
4. 写操作：Raft 和 ZAB 相同，写操作都必须在领导者节点上处理。
5. 成员变更：Raft 和 ZAB 都支持成员变更，其中 ZAB 以动态配置（dynamic configuration）的方式实现的。那么当你在节点变更时，不需要重启机器，集群是一直运行的，服务也不会中断。
6. 设计阶段：相比 ZAB，Raft 的设计更为简洁，比如 Raft 没有引入类似 ZAB 的成员发现和数据同步阶段，而是当节点发起选举时，递增任期编号，在选举结束后，广播心跳，直接建立领导者关系，然后向各节点同步日志，来实现数据副本的一致性。ZAB协议的数据同步的阶段，ZAB集群式无法对外提供服务。其实，ZAB 的成员发现，可以和领导者选举合到一起，类似 Raft，在领导者选举结束后，直接建立领导者关系，而不是再引入一个新的阶段；数据同步阶段，是一个冗余的设计，可以去除的，因为 ZAB 不是必须要先实现数据副本的一致性，才可以处理写请求，而且这个设计是没有额外的意义和价值的。
7. 设计独立性ZAB 和 ZooKeeper 强耦合，你无法在实际系统中独立使用；而 Raft 的实现（比如 Hashicorp Raft）是可以独立使用的，编程友好。