POW：Proof of Work，⼯作证明。
⽐特币在Block的⽣成过程中使⽤了POW机制，⼀个符合要求的Block Hash由N个前导零构成，零的个数取决于⽹络的难度值。要得到合理的Block Hash需要经过⼤量尝试计算，计算时间取决于机器的哈希运算速度。当某个节点提供出⼀个合理的Block Hash值，说明该节点确实经过了⼤量的尝试计算，当然，并不能得出计算次数的绝对值，因为寻找合理hash是⼀个概率事件。当节点拥有占全⽹n%的算⼒时，该节点即有n/100的概率找到Block Hash
POS：Proof of Stake，股权证明。
POS：也称股权证明，类似于财产储存在银⾏，这种模式会根据你持有数字货币的量和时间，分配给你相应的利息。 简单来说，就是⼀个根据你持有货币的量和时间，给你发利息的⼀个制度，在股权证明POS模式下，有⼀个名词叫币龄，每个币每天产⽣1币龄，⽐如你持有100个币，总共持有了30天，那么，此时你的币龄就为3000，这个时候，如果你发现了⼀个POS区块，你的币龄就会被清空为0。你每被清空365币龄，你将会从区块中获得0.05个币的利息(假定利息可理解为年利率5%)，那么在这个案例中，利息 = 3000 * 5% / 365 = 0.41个币，这下就很有意思了，持币有利息。
DPOS：Delegated Proof of Stake，委任权益证明
⽐特股的DPoS机制，中⽂名叫做股份授权证明机制（⼜称受托⼈机制），它的原理是让每⼀个持有⽐特股的⼈进⾏投票，由此产⽣101位代表,我们可以将其理解为101个超级节点或者矿池，⽽这101个超级节点彼此的权利是完全相等的。从某种⾓度来看，DPOS有点像是议会制度或⼈民代表⼤会制度。如果代表不能履⾏他们的职责（当轮到他们时，没能⽣成区块），他们会被除名，⽹络会选出新的超级节点来取代他们。DPOS的出现最主要还是因为矿机的产⽣，⼤量的算⼒在不了解也不关⼼⽐特币的⼈⾝上，类似演唱会的黄⽜，⼤量囤票⽽丝毫不关⼼演唱会的内容。
BFT : 拜占庭容错技术（Byzantine Fault Tolerance）
拜占庭容错技术（Byzantine Fault Tolerance，BFT）是⼀类分布式计算领域的容错技术。拜占庭假设是对现实世界的模型化，由于硬件错误、⽹络拥塞或中断以及遭到恶意攻击等原因，计算机和⽹络可能出现不可预料的⾏为。拜占庭容错技术被设计⽤来处理这些异常⾏为，并满⾜所要解决的问题的规范要求。
在分布式系统中，特别是在区块链⽹络环境中，也和拜占庭将军的环境类似，有运⾏正常的服务器（类似忠诚的拜占庭将军），有故障的服务器，还有破坏者的服务器（类似叛变的拜占庭将军）。共识算法的核⼼是在正常的节点间形成对⽹络状态的共识。通常，这些发⽣故障节点被称为拜占庭节点，⽽正常的节点即为⾮拜占庭节点。
拜占庭容错系统是⼀个拥有n台节点的系统，整个系统对于每⼀个请求，满⾜以下条件：
- 所有⾮拜占庭节点使⽤相同的输⼊信息，产⽣同样的结果；
- 如果输⼊的信息正确，那么所有⾮拜占庭节点必须接收这个信息，并计算相应的结果。
拜占庭系统普遍采⽤的假设条件包括：
- 拜占庭节点的⾏为可以是任意的，拜占庭节点之间可以共谋；
- 节点之间的错误是不相关的；
- 节点之间通过异步⽹络连接，⽹络中的消息可能丢失、乱序并延时到达，但⼤部分协议假设消息在有限的时间⾥能传达到⽬的地；
- 服务器之间传递的信息，第三⽅可以嗅探到，但是不能篡改、伪造信息的内容和验证信息的完整性。
原始的拜占庭容错系统由于需要展⽰其理论上的可⾏性⽽缺乏实⽤性。另外，还需要额外的时钟同步机制⽀持，算法的复杂度也是随节点增加⽽指数级增加。
PBFT：Practical Byzantine Fault Tolerance，实⽤拜占庭容错算法。
PBFT是⼀种状态机副本复制算法，即服务作为状态机进⾏建模，状态机在分布式系统的不同节点进⾏副本复制。每个状态机的副本都保存了服务的状态，同时也实现了服务的操作。将所有的副本组成的集合使⽤⼤写字母R表⽰，使⽤0到|R|-1的整数表⽰每⼀个副本。为了描述⽅便，假设|R|=3f+1，这⾥f是有可能失效的副本的最⼤个数。尽管可以存在多于3f+1个副本，但是额外的副本除了降低性能之外不能提⾼可靠性。
PBFT要求共同维护⼀个状态，所有节点采取的⾏动⼀致。为此，需要运⾏三类基本协议，包括⼀致性协议、检查点协议和视图更换协议。我们主要关注⽀持系统⽇常运⾏的⼀致性协议。⼀致性协议⾄少包含若⼲个阶段：请求（request）、序号分配（pre-prepare）和响应（reply）。根据协议设计的不同，可能包含相互交互（prepare），序号确认（commit）等阶段。
PBFT在很多场景都有应⽤，在区块链场景中，⼀般适合于对强⼀致性有要求的私有链和联盟链场景。例如，在IBM主导的区块链超级账本项⽬中，PBFT是⼀个可选的共识协议。在Hyperledger的Fabric项⽬中，共识模块被设计成可插拔的模块，⽀持像PBFT、Raft等共识算法。
RPCA：Ripple共识
2013年2⽉Vitalik Buterin曾详细介绍了瑞波币共识证明（Proof of Consensus），但RPCA真正应⽤到算法共识是在2014年。RPCA每隔⼏秒能应⽤到所⽤节点，这是⼗分⾼效的，可以以此来维护整个⽹络的有效性和⼀致性。在整个社区中，⼀旦达成共识，当前的账本将会保存记录在此之前的所有交易信息，然后关闭成为最后的账本。在这个关闭的账本中所有⽹络节点维护都是相同的。在瑞波币共识证明算法中，节点能够⼈为的⼲涉投票和维持trust not list。
Ripple（瑞波）是⼀种基于互联⽹的开源⽀付协议，可以实现去中⼼化的货币兑换、⽀付与清算功能。在Ripple的⽹络中，交易由客户端（应⽤）发起，经过追踪节点（trackingnode）或验证节点（validating node）把交易⼴播到整个⽹络中。追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外，还能够通过共识协议，在账本中增加新的账本实例数据。
Ripple的共识达成发⽣在验证节点之间，每个验证节点都预先配置了⼀份可信任节点名单，称为UNL（Unique Node List）。在名单上的节点可对交易达成进⾏投票。每隔⼏秒，Ripple⽹络将进⾏如下共识过程：
- 每个验证节点会不断收到从⽹络发送过来的交易，通过与本地账本数据验证后，不合法的交易直接丢弃，合法的交易将汇总成交易候选集（candidate set）。交易候选集⾥⾯还包括之前共识过程⽆法确认⽽遗留下来的交易。
- 每个验证节点把⾃⼰的交易候选集作为提案发送给其他验证节点。
- 验证节点在收到其他节点发来的提案后，如果不是来⾃UNL上的节点，则忽略该提案；如果是来⾃UNL上的节点，就会对⽐提案中的交易和本地的交易候选集，如果有相同的交易，该交易就获得⼀票。在⼀定时间内，当交易获得超过50%的票数时，则该交易进⼊下⼀轮。没有超过50%的交易，将留待下⼀次共识过程去确认。
- 验证节点把超过50%票数的交易作为提案发给其他节点，同时提⾼所需票数的阈值到60%，重复步骤3）、步骤4），直到阈值达到80%。
- 验证节点把经过80%UNL节点确认的交易正式写⼊本地的账本数据中，称为最后关闭账本（Last Closed Ledger），即账本最后（最新）的状态。
在Ripple的共识算法中，参与投票节点的⾝份是事先知道的，因此，算法的效率⽐PoW等匿名共识算法要⾼效，交易的确认时间只需⼏秒钟。当然，这点也决定了该共识算法只适合于权限链（Permissioned chain）的场景。Ripple共识算法的拜占庭容错（BFT）能⼒为（n-1）/5，即可以容忍整个⽹络中20%的节点出现拜占庭错误⽽不影响正确的共识。
RPCA的缺点就是易于遭受攻击，⿊客可以伪造node，甚⾄可以⼤量扩散潜伏，并在某个时间突然攻击所有⽹络。当然RPCA优势就是产⽣区块，Ripple 也不需要⼤量计算的。它的维护成本⾼，可以⼈⼯维护节点，但也有改动节点的风险。⾃然它可以采⽤⼿⼯⼲预，剔除⽹络中不安全节点。这样⽹络就分成两部分。牺牲了⾃动化的优势，保证可信的节点不被攻击。
dBFT：⼩蚁共识（delegated BFT），⼀种改进的拜占庭容错算法
⼩蚁采⽤的共识机制是在Castro 和 Liskov提出的“实⽤拜占庭容错算法”（Practical Byzantine Fault Tolerance）的基础上，经过改进后使其能够适⽤于 区块链系统。拜占庭容错技术被⼴泛应⽤在分布式系统中，⽐如分布式⽂件系统、分布式协作系统、云计算等。
⼩蚁主要做了以下改进：
- 将C/S架构的请求响应模式，改进为适合P2P⽹络的对等节点模式；
- 将静态的共识参与节点改进为可动态进⼊、退出的动态共识参与节点；
- 为共识参与节点的产⽣设计了⼀套基于持有权益⽐例的投票机制，通过投票决定共识参与节点（记账节点）；
- 在区块链中引⼊数字证书，解决了投票中对记账节点真实⾝份的认证问题；
以上主要是⽬前主流的共识算法。 但说起哪种共识机制更好或更具替代作⽤？ 我认为DPOS来单独替代POW，POS或者POW＋POS不太可能，毕竟存在即合理。每种算法都在特定的时间段、场景下具有各⾃的意义，⽆论是技术上，还是业务上。如果跳出技术者的⾓度，更多结合政治与经济的思考⽅式在⾥⾯，或许还会不断出现更多的共识机制。
对于算法的选择，⼀句话总结如下： “在区块链⽹络中，由于应⽤场景的不同，所设计的⽬标各异，不同的区块链系统采⽤了不同的共识算法。⼀般来说，在私有链和联盟链情况下，对⼀致性、正确性有很强的要求。⼀般来说要采⽤强⼀致性的共识算法。⽽在公有链情况下，对⼀致性和正确性通常没法做到百分之百，通常采⽤最终⼀致性（Eventual Consistency）的共识算法。”
通俗点就是：共识算法的选择与应⽤场景⾼度相关，可信环境使⽤paxos或者raft，带许可的联盟可使⽤pbft，⾮许可链可以是pow，pos，ripple共识等，根据对⼿⽅信任度分级，⾃由选择共识机制。
