PBFT 是 Practical Byzantine Fault Tolerance 的缩写，意为实用拜占庭容错算法。该算法首次将拜占庭容错算法巨大度从指数级低落到了多项式级，其可以在恶意节点不高于总数 1/3 的环境下同时担保安详性（Safety）和活性（Liveness）。我们假设所有节点的总数为 R ，拜占庭节点数量为 f，下面给出安详性证明：
设想 f 个哗变者和 k 个忠诚者，哗变者存心使坏，可以给堕落误的功效，也可以不响应。某个时候 F 个哗变者都不响应，则 k 个忠诚者取大都既能获得正确功效。当 f 个哗变者都给出一个恶意的提案，而且 k 个忠诚者中有 f 个离线时，剩下的 k - f 个忠诚者此时无法别离是否混入了哗变者，仍然要确保取大都能获得正确功效，因此，k - f > f，即 k > 2f 或 R - f > 2f，所以系统整体局限 R 要大于 3f。所觉得了能确保告竣共鸣的拜占庭系统节点数至少为 4，此时最多答允呈现 1 个拜占庭节点。
PBFT 是一种基于状态机副本复制的算法，每个状态机的副本都生存了处事的状态，同时也实现了处事的操纵。PBFT 中所有的副本都在视图（View）的轮换进程中运作，当主节点掉线的时候就启动视图改换进程担保算法的一连运行。
从上面的内容可以看出，PBFT 算法的流程如下：
1.客户端向主节点发送请求；
2.主节点向其他副本广播请求；
3.所有副本执行请求后，将功效返回给客户端；
4.客户端需要期待 2f+1 个差异副本返回沟通的功效，作为最终功效。
这内里暗含着的是所有节点都是确定性的和所有节点都从沟通的状态开始执行这两个条件。
首先客户端发送了一个请求到主节点，之后经典的三阶段协议（three-phase protocol）就拉开了序幕。
1.预筹备阶段
首先，主节点向所有副本节点发送预筹备动静。这内里包括有动静序号，，视图编号和动静的摘要。需要留意的是预筹备动静是不包括请求的，这样做有两个长处，一是压缩动静巨细晋升流传效率，二是将请求排序与请求传输解耦。
接着副本节点会去验证动静的签名是否正确，视图编号是否一致和动静序号是否满意水线要求。这里就要引出 PBFT 中的水线机制（watermark）。对付动静的序号 n，要求其在水线 h 和 H 之间。水线存在的意义在于防备一个失效节点利用一个很大的序号耗损序号空间。
2.筹备阶段
假如副本节点接管预筹备动静，就进入了筹备阶段。在筹备阶段，每一个节点都向其他节点发送包括本身 ID 的筹备动静，同时也吸收其他节点的筹备动静。对付收到筹备动静同样举办正当性查抄。验证通过则把这个筹备动静写入本身的动静日志中。一个节点集齐至少 2f+1 个验证过的动静才进入筹备状态。
3.提交阶段
在提交阶段，每个节点广播 commit 动静汇报其他节点本身已经进入筹备状态。假如集齐至少 2f+1 的 commit 动静则说明提案通过。
在颠末尾三阶段协议之后，每个副本节点都想客户端发送回覆，副本节点会把时间戳比已回覆时间戳更小的请求扬弃，以担保请求只会被执行一次。
总结
PBFT 共鸣算法在 1999 年的时候由 Castro 和 Liskov 正式提出，它在设计时思量的共鸣工具是一些相对不大的动静。为了对动静举办排序，PBFT 设计了水线机制，通过 checkpoint 机制移动水线，用以并发地处理惩罚多个动静的投票进程。同时， PBFT 只有当某个节点作恶或掉线才触发视图的切换，主节点的改换。这是因为视图的切换进程也是需要共鸣的，这一进程很是耗时，因此 PBFT 不能接管频繁的视图改观。再加上为了共同水位机制，视图切换的动静都相对普通动静要大得多。因为以上原因，PBFT 的设计很是巨大，效率不高。
然而，跟着技能的成长，区块链技能的降生轻松的化解掉了 PBFT 在设计上的一些问题。 在区块链中，每一个动静（区块）前后相继，用于并发处理惩罚的水位机制毫无用处，因此水线机制以及为此处事的 checkpoint 机制就没有存在的意义了。没有了水线机制和 checkpoint，阻碍视图切换的就只剩下视图切换的共鸣进程了，而这一点又被区块链自己作为共鸣账本的特点给简化掉了。假如节点的切换通过链上的数据来告竣共鸣，那么原本需要颠末在线共鸣的进程又省掉了。
因此大量的区块链项目都利用了改造的 PBFT 用作共鸣算法，作为拜占庭容错的代表的 PBFT 也在不绝地优化的进程中抖擞出了新的朝气。除了PBFT共鸣算法以外，不少优秀的区块链项目自行研发除了越发创新的共鸣算法，好比DPOW共鸣算法。此共鸣算法由UENC公链创始，极大地晋升了去中心化网络下的生意业务机能。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
