区块链核心技术——共识算法

本文是对区块链技术中涉及的共识算法的学习总结整理。 其中PBFT和Raft是联盟链和私有链常用的共识算法，而PoW和PoS是公有链常用的共识算法。

一、实用拜占庭容错系统PBFT

拜占庭容错技术（Byzantine Fault Tolerance,BFT）是一类分布式计算领域的容错技术，是一种解决分布式系统容错问题的通用方案。实用拜占庭容错系统（Practical Byzantine Fault Tolerance，PBFT）使拜占庭协议的运行复杂度从指数级别降低到多项式级别，使拜占庭协议在分布式系统中应用成为可能。

1.1 拜占庭将军问题

拜占庭将军（Byzantine Generals Problem）问题，是 Leslie Lamport 1982 年提出用来解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于将军中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消息，试图会干扰一致性的达成。拜占庭问题即为在此情况下，如何让忠诚的将军们能达成行动的一致。

1.2 拜占庭容错系统

拜占庭容错系统是指：在一个拥有n台节点的系统，整个系统，对每个请求满足如下条件：

• 所有非拜占庭节点使用相同的输入信息，产生同样的结果；
• 如果输入的信息正确，那么所有非拜占庭节点必须接收这个信息，并计算相应的结果。

与此同时,在拜占庭系统的实际运行过程中一般假设系统中拜占庭节点不超过m台，并且对每个请求满足2个指标：

• 安全性——任何已经完成的请求都不会被更改，它可以在以后请求看到；
• 活性——可以接受并且执行非拜占庭客户端的请求，不会被任何因素影响而导致非拜占庭客户端的请求不能执行。

拜占庭系统目前普遍采用的假设条件包括:
1) 拜占庭节点的行为可以是任意的，拜占庭节点之间可以共谋；
2) 节点之间的错误是不相关的；
3) 节点之间通过异步网络连接，网络中的消息可能丢失、乱序、延时到达；
4) 服务器之间传递的信息,第三方可以知晓 ,但是不能窜改、伪造信息的内容和验证信息的完整性；

（发生故障的节点称为拜占庭节点；正常的节点为非拜占庭节点。）

1.3 状态机拜占庭系统

状态机拜占庭系统的特点

状态机拜占庭系统的特点是整个系统共同维护一个状态,所有节点采取一致的行动,一般包括 3 种协议：一致性协议、 检查点协议和视图更换协议。系统正常运行在一致性协议和检查点协议下，视图更换协议则是只有在主节点出错或者运行缓慢的情况下才会启动，负责维系系统继续执行客户端请求的能力。

状态机拜占庭系统的核心协议

一、一致性协议
一致性协议的目标是使来自客户端的请求在每个服务器上都按照一个确定的顺序执行。在协议中，一般有一个服务器被称作主节点，负责将客户端的请求排序；其余的服务器称作从节点，按照主节点提供的顺序执行请求。所有的服务器都在相同的配置信息下工作，这个配置信息称作view，每更换一次主节点，view就会随之变化。

一致性协议至少包含3个阶段：发送请求、序号分配和返回结果。根据协议设计的不同，可能包含相互交互、序号确认等阶段。

一致性协议解决一致性的方法主要有：
1）服务器之间两两交互，服务器通过将自己获得的信息传递给其他的服务器；
2）由客户端收集服务器的信息，将收集的信息制作成证明文件再发送给服务器。对于一个包含3m+1台服务器的拜占庭系统，需要收集到2m+1台服务器发送的一致信息，才能保证达成一致的非拜占庭服务器数量大于拜占庭服务器数量。

二、检查点协议
拜占庭系统每执行一个请求，服务器需要记录日志。如果日志得不到及时的清理，就会导致系统资源被大量的日志所占用，影响系统性能及可用性。另一方面，由于拜占庭服务器的存在，一致性协议并不能保证每一台服务器都执行了相同的请求，所以，不同服务器状态可能不一致。例如，某些服务器可能由于网络延时导致从某个序号开始，之后的请求都没有执行。因此，拜占庭系统中设置周期性的检查点协议，将系统中的服务器同步到某一个相同的状态。因此，周期性的检查点协议可以定期地处理日志，节约资源，同时及时纠正服务器状态。

处理日志主要解决的问题就是区分那些日志可以清理，那些日志仍然需要保留。如果一个请求已经被m+1台非拜占庭服务器执行，并且某一服务器i能够向其他的服务器证明这一点，那么i就可以将关于这个请求的日志删除。目前，协议普遍采用的方式是服务器每执行一定数量的请求，就将自己的状态发送给所有服务器并且执行一个该协议，如果某台服务器接收到2m+1台服务器的状态，那么其中一致的部分就是至少有m+1非拜占庭服务器经历过的状态，因此，这部分的日志就可以删除，同时将自己状态更新只较新状态。

三、视图更换
在一致性协议里，已经知道主节点在整个系统中拥有序号分配，请求转发等核心能力，支配着这个系统的运行行为。然而一旦主节点自身发生错误，就可能导致从节点接收到具有相同序号的不同请求，或者同一个请求被分配多个序号等问题，这将直接导致请求不能被正确执行。视图更换协议的作用就是在主节点不能继续履行职责时，将其用一个从节点替换掉，并且保证已经被非拜占庭服务器执行的请求不会被篡改。

视图更换协议一般有两种触发方式：
1）只由服务器触发，这一类触发方式中，判断服务器一致性是否达成的工作是由服务器自身负责，客户端不能从请求的整个执行过程中获得服务器运行状况的信息；
2）客户端触发，这一类触发方式中，客户端一般负责判断服务器是否达成一致，如果不达成一致，那么就能判断服务器运行出现问题，如果是主节点的问题就会要求服务器更换主节点。

视图更换协议需要解决的问题是如何保证已经被非拜占庭服务器执行的请求不被更改。由于系统达成一致性之后至少有m+1台非拜占庭服务器执行了请求，所以目前采用的方法是：由新的主节点收集至少2m+1台服务器的状态信息，这些状态信息中一定包含所有执行过的请求；然后，新主节点将这些状态信息发送给所有的服务器，服务器按照相同的原则将在上一个主节点完成的请求同步一遍.同步之后,所有的节点都处于相同的状态,这时就可以开始执行新的请求。

1.4 实用拜占庭容错系统PBFT详解

实用拜占庭容错系统（Practical Byzantine Fault Tolerance，PBFT），是一类状态机拜占庭系统。

PBFT的一致性协议如下：PBFT系统通常假设故障节点数为m个，而整个服务节点数为3m+1个。每一个客户端的请求需要经过5个阶段，通过采用两次两两交互的方式在服务器达成一致之后再执行客户端的请求。由于客户端不能从服务器端获取任何服务器运行的状态信息，PBFT中主节点是否发生错误只能由服务器监测。如果服务器在一段时间内都不能完成客户端的请求，则会触发视图更换协议。

上图显示了一个简化的PBFT的协议通信模式，其中C为客户端，N0~N3表示服务节点，特别的，N0为主节点，N3为故障节点。整个协议的基本过程如下：
1）客户端发送请求，激活主节点的服务操作；
2）当主节点接收请求后，启动三阶段的协议以向各从节点广播请求；

1. 序号分配阶段，主节点给请求赋值一个序号n，广播序号分配消息和客户端的请求消息m，并将构造pre-prepare消息给各从节点；
2. 交互阶段，从节点接收pre-prepare消息，向其他服务节点广播prepare消息；
3. 序号确认阶段，各节点对视图内的请求和次序进行验证后，广播commit消息，执行收到的客户端的请求并给客户端响应。

3）客户端等待来自不同节点的响应，若有m+1个响应相同，则该响应即为运算的结果；

二、Raft协议

Raft是在非拜占庭故障下达成共识的强一致协议。在区块链系统中，使用Raft实现记账共识的过程可以描述如下：首先选举一个leader，接着赋予leader完全的权利管理记账。leader从客户端接收记账请求，完成记账操作，生成区块，并复制到其他记账节点。有了leader简化了记账操作的管理。如果leader失效或与其他节点失去联系，这时，系统就会选出新的leader。

2.1 Raft基础

一个Raft集群通常包含5个服务器，允许系统有2个故障服务器。每个服务器处于3个状态之一：leader、follower或candidate。正常操作状态下，仅有一个leader，其他的服务器均为follower。follower是被动的，不会对自身发出的请求而是对来自leader和candidate的请求做出响应。leader处理所有的客户端请求（若客户端联系follower，则该follower将转发给leader)。candidate状态用来选举leader。

Raft阶段主要分为两个，首先是leader选举过程，然后在选举出来的leader基础上进行正常操作，比如日志复制、记账等。

2.2 leader选举

当follower在选举超时时间内未收到leader的心跳消息，则转换为candidate状态。为了避免选举冲突，这个超时时间是一个150~300ms之间的随机数。

一般而言，在Raft系统中：
1）任何一个服务器都可以成为一个候选者candidate，它向其他服务器follower发出要求选举自己的请求。
2）其他服务器同意了，发出OK。如果在这个过程中，有一个follower宕机，没有收到请求选举的要求，此时候选者可以自己选自己，只要达到N/2+1的大多数票，候选人还是可以成为leader。
3）这样这个候选者就成为了leader领导人，它可以向follower发出指令，比如进行记账。
4）以后可以通过心跳进行记账的通知。
5）一旦这个leader崩溃了，那么follower中有一个成为候选者，并发出邀票选举。
6）follower同意后，其成为leader，继续承担记账等指导工作。

2.3 记账过程

Raft的记账过程按以下步骤完成：
1）假设leader领导人已经选出，这时客户端发出增加一个日志的要求；
2）leader要求follower遵从他的指令，都将这个新的日志内容追加到他们各自日志中；
3）大多数follower服务器将交易记录写入账本后，确认追加成功，发出确认成功消息；
4）在下一个心跳中，leader会通知所有follower更新确认的项目。
对于每个新的交易记录，重复上述过程。

如果在这一过程中，发生了网络通信故障，使得leader不能访问大多数follower，那么leader只能正常更新它能访问的那些follower服务器。而大多数的服务器follower因为没有了leader，它们将重新选举一个候选者作为leader，然后这个leader作为代表与外界打交道，如果外界要求其添加新的交易记录，这个新的leader就按上述步骤通知大多数follower，如果这时网络故障修复了，那么原先的leader就变成follower，在失联阶段，这个老leader的任何更新都不能算确认，都回滚，接收新的leader的新更新。

如果想更直观的理解Raft协议，可以看这个http://thesecretlivesofdata.com/raft/，动画演示。

三、PoW

PoW的数学原理可以参看我的这篇博文中哈希函数难题友好性这一节：http://blog.csdn.net/s_lisheng/article/details/77937202，理解了难题友好性，就基本理解了PoW机制的原理。结合比特币去理解PoW。比特币PoW的过程，就是将不同的nonce值作为输入，尝试进行SHA256哈希运算，找出满足给定数量前导0的哈希值的过程。要求的前导0的个数越多，代表难度越大。比特币节点求解工作量证明问题的步骤归纳如下：

1）生成铸币交易，并与其他所有准备打包进区块的交易组成交易列表，通过Merkle树算法生成Merkle跟哈希；
2）把Merkle根哈希及其他相关字段组装成区块头，将区块头的80字节数据作为工作量证明的输入；
3）不停地变更区块头中的随机数nonce，并对每次变更后的区块头做双重SHA256运算，将结果值与当前网络的目标难度做比对，如果满足难度条件，则解题成功，工作量证明完成。

四、PoS

PoW存在以下弊端：
1）矿池的出现，一定程度上违背了去中心化的初衷；
2）PoW存在巨大的算力浪费，这个很容易理解。

PoS（权益证明，Proof of Stake）的出现很大程度上是因为PoW的缺陷而提出的。采用PoS的币中不同币的PoS不完全相同，权益证明要求用户证明拥有某些数量的货币（即对货币的权益），下面以点点币为例，理解PoS的思想。

点点币在SHA256的哈希运算的难度方便引入了币龄的概念，使得难度与交易输入的币龄成反比。在点点币中，币龄被定义为币的数量与币所拥有的天数的乘积。点点币的权益证明机制结合了随机化与币龄的概念，未使用至少30天的币可以参与竞争下一区块，越久和越大的币集有更大的可能去签名下一区块。而一旦币的权益被用于签名一个区块，则币龄将清为零，这样必须等待至少30日才能签署另一个区块。同时，为防止非常老或非常大的权益控制区块链，寻找下一区块的最大概率在90天后达到最大值，这一过程保护了网络，并随着时间逐渐成为新的币而无需消耗大量的计算能力。

五、DPoS

PoS机制虽然考虑了PoW的不足，但也有缺点：依据权益结余来选择，会导致首富账户的权力更大，有可能支配记账权。

股份授权证明机制（Delegated Proof of Stake，DPoS），是对PoW、PoS不足的提出的。下面以比特股为例，理解DPoS的思想。

比特股引入了见证人这个概念，见证人可以生成区块，每一个持有比特股的人都可以投票选举见证人。得到总同意票数中的前N个（N通常定义为101）候选者可以当选为见证人，当选见证人的个数需满足：至少一半的参与投票者相信N已经充分地去中心化。见证人的候选名单每个维护周期（1天）更新一次。见证人然后随机排列，每个见证人按序有2秒的权限时间生成区块，若见证人在给定的时间片不能生成区块，区块生成权限交给下一时间片对应的见证人。如果见证人提供的算力不稳定或计算机宕机等，持股人可以随时通过投票更换这些见证人。

参考资料：
拜占庭共识算法之PBFT：http://www.jianshu.com/p/fb5edf031afd
Raft动画演示：http://thesecretlivesofdata.com/raft/
The Raft Consensus Algorithm：https://raft.github.io/