共识算法（二）—— DPoS（股份授权证明）、PBFT（实用拜占庭容错）

本文主要是介绍共识算法（二）—— DPoS（股份授权证明）、PBFT（实用拜占庭容错），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

DPoS简介

DPoS（Delegated-Proof-of-Stake）即股份授权证明，目的是解决PoS和PoW的不足，DPoS是由被社区选取的可信账户（受托人，得票数为所有委托人得前101位）来创建区块，为了成为正式委托人，用户要去社区拉票，获得足够多的用户信任，用户根据自己持有的加密货币数量占有总量的百分比来进行投票。它就像一个股份制公司，普通员工进不去董事会，但可以推选代表（受托人）代他们做决策。这前101位受托人可以理解为101个矿池，而这101个矿池彼此的权力是相等的，那些拥有加密货币的用户可以随时更换这些矿池。

代币

EOS

优点

能耗底
更加的去中心化
更快的确认速度。

缺点

投票的积极性不高
社区选举可能存在网络安全问题。

PBFT简介

PBFT(Practical Byzantine Fault Tolerance),即实用拜占庭容错算法，是解决拜占庭将军问题的一种方案。比起最开始的BFT算法，PBFT额外要求网络封闭，即节点数目确定并提前互通，但将复杂度从指数级降低到多项式级，使得BFT系列算法真正具有可行性。。PBFT算法的核心理论是 y>=3x+1，y是系统的总节点数，x是允许出现故障的节点数，换句话说如果整个系统拥有x个节点是出错了，那么，这个系统必须包含y个节点，才能解决故障。

PBFT4个阶段：

request：client请求阶段（有些说法不包括这个阶段）。总司令给军长下命令。

预准备（pre-prepare）：主节点向所有backup节点发送预准备消息，其中包括当前视图编号，client请求以及请求摘要，签名是否一致等。军长对各位师长说：现在是我的时代（视图），我是军长，你们都是师长，所有人都得听我的。现在公布总司令的命令（先说说总司令是谁，命令摘要）。

准备(prepare)：包括主节点在内的所有副本节点在收到准备消息之后，对消息的签名是否正确，视图编号是否一致，以及消息序号是否满足水线限制这三个条件进行验证，如果验证通过则把这个准备消息写入消息日志中。backup节点核对签名信息，比如其他师长听到总司令的名字，说对，总司令就是这个人没错，然后核对总司令曾经任命这家伙当军长，好吧，那就听他的吧。

确认(commit)：每个副本接受确认消息的条件是：1）签名正确；2）消息的视图编号与节点的当前视图编号一致；3）消息的序号n满足水线条件，在h和H之间。一旦确认消息的接受条件满足了，则该副本节点将确认消息写入消息日志中。每个师长都经过上述核对，确认无误，就会接受命令进行执行。
回复（reply）：结果反馈。