The consensus algorithm block chain

Requirements: mainstream consensus algorithm appreciated, including, without limitation PoW, PoS, DPoS, PBFT, Paxos, Raft the like;

1. What is the consensus mechanism?

We all know that the block chain can be regarded as a record of all transactions in the books of publicly distributed, each participant block chain network sees it as an authoritative record of ownership.

Open the books of historical data can not be tampered with, allowing only later added, each node has the same privileges, then it creates a problem:

Open books for each new block of who is responsible for writing?
Because all nodes are the same, if all nodes simultaneously write data books together, so sure the data is inconsistent.

Therefore, a mechanism is needed to ensure that each block of the block chain by only one node is responsible for writing, how to write books selected node data, which is the consensus mechanism. Let equal participants agree according to a certain order.

Figuratively,

There is now a central database, to query all clients, each client privilege is the same, but if you want to additions and deletions to the database, I am sorry, allows only one client to operate, popular talk, is to make database serial modify the database. By an algorithm mechanism to choose a client operation. The mechanism is a consensus mechanism, the so-called consensus is equality in society, we need to form a common consensus, the operator generates a temporary policy makers, on behalf of everyone to operate centralized, according to the consensus of everyone to keep to the center of the online world.

2, the mainstream consensus algorithm What?

The most important block chain in the final analysis, the consensus algorithm distributed system consistency problem: how to ensure data consistency in a distributed network.

Speaking of consistency, we would have to mention the famous Byzantine generals problem. Is a fictional model Leslie Lamport 1982 put forward to explain the consistency problem. Ancient Byzantine capital of the Eastern Roman Empire, due to the large land area, the border guard more general (multiple-node system) need to pass messages through the messenger, some unanimous decision. But because there may be a traitor generals (the failed node system), these traitors will try to send different messages to different generals, tried to interfere with the consistency of reach.
Leslie Lamport proved that when the mutineers of not more than 1/3, the existence of efficient algorithms, no matter how frustrating the mutineers and loyal generals can always reach consistent results. If the mutineers too much, it can not guarantee it will be to achieve consistency.

Byzantine generals problem for two cases:

1) for non-Byzantine error, generally including Paxos, Raft (private chain commonly used) and its variants.

Distributed database design are generally based on paxos or raft algorithm.

The basic use of open-source database of variants raft and paxos:
Baidu open source: Baidu officially open its Raft consistency algorithm braft http://www.infoq.com/cn/news/2018/03/Baidu-open-source-Raft- algorithm
Ali revenue: AliSQL X-Cluster-based high-performance MySQL X-Paxos strong consistent database http://tech.it168.com/a2017/0803/3159/000003159063.shtml

Open source Ali: Ali cloud the new generation of relational database PolarDB analysis using distributed Raft protocols to ensure data consistency and strong, with more excellent recovery time, and more to meet the needs of data backup disaster recovery and other business scenarios. http://www.infoq.com/cn/articles/ali-polardb

Micro-channel open source: production-level paxos library
PhxPaxos implement the principles introduces http://www.infoq.com/cn/articles/weinxin-open-source-paxos-phxpaxos

2) to be able to tolerate Byzantine errors, generally include PBFT series (Union common chain), PoW (public chain commonly used) series of algorithms.

From a probability point of view, PBFT series algorithm is determined, once a consensus on irreversible; and PoW family of algorithms is uncertain, as time goes on, more and more small probability of being overthrown.

3, non-Byzantine fault consensus algorithm of Raft agreement

Raft is a strong consensus agreement reached consensus in a non-Byzantine fault. In block chain system, a billing process to achieve consensus Raft be described as follows: First, a leader election, and then given a complete leader rights management accounting. leader accounting request received from a client, the accounting operation is completed, generation block, and copied to other billing nodes. With leader simplifies the management of billing operations. If the leader fails or loses contact with other nodes, then the system will elect a new leader.

Raft foundation

Consistent data RAFT core idea is easy to understand, if the number of databases, the same initial state, as long as the same operation performed after, we can guarantee thereafter. RAFT using Log thereby synchronized, and the server is divided into three roles: Leader, Follower, Candidate, mutually interchangeable.
RAFT from the big perspective, is divided into two processes:

1. Election Leader
2. Leader generates Log, and synchronized with Headbeats Follower

Raft a server cluster typically contain five, allows the system to have two failed server. Each server in one of three states: leader, follower or candidate. Under normal operating conditions, there is only one leader, the other servers are follower. follower is passive, the request will not be sent on their own but responds to a request from the leader and candidate of. leader handles all client requests (if the client contacts the follower, the follower will be forwarded to the leader). candidate for the state election leader.

Raft is divided into two stages, first leader of the electoral process, and then normal operation leader elected on the basis of, for example, log replication, billing and so on.

leader election

When the follower heartbeat message is not received within the election leader of the timeout, then converted to a candidate state. In order to avoid electoral conflict, this time-out is a random number between 150 ~ 300ms.

In general, Raft system:

• 1) Any server can become a candidate for a candidate, it sends a request to elect their own requirements to other server follower.
• 2) the consent of the other servers, send out OK. If in the process, there is a follower of downtime, no requests call for the election, in which case you can choose their own candidates themselves, as long as to reach a majority of votes N / 2 + 1, the candidate can still become a leader.
• 3) so that the candidate has become a leader leaders, it can issue instructions to the follower, for example, it is billed.
• 4) After the notification may be performed by accounting heartbeat.
• 5) Once the leader collapsed, then the follower has become a candidate, and issued the invitation electoral votes.
• 6) After follower agreed to become its leader, continue to bear the bookkeeping and other guidance.

image.png

Accounting process (log synchronization)

Raft billing process is completed by the following steps:

• 1) assume leader leaders have chosen, then the client makes a log increase in demand;
• 2) leader requires follower follow his instructions, the new log will be appended to the contents of their respective logs;
• 3) Most follower server will write the books after the transaction, additional confirmation is successful, a confirmation message is successful;
• 4) In the next heartbeat, leader will notify all follower update confirmation of the project.
  For each new transaction record, repeat the process.

If in the process, network communication failure occurred, so that the leader can not access most of the follower, then the leader can only update those follower server can be accessed normally. Most servers follower because there is no leader, they will be a candidate for re-election as leader, and the leader as a representative to deal with the outside world, if the outside world asking them to add a new transaction, the new leader will notice big step above most follower, if the time network troubleshooting, then the original leader to become follower, lost to phase in any update of the old leader can not be considered confirmed, are rolled back, to receive the new leader of the new update.

http://thesecretlivesofdata.com/raft/

4, non-Byzantine fault of Paxos consensus algorithm Agreement

PAXOS consistent algorithm is based on message passing and highly fault tolerant characteristics.

Algorithm itself is described in language extremely streamlined:
Phase. 1
A) proposer transmits prepare message to more than half of the acceptor in the network
b) Reply promise message the acceptor normally
Stage 2
A) when there are enough acceptor reply promise message, proposer send accept message
b) under normal circumstances acceptor reply message accepted

PAXOS There are three types of roles Proposer, Acceptor and Learner, the main interaction between the Proposer and Acceptor, it made chart as shown below:

image.png

The following diagram depicts the multi Proposer, T represents the timeline, figure painting only full relations with the Acceptor of a Proposer:

image.png

A3在T1发出accepted给A1，然后在T2收到A5的prepare，在T3的时候A1才通知A5最终结果(税率10%)。这里会有两种情况：

1. A5发来的N5小于A1发出去的N1，那么A3直接拒绝(reject)A5
2. A5发来的N5大于A1发出去的N1，那么A3回复promise，但带上A1的(N1, 10%)
   最终A5也会接受10%

image.png

上图描述，如果已经Promise一个更大的N，那么会直接Reject更小的N

image.png

 

上述描述了，即使Promise了一个N，如果在未Accepted前，再收到一个更大的N，那么依旧会Reject那个即使已经Promise的N

总流程图概括如下：

 

image.png

5、非拜占庭故障共识算法之Pool验证池

Pool验证池，基于传统的分布式一致性技术，加上数据验证机制；Pool（联营）验证池是目前行业内大范围使用的共识机制

• 优点：不需要代币也可以工作，在成熟的分布式一致性算法（Paxos、Raft）基础上，实现秒级共识验证；
• 缺点：去中心化程度不如bictoin；更适合多方参与的多中心商业模式

6、拜占庭容错共识算法之 PBFT 系列

拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或断开以及遭到恶意攻击，计算机和网络可能出现不可预料的行为。拜占庭容错协议必须处理这些失效，并且这些协议还要满足所要解决的问题要求的规范。这些算法通常以其弹性t作为特征，t表示算法可以应付的错误进程数。很多经典算法问题只有在n ≥ 3t+1时才有解，如拜占庭将军问题，其中n是系统中进程的总数。

拜占庭容错能够容纳将近1/3的错误节点误差，IBM创建的Hyperledger就是使用了该算法作为共识算法。

1） PBFT机制：

PBFT：用拜占庭容错系统（Practical Byzantine Fault Tolerance）是一种状态机副本复制算法，即服务作为状态机进行建模，状态机在分布式系统的不同节点进行副本复制。每个状态机的副本都保存了服务的状态，同时也实现了服务的操作。将所有的副本组成的集合使用大写字母R表示，使用0到|R|-1的整数表示每一个副本。为了描述方便，假设|R|=3f+1，这里f是有可能失效的副本的最大个数。尽管可以存在多于3f+1个副本，但是额外的副本除了降低性能之外不能提高可靠性。

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

基于拜占庭将军问题，一致性的确保主要分为这三个阶段：预准备（pre-prepare）、准备(prepare)和确认(commit)。流程如下图所示：

image.png

上图显示了一个简化的PBFT的协议通信模式，其中C 为客户端，N0 ~ N3表示服务节点，特别的，N0为主节点，N3 为故障节点。整个协议的基本过程如下：

Request：客户端发送请求，激活主节点的服务操作，当主节点接收请求后，启动三阶段的协议以向各从节点广播请求；

pre-prepare：主节点给请求赋值一个序号n ，广播序号分配消息和客户端的请求消息m ，并将构造pre-prepare消息给各从节点；
prepare：交互阶段，从节点接收pre-prepare消息，再次向其他服务节点广播prepare消息；
commit：在Prepare阶段，若收到超过一定数量的相同请求，则进入Commit阶段，各节点对视图内的请求和次序进行验证后，广播Commit请求；

reply：在Commit阶段，若收到超过一定数量的相同请求，则执行客户端的请求并给客户端响应；
根据上述流程，在 N ≥ 3F + 1 的情況下一致性是可能解決，N为总计算机数，F为有问题的计算机总数

2） DBFT机制

是由权益来选出记账人，然后记账人之间通过拜占庭容错算法来达成共识，
这种方式的优点是：

• 1)专业化的记账人；
• 2)可以容忍任何类型的错误；
• 3)记账由多人协同完成，每一个区块都有最终性，不会分叉；
• 4)算法的可靠性有严格的数学证明；

缺点：

• 1)当有1/3或以上记账人停止工作后，系统将无法提供服务；
• 2)当有1/3或以上记账人联合作恶，且其它所有的记账人被恰好分割为两个网络孤岛时，恶意记账人可以使系统出现分叉，但是会留下密码学证据；
  对于拜占庭将军问题可自行网上查找资料，很多这里不再赘述。

7、拜占庭容错共识算法之 PoW 系列算法

1）工作量证明PoW

工作量证明，Proof of Work，通过计算来猜测一个数值（nonce），得以解决规定的 hash 问题（来源于 hashcash）。保证在一段时间内，系统中只能出现少数合法提案。

同时，这些少量的合法提案会在网络中进行广播，收到的用户进行验证后会基于它认为的最长链上继续难题的计算。因此，系统中可能出现链的分叉（Fork），但最终会有一条链成为最长的链。

这个过程，就是大家熟悉的挖矿，通过hash运算，计算出一个满足规则的随机数，即获得本次记账权，把已经打包好的区块添加到区块链，然后广播到全网，全网其它节点验证后一起添加到本地节点的区块链上

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

2）权益证明PoS

权益证明，Proof of Stake，2013 年被提出，最早在 Peercoin 系统中被实现，根据每个节点所拥有代币的比例和时间；等比例的降低挖矿难度，从而加快找随机数的速度。类似现实生活中的股东机制，拥有股份越多的人越容易获取记账权。

典型的过程是通过保证金（代币、资产、名声等具备价值属性的物品即可）来对赌一个合法的块成为新的区块，收益为抵押资本的利息和交易服务费。提供证明的保证金（例如通过转账货币记录）越多，则获得记账权的概率就越大。合法记账者可以获得收益。
PoS 是试图解决在 PoW 中大量资源被浪费的缺点。恶意参与者将存在保证金被罚没的风险，即损失经济利益。

一般的，对于 PoS 来说，需要掌握超过全网 的资源，才有可能左右最终的结果。这个也很容易理解，三个人投票，前两人分别支持一方，这时候，第三方的投票将决定最终结果。

• 优点：在一定程度上缩短了共识达成的时间
• 缺点：还是需要挖矿，本质上没有解决商业应用的痛点

3）授权股权证明机制DPOS

PoS 的改进算法，DPOS与POS原理相似。与POS的主要区别在于节点选举若干代理，由代理人验证和记账。类似于董事会投票，持币者投出一定数量的节点，代理他们进行验证和记账。

PoW机制和PoS机制虽然都能有效地解决记账行为的一致性共识问题，但是现有的比特币PoW机制纯粹依赖算力，导致专业从事挖矿的矿工群体似乎已和比特币社区完全分隔，某些矿池的巨大算力俨然成为另一个中心，这与比特币的去中心化思想相冲突。PoS机制虽然考虑到了PoW的不足，但依据权益结余来选择，会导致首富账户的权力更大，有可能支配记账权。

股份授权证明机制( Delegated Proof of Stake，DPoS)的出现正是基于解决PoW机制和PoS机制的这类不足。

优点：大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证
缺点：整个共识机制还是依赖于代币，很多商业应用是不需要代币存在的

8、目前主流区块链采用的共识算法

主流区块链采用的共识算法汇总如下：

image

image

• 1）PoW共识算法代表：比特币&莱特币&以太坊

比特币采用的是PoW（Proof of Work），工作量证明，通过计算来猜测一个数值（nonce），得以解决规定的 hash 问题。

需要以下参数：

block的版本 version
上一个block的hash值: prev_hash
需要写入的交易记录的hash树的值: merkle_root
更新时间: ntime
当前难度: nbits
挖矿的过程就是找到x使得以下等式成立：

SHA256(SHA256(version + prev_hash + merkle_root + ntime + nbits + x )) < TARGET

上式的x的范围是0~2^32, TARGET可以根据当前难度求出的。由于hash的特性，找这样一个x只能暴力搜索。

PoW共识算法的核心是所有节点通过暴力查找x，使得上面的等式成立。

谁先找到谁就或者这一区块的写入权，并获得奖励，因此pow共识机制对所有节点都公平，谁的算力强谁就更有机会更高概率获得写入权。

以太坊也是采用PoW工作量证明算法，具体实现算法叫（Ethash）

• 2）PoS机制代表：Peercoin(点点币) & Nxt(未来币)

点点币（Peercoin ）的权益证明机制结合了随机化与币龄的概念，未使用至少30天的币可以参与竞争下一区块，越久和越大的币集有更大的可能去签名下一区块。然而，一旦币的权益被用于签名一个区块，则币龄将清为零，这样必须等待至少30日才能签署另区块。同时，为防止非常老或非常大的权益控制区块链，寻找下一区块的最大概率在90天后达到最大值，这一过程保护了网络，并随着时间逐渐生成新的币而无需消耗大量的计算能力。点点币的开发者声称这将使得恶意攻击变得困难，因为没有中心化的挖矿池需求，而且购买半数以上的币的开销似乎超过获得51%的工作量证明的哈希计算能力。

权益证明必须采用某种方法定义任意区块链中的下一合法区块，依据账户结余来选择将导致中心化，例如单个首富成员可能会拥有长久的优势。为此，人们还设计了其他不同的方法来选择下一合法区块。

NXT币采用随机方法预测下一合法区块，使用公式查找与权益大小结合的最小哈希值。由于权益公开，每个节点都可以合理的准确度预计哪个账户有权建立区块。

• 3）DPoS共识算法代表：Bitshare & EOS

比特股( Bitshare)是一类采用DPoS机制的密码货币，它期望通过引入一个技术民主层来减少中心化的负面影响。

比特股引入了见证人这个概念，见证人可以生成区块，每一个持有比特股的人都可以投票选举见证人。得到总同意票数中的前N个(N通常定义为101)候选者可以当选为见证人，当选见证人的个数(N)需满足：至少一半的参与投票者相信N已经充分地去中心化。

见证人的候选名单每个维护周期(1天)更新一次。见证人然后随机排列，每个见证人按序有2秒的权限时间生成区块，若见证人在给定的时间片不能生成区块，区块生成权限交给下一个时间片对应的见证人。DPoS的这种设计使得区块的生成更为快速，也更加节能。DPoS充分利用了持股人的投票，以公平民主的方式达成共识，他们投票选出的N个见证人，可以视为N个矿池，而这N个矿池彼此的权利是完全相等的。持股人可以随时通过投票更换这些见证人(矿池)，只要他们提供的算力不稳定，计算机宕机，或者试图利用手中的权力作恶。

比特股还设计了另外一类竞选，代表竞选。选出的代表拥有提出改变网络参数的特权，包括交易费用、区块大小、见证人费用和区块区间。若大多数代表同意所提出的改变，持股人有两周的审查期，这期间可以罢免代表并废止所提出的改变。这一设计确保代表技术上没有直接修改参数的权利以及所有的网络参数的改变最终需得到持股人的同意。

• 4）哪种共识算法最好？
  每一种共识算法都有各自的应用场景，没有绝对的好坏之分。到底选择哪个共识来进行区块链的实施取决于哪类网络和数据。

最近很反感一种现象：很多新区块链一上来就说自己的共识算法是PoA、PoB~PoZ（a到z的字母都快被用完了），动不动就说是颠覆性的，可实际上还是对以上介绍的几种共识算法的模仿或小改造，让初入区块链行业的人很懵逼，觉得好高大上，纯属吓唬人。

作者：张凯_9908
链接：https://www.jianshu.com/p/7bd72211733a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。