HPB50：主流共识算法分析

区块链核心框架

区块链是一个不断增加的分布式帐本[2]，帐本用“区块”的形式衔接在一块儿，区块中包含交易， 时间戳，随机数等元数据，每一个区块中含有一个指针指向上一个交易连接，区块链的设计是安 全的，由于其具备良好的拜占庭容错能力。区块链能够归纳为一个分布式的高频交易系统，如 下图 1 所示，区块链的核心技术能够总结为四部分：分布式的数据库，密码学相关理论，共识机制和 P2P 网络。

中分布式数据库负责数据的写入与读取，密码学中非对称密钥和 HASH 等算法来标识交易者的身份和保证系统的完整性；对等网络是系统运行的基础；共识算法用来保证交易信息在整个帐本不一样节点中写入的一致性，经常使用的共识算法有 POW, POS, DPOS 等。

共识算法与 CAP 理论

共识算法是为了解决在对等网络中(P2P),相互独立的节点如何达成一项决议问题的过程。简而言之，共识算法是在解决分布式系统中如何保持一致性的问题。关于此部分的讨论较为成熟和最为普遍接受的理论是 CAP 理论。CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出[4]，并提出分布式系统不能同时彻底知足 CAP 三个要求的假设，其中包括以下三个方面：

Consistency： 一致性 从不一样节点读取的数据一致。一致性是指数据的原子性，在经典的数据库中经过事务来保障，事务完成时，不管成功或回滚，数据都会处于一致的状态，在分布式环境下，一致性是指多个节点数据是否一致。

Availability： 可用性是指服务及时非错误地响应，服务一直保持可用的状态，当用户发出一个请求，服务能在必定的时间内返回结果，响应可终止、不会一直等待。

Partition tolerance：分区容错性便可靠性。可靠性的量化指标是周期内系统平均无端障运行时间. 即便有些消息延迟或者没法到达，并不影响系统的总体运行。简而言之，在网络分区的状况下，被分隔的节点仍能正常对外服务。

和全部分布式系统同样，区块链共识算法设计也是在权衡上面的三个因素，假如区块链中节点能当即确认交易数据，好处是不依赖其余节点当即可用，知足了 CAP 理论中的 AP，可风险是失去了强一致性，其余节点可能丢弃这个区块，由于区块所在的区块链分叉在竞争性的选举中失败了[5]。 为了得到 CP，客户端应该等待区块链大多数节点接受了这笔交易在真正接受它， 说明这笔交易所在分叉已经选举胜利，得到大部分共识，得到了强一致性，可是风险是可能unavailable ，丧失 CAP 的 A，由于网络分区通讯等问题可能阻止这种共识。

研究定位

区块链系统是一个将交易数据正确地固化在分布式节点上的系统。共识算法为了解决如何更安全有效的将交易数据写入到区块链上，本质上讲，共识算法旨在解决如下问题：

• 哪一个服务节点有权利生成下一个用新区块？

• 上一个区块与下一个区块之间应如何衔接

• 下一个区块什么时间产生？

• 区块中应该包含了哪些内容？

• 区块的大小是多少，一个区块中包含多少交易数据？

• 确认机制若是解决区块链分叉的问题？

本文档从多个角度分析不一样共识算法关于以上问题的解决方案，旨在为未来实际算法设计提供相关理论参考,分析方法为如下两点：

• 纵向分析：咱们以一个交易的被确认的完整过程，勾画出整个区块链系统的工做过程，纵向的分析共识算法在整个区块链系统中所扮演的角色。

• 横向对比：咱们陈列出当前加密货币中经常使用的共识算法，如 POW,POS,DPOS,PBFT 等，而后从算法的一致性，容错性，网络组织状况等方面进行对比分析。

纵向定位分析

研究共识机制旨在设计更安全，高效的区块产生方案。为了让读者更加清晰的认识共识算法在整个区块链中所扮演的角色，在本章中咱们勾画出区块产生的完整周期，并用以比特币的例子详细的讲解区块产生的过程。

图 2. 交易数据在区块链中被确认的过程

图 2 中展现了交易数据在区块链中一个完整的流转过程，在起始阶段，交易信息被客户端组装， 其中交易信息包含了交易的输入金额，输入帐户信息和输出帐户信息等，客户端能够被认为是 全节点钱包，轻钱包和各大交易平台。在一个完整的交易被生成后被称为“原始交易（Raw

Transaction）”。 原始交易并不能被矿机接收，由于缺少相应转帐人的签名。在转帐人签名完成后容许将其广播到区块链系统中，矿机采集相关交易后，通过共识算法将交易数据打包并确认到对等网络中的其余节点上。下面咱们以比特的例子详细阐述以上过程。

交易数据的组装

假设用户 A 给用户 B 进行转帐，用户 A 的的公钥为 Pk_a，私钥为 Pr_b, 用户 B 的的公钥为Pk_b，私钥为 Pr_b. 咱们按照表 1 给出的协议一步一步的给出最终可广播的内容。备注: 如下数据均为十六进制表示，咱们采用比特币中最经常使用的 Pay-to-PubkeyHash 进行分解。通过客户端的数据组合，咱们展现一个完整的交易协议以下，其中输入数据 inputs 数据能够从UTXO（Unspent Transaction Output，未开销的比特币交易输出）中获取。

表 1. 比特币原始区块链交易协议

	Version (版本)		01000000
	Input count (输入长度)		01 |
	inputs	previous output hash (上一个脚本的 hash)	be66e10da854e7aea9338c1f91cd4897 68d1d6d7189f586d7a3613f2a24d5396 |
	inputs	previous output index (上一个交易的索引)	00000000 |
	inputs	scriptSig length (表示脚本的长度)	19 |
	inputs	scriptSig(脚本签名，实际此部分为脚本的前半部分)	76a914010966776006953d5567439e5e 39f86a0d273bee88ac |
	inputs	Sequence （序列）	ffffffff |
	outputs count (输出长度)		01 |
	outputs	Value (须要转出的比特币的值，上面的输入的值减去)	605af40500000000 |
	outputs	script length (表示脚本的长度）	19 |
	outputs	script(脚本签名，实际此部分为脚本的先后半部分)	76a914097072524438d003d23a2f23ed b65aae1bb3e46988ac |
	lock time (锁定时间)		00000000 |

交易数据的签名

交易数据的完成组装后并不能当即被矿机所接受，由于交易的输出方并无对其进行有效的签名，咱们用 sha256 总体对上面的数据的 hash 进行签名，咱们假设发送者的公钥是 Pk_a, 签名后的结果为 Sig_a. 为更好的理解签名后在区块链中执行的过程，咱们将上面 inputs 中的scriptSig 进行分解76a914010966776006953d5567439e5e39f86a0d273bee88ac 分解后的内容以下表格,表 2. 未签名的 ScriptSig 数据格式分解，备注数字与操做符的对应关系能够经过https://en.bitcoin.it/wiki/Script 查询到,ScriptSig 格式以下：

	OP_DUP	76
	OP_HASH160	a9 |
	length	14 |
	pubKeyHash	010966776006953d5567439e5e39f86a0d273bee |
	OP_EQUALVERIFY	88 |
	OP_CHECKSIG	ac |

通过签名以后咱们将签名后的数据衔接在 ScriptSig 上面，所以最终的 ScriptSig 变成以下格式。表 3. 签名后的 ScriptSig 数据格式分解。

	Sig_a	Sig_a.
	Pk_a	Pk_a |
	OP_DUP	76 |
	OP_HASH160	a9 |
	pubKeyHash	14010966776006953d5567439e5e39f86a0d273bee |
	OP_EQUALVERIFY	88 |
	OP_CHECKSIG	ac |

比特币的区块链中采用的是堆栈式的语言，ScriptSig 的执行过程描述以下 ：

	堆栈	脚本	描述
	空	Sig_a \	Pk_a | OP_DUP | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | 将 Sig_a 和 Pk_a 抛出 |
	Sig_a \	Pk_a	OP_DUP | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | 将常量加入到堆栈中 |
	Sig_a \	Pk_a\	Pk_a | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | OP_DUP 做用是复制 Pk_a， 目前状态堆栈中有两个 Pk_a |
	Sig_a \	Pk_a\	Pk_a_hash | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | OP_HASH160 的做用是计算出最顶层 stack 的 hash |
	Sig_a \	Pk_a\	Pk_a_hash |pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | 将 pubKeyHash 推入堆顶 |

	Sig_a \	Pk_a	OP_CHECKSIG	OP_EQUALVERIFY 是检查栈顶的两个值是否相同
	true	空	OP_CHECKSIG 做用是检查栈顶的签名是否正确，正确则返回 true

交易数据的广播

在原始交易组装完成后，讲交易进行广播出去。非严格意义上讲，消息广播出去分为两种形式：直接调用 API，自身加入 P2P 节点。

交易数据打包确认

交易数据的打包和确认非正式术语称为“挖矿”，进行挖矿以前，首先要将交易合并在区块中， 区块对于交易的数据打包采用的 Merkle tree 算法。将多个交易的 hash 合并到树中，而后将Tree 的树根合并到块中。

须要说明的是在区块中不只仅含有 Merkle root ，还有其余的辅助信息如图 4 所示。共识机制做用于此部分，共识算法旨在将上面的 Merkle Root 所在的区块衔接在上一个区块中，不一样的区块链产品所采用的共识算法不一样，咱们将在下面的章节中选取典型的算法进行分析。

纵向分析总结

宏观上讲，共识算法做用于图 4 中的打包确认阶段，共识算法负责将交易数据打包到新的区块中，同时负责将该区块衔接到以前的链上。微观上从服务节点的角度上讲，共识算法包括 4 个阶段，以下图 5 所示，分发阶段，验证阶段，挖矿阶段，宣布阶段。矿机在分发阶段进行对交易进行收集，验证阶段开始验证交易的正确性，通过验证的交易在挖矿阶段进行确认，而后在T5 阶段进行下一轮的共识。

横向对比分析

在本章中咱们选取了的业界经常使用的共识算法进行分析，这些共识算法包括工做量证实POW, 权益证实 POS, 受权股权证实 DPOS, 瑞波共识算法 RC 和用于 Hyperledger 的拜占庭算法 PBFT。在工做量证实 POW 中咱们会以 Bitcoin 和 Ethereum 中不一样的 POW 作阐述；权益证实 POS 主要以点点币为表明进行分析；受权股权证实 DPOS 分别以Bitshares 和 Casper 算法进行讲解；瑞波共识算法 RC 和 拜占庭算法 PBFT 的分析依附于瑞波加密货币和 Hyperledger。同时在本章节的最后咱们会从网络组织，算法的效率和货币的发行机制等多个方面进行横向分析。

工做量证实 POW

工做量证实 POW（Proof-of-work）最先由 Markus Jakobsson 在反垃圾邮件系统实现中提出[6]。反垃圾邮件系统可以使垃圾邮件发送者须要更多的时间来发送邮件，就能够增 大他们的成本， 起到抵挡攻击的做用。2008 年被中本聪在论文《a peer to peer electronic cash system》[1] 中再次说起并使用，其设计理念是整个系统中每一个节点为整个 系统提供计算能力(简称算力)，经过一个竞争机制，让计算工做完成最出色的节点得到系统的奖励， 完成新生成货币的分配。

目前采用 POW 的算法表明有 Bitcoin 和 Ethereum（早期版本），他们虽然同时都成为POW，并都采用全节点竞争的方式对交易进行确认，但算法本质却大相径庭。咱们下面将对两个系统不一样的 POW 算法进行分析。

Bitcoin的POW 算法分析

下面咱们采用一个例子来描述在比特币中挖矿的过程。 上面的区块产生的过程章节中已经对下面的参数进行了交代，黄色的部分是块头，他将随着交易一块儿被被打包到区块链，第一个交易称为 coinbase ， coinbase 是用来奖励矿工的，它的具体的工做原理是coinbase收敛“正常交易”中的交易费组成一个新的交易，而后交易指向矿工的地址“正常交易”只指用来转移比特币用的交易。

图 6. 比特币区块结构图

Bitcoin 的 POW 核心机制是找 hash 碰撞, 从上面的分析咱们知道，区块链是一个持续增加的顺序块组成的，区块链是密码上的安全，对于每一轮只要找到相应的 hash 的碰撞就算成功， hash 碰撞的意思能够理解为 hash 值的前多少位相同，咱们知道何难找到两个 hash 如出一辙的文件，但咱们能够找到前几位相同的，咱们将一个完整的挖矿过程整理以下：

f(Di)>SHA256(SHA256(Hi−1||Ti||TXi||di||Ni)))

Hi−1 表示上一个区块的 HASH，Ti 表示时间戳，di 表示本轮的难度，Ni 表示须要找出的随机数。咱们从下图 7（比特币的官网上截取）能够清晰的看出上一个区块和下一个区块之间的关系。直观上讲，下一个区块比上一个区块前面多个一个 0，就是前 N 位对撞成功。

Ethereum 的 Pow 算法分析

以太坊 Etherum 目前采用的是 Ethash 算法，最初设计的目标是“GPU 友好，阻断 ASIC”鼓励一个机器一票，抵制大型的集成电路挖矿，Ethash 是基于一个固定的只读数据集的随机路径，受启发与内存限制的工做证实谜题和相关的学术著做。Ethash 所使用的定制随机功能是非标准的，难以进行密码分析，但它们能够进行简单的统计测试。算法的主题思路是从缓存获得固定数据集容易，反之十分困难，完整的算法描述以下：

固定数据集合代码 :

缓存集合代码 :

权益证实机制 POS

POS (Proof of Stake) 即权益证实机制，最先出如今点点币的白皮书中 [7]，其核心思想是将货币持有人的数目和持有的时间累计做为被选为共识节点的资本。

协议描述

这种新型区块里 POS 是一种特殊的交易称利息币(coinstake)（依据 BTC 当中的一类特殊交易：币基 coinbase 而命名，如上图 6 中所说起）。在利息币(coinstake) 交易中，区块持有人能够消耗币龄得到利息，同时得到为网络产生一个区块和用 POS 造币的优先权。利息币的第一个输入被称为核心（Kernel），并须要符合某一 Hash 目标协议。由此 POS 区块的产生具备随机性，这一过程与 POW 类似。但有一个重要的区别在 POS 随机散列运算是在一个有限制的空间里完成的（具体来讲为 1 hash / 未消费钱包的输出*秒），而不是像 POW 那样在无限制的空间里寻找，所以无需大量的能源消耗。

权益核心(kernel)所要符合的随机散列目标是以在核心中消耗币龄的目标值（币* 天 coin-day） 这与 BTC 的 POW 是不一样的，BTC 的每一个节点都是相同的目标值。 所以核心消耗的币龄越多， 就越容易符合目标协议。

点点币源码地址：https://github.com/peercoin/peercoin/blob/master/src/kernel.cpp

受权股权证实机制 DPOS

受权股权证实机制 (Delegated Proof of Stake) 是一种新的共识算法，有程序员 Daniel Larimer 提出 [8]，旨在优化 POW 和 POS 中的问题，这些问题集中在共识效率和严重集中化上。DPOS 使用技术民主用来抵消集中化的负面影响。

解决集中化的问题：

受权股权证实机制经过使用证人（称为表明）减轻集权化的潜在负面影响。总共 N 名证人签署了这些区块，并由分散在 P2P 网络的节点进行投票，并进行了每一笔交易。经过使用分散的投票程序，DPOS 的设计比同类系统更加民主。每一个被签名的区块在被接收信任节点签名以前都要被检验。

解决共识效率的问题：

DPOS 消除了在肯定事务以前必须等待必定数量的不可信节点进行验证的过程。这减小了对确认的需求，提升了交易速度。经过网络决定，经过有意向最可信赖的潜在的块签名者进行信任， 不须要施加人为的负担来减缓块签名过程。 DPOS 容许将多个事务包含在块中，而不是工做证实或证据证实系统。DPOS 系统中的每一个客户端都有能力决定谁是信任的，而不是将信任集中在资源最多的人手中。在受权的证据证实系统集权仍然发生，但它是受控制的。与其余保护密码安全网络的方法不一样，

DPOS 系统中的每一个客户端都有能力决定谁是信任的，而不是将信任集中在资源最多的人手中。DPOS 容许网络得到集中化的一些主要优势，同时仍然保持一些计算的权力下放衡量标准。这个制度是经过公正的选举程序执行的，任何人均可能成为大多数用户的表明。下面咱们选取了BitShares 和 Ethereum 的 DOPS 算法进行简要分析。

BitShares 算法分析

BitShares 是第一个提出并采用 DPOS 的分布式帐本 [8]。按照它的设计原则分类账本必须按照正确的顺序进行验证和确认。以保证数据库的的一致性和广泛确认。

协议描述

在现实生活中见证人发挥着中立担保的做用。例如一份重要的合同签证每每须要公共仲裁机构的担保。在 BitShares 系统中，见证人担任着相同的角色，因为它能够验证签名和交易中的时间戳信息。

在 BitShares 系统设计中，利益相关者能够选举必定数量的见证人来生成区块。每一个帐户容许对每一个见证人投一票，这个投票的过程被称为“批准投票”。选择出来的 N 个见证人被认为是对至少 50％的投票利益相关者的表明。每次见证人产生一个区块，见证人将获得必定的奖励，若是见证人由于违规没有生成区块，将不能到奖励，而且会被加入“黑名单”，再次获取 见证人的机会将会大大下降。

每组见证人的活跃状态在每个周期将会被更新，这个周期的一般设置为 1 天，随后这组见证人将会被解散。每一个见证人给一个 2 秒的流起色会用来区块，当全部的见证人被流转完成，改组见证人也会被解散，若是一个见证人在它的时间周期内没有产生区块，他的时间机会将会被错过，下一个见证人将产生下一个区块。任何节点均可以经过观察证人参与率来监控网络健康情况。历史上 BitShares 曾经维持了 99％的见证参与。

表明们以相似证人的方式当选。表明成为特权账户的共同签署者，该账户有权提出对网络参数 的更改。这个账户被称为起源账户。这些参数包括从交易费用到块大小，见证支付和块间隔的 一切。在大多数表明批准了一项拟议的变动后，利益相关者将得到 2 周的审查期间，在此期间， 他们能够对表明进行投票，并根据建议变动或者取消。选择这种设计是为了确保表明在技术上 不具备直接的权力，全部对网络参数的更改最终都获得利益相关者的批准。这样作是为了保护 表明免受可能适用于加密货币的管理者或管理员的规定。在 DPOS 下，咱们能够真正地说， 行政权力由用户掌握，而不是表明或证人。

Casper 算法分析

Casper 是近期 Ethereum 改进型方案。下面咱们简单的描述下 Casper 算法。

咱们给出如下定义, b（block）表示每一个块，c (checkpoint)表示检查点,其中b和c的关系能够表示成下图：

C0 被定义为起始指针，一个“纪元”被定义为两个检查点之间的连续的块序列，这个块序列包括后面的检查点，而不是较早的检查点。块的“纪元“是包含该散列的历元的索引，例如， 区块 599 的纪元为 5。

每一个表明都须要提交必定的准备金，和现实的世界同样，这份准备金直接关系到未来的奖励和违规罚金。系统中所说起的 2/3 的验证者，实际并非 2/3 的节点，而是指拥有 2/3 保证金的节点。表明能够广播两种类型的消息，第一种为“准备消息”显示格式为 <prepare, h, e, h, e, S> ， 其中的含义以下图所示。

“准备消息” 的内容描述 :

	符号	描述
	h	检查点的 hash |
	e	检查点的纪元 |
	h*	最近调整的 hash |
	e*	h* 的纪元 |
	S	每一个表明的签名 |

另外一种为“提交消息” 显示格式为 <commit, h, e, S> , 下表“提交消息”的含义描述

	符号	描述
	h	检查点的 hash |
	e	检查点的纪元 |
	S	每一个表明的签名 |

协议描述

一个检查点 h 知足如下条件是被认为是“调整过的”，这个阶段能够认为是选举的阶段。

• 2/3 的准备金持有表明已经发出 <prepare, h, e, h, e, S>消息

• h 自身被调整

一个检查点 h 知足如下条件是被认为是“被确认成功的”。这个阶段能够认为是共识阶段。

• h 被调整

• 2/3 的准备金持有表明已经发出<commit, h, e, S>消息

须要指出的是调整 h 时候有超过 2/3 表明的消息中必须含有相同的 h*. 同时起始指针 C0 默认为是已经调整和已经确认过的。

协议规定

Casper 的创新点在于不可能两个冲突的检查点同时被确认，除非有超过 1/3 的人违反了规定， 规定的内容以下：

• 表明不得在同一纪元发布两个或多个不一致的准备消息。换句话说，一个表明在一个纪元只能发布一个准备消息。

• 表明不能在同一个纪元发布确认消息早于准备消息。言外之意，确认消息必定晚于准备消息。

若是表明违反了上面的协议，准备金将所有被没收，用来奖励发现它违规的见证人。咱们给出一个理想的例子，在纪元 n 期间,全部的表明准备好 Cn h* = Cn-1 同时提交了 Cn。

瑞波共识机制 RCA

RCA 即瑞波公式算法（ripple consensus algorithm），在分布式支付系统老是会出现因为网络中全部节点同步通讯的要求致使节点遭受高延迟的问题 [9] 。瑞波共识算法经过在较大的网络中利用集体可信的子网来解决这些问题。下面咱们将详细的解读瑞波共识算法.

参数定义

服务节点（Server）： 服务节点能够是 P2P 网络中的任意一个，用来参与共识算法。帐本

（Ledger）：用来记录交易记录的数据库。帐本有服务节点在完成共识以后进行维护。最后 一个关闭的帐本（Last-Closed Ledger）：通过公式算法写入的帐本，最近写入的帐本，表明了网络中帐本的最新状态。活动帐本（Open Ledger）：每一个节点上会维护一个活动帐本， 共识的过程就是将活动帐本变为最后一个关闭的帐本的过程。独特节点列表（Unique Node

List）：每一个服务节点都会维护这一组服务节点列表，服务列表中的服务节点是被认为是未来有能力进行选举算法的， 咱们能够认为这些服务节点组成的网络是可信网络。提案人

（Proposer）：任何服务器均可以广播交易，在一次交易循环开始的时候，每一个服务器都尝

试着确认有效的交易，可是在这个确认过程当中，只有服务上的独特节点列表的服务器确认的才有效。

协议描述

第一步：全部的服务节点采集有效的交易，并将这些交易打包成一个“候选交易集合”。

第二步：每一个服务节点上的 UNL 合并“候选交易集合”，并验证“候选交易集合”的真实性。

第三步：候选交易集合中的集合只有在收集到 UNL 足够的认同后才能被选中，若是没有得到足够的认同，将被丢弃或者做为新一轮的候选交易。

第四步： 一个交易须要 80%的服务节点上的 UNL 赞成，全部知足要求的交易才容许挂载到链上。一旦挂载成功，当前的链自动关闭。

详细过程

以下图所示：每一个区块中都包含了帐本序号，帐户信息，交易信息，时间戳等信息。整个帐本每隔几秒会生成一个新的帐本，一个新的帐本用帐本序号进行标识。假如当前的帐本的序号为

N，则前一个帐本的序号为 N-1，下一个帐本的 N+1。

瑞波网络由接受和处理事务的分布式服务器（称为节点）和客户端应用程序组成。客户端应用程序向节点进行签名和发送交易，客户端应用程序包括钱包和金融机构的电子交易平台。

接收，中继和处理事务的节点能够是跟踪节点或验证节点。跟踪节点的主要功能包括分发来自客户端的事务和响应关于帐本的查询。验证节点执行与跟踪节点相同的功能，并另外有助于推动帐本序列。在接受客户应用程序提交的交易时，每一个跟踪节点使用最后一个验证的帐本做为起点。

网络上的节点共享关于候选交易的信息。经过协商一致的过程，验证节点就下一个帐本考虑的候选交易的特定子集达成一致。共识是一个迭代过程，其中节点转发提案或一组候选事务。节点沟通和更新建议，直到超过多个对等节点（80%以上，可调整）赞成一组候选交易。这个 过程决定了哪些交易被接受，哪些交易被抛弃或者被载入到下一轮提案中。在交易选择过程当中付出交易费用更多的节点更容易被接受。

当一组交易完成的时候，交易蔓延到不一样的节点并进行签名，当收集到足够多的节点的时候， 当前的备选交易将被打包到区块链中。若是网络节点在交易繁忙或者交易共识将很难被达成， 此时算法能够自主调节交易费用和等待时间。

总结

咱们将一个完整的交易周期总计以下：

	步骤	描述
	1. 一个交易被建立而且被签名	|
	2. 交易信息被提交到网络中	错误的格式的交易，将直接被拒绝 正确格式的数据暂时会被拒绝，可能下一轮 会被确认。 |
	3. 通过共识算法，交易将被打包到帐本中	验证成功的交易被加入到帐本中。 |

瑞波共识算法面临中心化的问题，使一组节点可以基于特殊节点列表达成共识。初始特殊节点列表就像一个俱乐部，要接纳一个新成员，必须由 51%的该俱乐部会员投票经过。共识遵循这核心成员的 51%权力，外部人员则没有影响力。因为该俱乐部由“中心化”开始，它将一直是“中心化的”，而若是它开始腐化，股东们什么也作不了。与比特币及点点币同样，瑞波 系统将股东们与其投票权隔开，并所以比其余系统更中心化。

拜占庭共识机制 PBFT

PBFT（Practical Byzantine Fault Tolerance），意为实用拜占庭容错算法，是目前最经常使用的 BFT 算法之一。该算法是 Miguel Castro (卡斯特罗)和 Barbara Liskov（利斯科夫）在

1999 年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级下降到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。下面咱们来分析这个算法。

参数定义

• client：客户端，发出调用请求的实体

• view：视图，内容为连续的编号

• replica：网络节点

• primary：主节点，负责生成消息序列号

• backup：支撑节点，辅助总体共识过程

• state：节点状态

协议描述

PBFT 算法要求整个系统流程要在同一个视图（view）下完成，全部节点采起一致的行动。一个客户端会发送请求<REQUEST, o ,t, c>给 replicas。其中，o 表示具体的操做，t 表示

timestamp，给每个请求加上时间戳，这样后来的请求会有高于前面的时间戳。Replicas

接收到请求后，若是验证经过，它就会将其写入本身的 log 中。在此请求执行完成后，

replicas 会返回 client 一个回复 <REPLY,v,t,c,i,r>，其中：v 是当前的 view 序号，t 就是对应请求的时间戳，i 是replica 节点的编号，r 是执行结果。每个replica 会与每个处于active 状态的 client 共享一份秘钥。秘钥所占据空间较少，加上会限制 active client 的数量，因此没必要担忧之后出现的扩展性问题。

PBFT 采用三阶段协议来广播请求给 replicas ： pre-prepare, prepare, commit 。pre-prepare 阶段和 prepare 阶段用来把在同一个 view 里发送的请求排序，而后让各个 replicas节点都承认这个序列，照序执行。prepare 阶段和 commit 阶段用来确保那些已经达到commit 状态的请求即便在发生视图改变（view change， 以后会提到）后，在新的 view 里依然保持原有的序列不变，好比一开始在 view 0 中，共有 req 0， req 1， req2 三个请求依次进入了 commit 阶段，假设没有恶意节点，那么这四个 replicas 即将要依次执行者三条请求并返回给Client。但这时主节点问题致使 view change 的发生，view 0 变成 view 1，在新的 view 里，本来的 req 0，req1， req2 三条请求的序列将被保留。可是处于 pre-prepare 和 prepare 阶段的请求在 view change 发生后，在新的 view 里都将被遗弃。

pre-prepare 阶段

主节点收到来自 Client 的一条请求并分配了一个编号给这个请求，而后主节点会广播一条<<PRE-PREPARE,v,n,d>, m>信息给备份节点，这里 v 是视图编号，m 是客户端发送的请求消息，d 是请求消息 m 的摘要（digest）。该信息会送达到每个备份节点，收到信息的备份节点会进行一系列验证，验证经过后会 accept 这条 PRE-PREPARE 信息。验证内容主要为：

• 请求和预准备消息的签名正确，而且 d 与 m 的摘要一致。

• 当前视图编号是 v。

• 该备份节点从未在视图 v 中接受过序号为 n 可是摘要 d 不一样的消息 m。

• 预准备消息的序号 n 必须在水线（watermark）上下限 h 和 H 之间（水线存在的意义在于防止一个失效节点使用一个很大的序号消耗序号空间）。

当一个备份节点 accept 了这条 PRE-PREPARE 后，它就会进入下面的 prepare 阶段。

prepare 阶段

一个备份节点进入到本身的 prepare 阶段后，开始将一条信息<PREPARE,v,n,d,i>，广播给主节点和其它的备份节点，与此同时，该备份节点也会收到来自其它备份节点的 PREPARE 信息。该备份节点将验证消息的签名是否正确，视图编号是否一致，以及消息序号是否知足水线限制， 而后综合验证信息作出本身对编号 n 的最终裁决。若是验证经过，则把这个准备消息写入消息日志中。当一个备份节点收到来自至少 2/3 个节点的准备消息，而且验证请求消息一致时，那么咱们就说该请求在这个节点上的状态是 prepared， 同时该节点也拥有了一个证书叫prepared certificate 。

commit 阶段

紧接着 prepare 阶段，当一个 replica 节点发现有一个 quorum 赞成编号分配时，它就会广播一条 COMMIT 信息给其它全部节点告诉他们它有一个 prepared certificate 了。与此同时它也会陆续收到来自其它节点的 COMMIT 信息，若是它收到了至少 2/3 条 COMMIT 后，咱们就说该节点拥有了一个叫 committed certificate 的证书， 请求在这个节点上达到了committed 状态。此时只经过这一个节点， 咱们就能判定该请求已经在一个有效团体（quorum）中到达了 prepared 状态，即一个有效团体的节点们都赞成了编号 n 的分配。当请求 m 在一个节点中到达 commited 状态后，该请求就会被该节点执行。

横向分析小节

本章将从三个角度进行总结：货币控制权，货币发行机制，以上说起算法的综合对比。

控制权的争夺

比特币的设计之初，系统默认节点和算力是均匀分布的，由于经过 CPU 来进行投票，拥有钱包(节点)数和算力值应该是大体匹配的，每个比特币钱包的拥有者都可以参与整个系统的决策机制， 若是有任何人试图对系统做恶，或者某一部分节点收到损失，均可以让其余节点迅速补上，而且只要有 51%的节点(算力)投票就能够选择对系统发展更有利的方向。

在实际操做中 POW 的主要问题是算力过于集中的安全风险，这种风险体如今比特币的控制权上， 挖矿的人和持有比特币的人已经彻底被隔开，许多矿工可能彻底不了解比特币的生态，甚至不关心比特币的将来，却拥有对比特币的绝对控制权，由于他们是新币产生的起始点。一种极端的想法，若是几个大型的矿池联合在一块儿，那么最新发行的币将囤积，会形成原有币种的进一步通货紧缩。简而言之，比特币的命运掌握在并不必定关心比特币命运的人手上，而持有比特币的人并无控制权。

这就有点像，一个公司的命运并非那些持有公司股份的股东来决定的，而是那些有可能根本不拥有股份，而只要有钱的人来决定的。那些持有比特币的人彻底没法对比特币的将来作出本身的决定。咱们仿佛从中本聪设定的一 CPU 一票的文明世界，一会儿沦为纯粹是靠蛮力，看谁力气更大的原始社会。

DPOS 机制彷佛又从新把权利归还到那些持有数字货币的人手上。DPOS 机制是让每个持有 BTS 的人对整个系统资源当表明的人进行投票，而得到最多票数的 101 个表明进行交易打包计算。这个能够理解为 101 个矿池，而这 101 个矿池彼此的权利是彻底相等的。那些握着 BTS 选票的人能够随时经过投票更换这些表明(矿池)，只要他们提供的算力不稳定，计算机宕机、或者试图利用手中的权力做恶，他们将会马上被愤怒的选民踢出整个系统，然后备表明能够随时顶上去。

货币发行机制

整体而言，目前的共识算法所对应的货币发行机制有 3 种：以比特币为表明的经过挖矿产生新货币，以点点币为例子的经过持有者的利息产生新货币和以瑞波币的恒量发行。

POW 的新增机制是“挖矿”，即矿工每完成必定量的计算，有可能得到一块新 block 中的新增比特币。这个过程是一个纯粹的通胀过程，即无中生有新增比特币。但得到新增的比特币有必定的要求，必须全球第一个找出特定的 HASH 值。所以发行机制是算力比例分配的。

POS 和 DPOS 的新增机制是“利息”，即持有必定的 POS 币必定时间，将得到必定量的固定“利息”。这部分“利息”是新增的币。只要你持有 POS 币并开机，你就能得到必定比例的“利息”。所以 POS 体系将新增 POS 币投放社会的机制，其投向是以已有 POS 币等比例增长的。

RCA 所对应的瑞波币为恒量发行，再也不增发，总发行量1000 亿个，瑞波币计划最终向外发行75% 的 Ripple 货币供应，并承诺永不增发。用户在进行每次交易时要花费必定的 Ripple 币（金额很是很是低，大约是 1/1000 美分），这个交易费不交给任何人，只是凭空消失。所以 Ripple 币只会愈来愈少，但减小的速度很是慢。瑞波币是一个不断通货紧缩的过程。

共识算法对比

		POW	POS	DPOS	RCA	PBFT
	一致性	最终一致性	最终一致性	最终一致性	最终一致性	强一致性 |
	容许失败的 节点数目	<=25%	根据不一样的算 法而定	<=33%	<=20%	<=33% |
	网络扩展性	高	高	高	高	低 |
	区块链类型	无权限	无权限	无权限	无权限	有权限 |
	交易速度	慢	快	快	极快	慢 |

结论

区块链的共识算法是加密货币的核心，良好的区块链算法能够安全高效的解决分布式加密货币系统中的“双花”和交易数据一致性的问题，本文从纵向定位分析和横向分析对比分析多角度研究了不一样加密货币系统中共识算法，旨在为区块链项目设计本身的共识算法提供理论参考和设计依据。

引用

[1]. S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Oct. 2008

[2]. “Blockchain.” Wikipedia. October 15, 2017. Accessed October 17, 2017. https://en.wikipedia.org/wiki/Blockchain.

[3]. RuJia . “【区块链技术系列】 区块链共识机制总结(上).” Ehcoo. October 09, 2017. Accessed October 17, 2017. http://www.ehcoo.com/blockchain_confirmation_mechanism.html.

[4]. Towards Robust Distributed Systems, Eric Brewer, 2000

[5]. Anon, (2017). [online] Available at: https://kknews.cc/finance/5m4ye5k.html [Accessed 17 Oct. 2017].

[6]. Jakobsson, Markus, and Ari Juels. “Proofs of Work and Bread Pudding Protocols(Extended Abstract).” Secure Information Networks, 1999, 258-72. doi:10.1007/978-0-387-35568-9_18.

[7]. Sunny King, Scott Nadal . PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. August 19th, 2012

[8]. “Delegated Proof of Stake.” Graphene Documentation. Accessed October 17, 2017. http://docs.bitshares.org/bitshares/dpos.html.

[9]. David Schwartz, Noah Youngs, Arthur Britto. The Ripple Protocol Consensus Algorithm.2014

[10]. “The XRP Ledger Consensus Process.” Ripple. Accessed October 17, 2017. https://ripple.com/build/xrp-ledger-consensus-process/#the-xrp-ledger-protocol-consensus-and-validation.

[11]. 梧桐树. “共识算法 区块链实用手册.” 区块链实用手册. Accessed October 17, 2017. http://wutongtree.github.io/hyperledger/consensus.

感谢HPB团队整理。

 

关于我

蓝莲花（汪晓明），微信/QQ：263305605，公众号：xm123798。朝夕网络(zhaoxi.co)创始人。致力于推进区块链应用落地。