上一节我们讲到PBFT是在共识节点较少的情况下拜占庭问题的一种解决方案，适用于联盟链。这一节我们就继续讲讲，什么是PBFT（实用拜占庭容错）算法。

早期提出的能解决拜占庭问题的算法（包括随拜占庭问题论文提出来的两种原生算法），要么仅仅停留在展示算法的理论可能性阶段，而实用性不高，要么就假设算法的使用环境为同步系统，而真实生产中的信息系统往往是异步的，例如互联网。

所以，Miguel Castro和Barbara Liskov在1999年提出PBFT，旨在解决拜占庭算法效率不高的问题，同时它也是首个能应用在异步系统中的拜占庭算法。

PBFT算法采用了加密学算法保证恶意节点无法解密篡改诚实节点中的信息，经证明，算法的拜占庭容错率为1/3，即只要恶意节点的总数不超过总节点数的三分之一，就可以断定这个系统是可信的。

算法选择分布式网络中的一个节点为主节点（primary），剩下的节点则是主节点的备份节点（backups），当客户端向分布式系统发送请求后，它经历以下几个阶段，最终得到正确的结果响应。

1.  客户端向主节点（primary）发送请求命令。

2.  主节点（primary）得到命令后，将命令分发给它的备份节点（backups）。

3.  备份节点得到命令后，处理命令，再将处理结果直接回传给客户端。

4. 客户端统计处理结果，当某一结果的数量达到f+1时，将其作为最终结果。

（f为系统允许的恶意节点数量）

（C是客户端，0是主节点，1、2、3是备份节点）

如上图所示，在实现这些阶段的过程中，主节点与备份节点间，备份节点与其他节点之间，会进行多次通信验证。

通信验证有两个目的：

1.使最终的结果响应是可信且有效的。

2.为主节点作恶或掉线的情况提供保护机制，即备份节点间通过通信验证，检测主节点是否作恶或掉线，如果作恶或掉线，则由备份节点们共同发起一个协议，选出新的主节点，让系统继续运行下去。

这种通信验证带来的弊端是，随着节点的增多，系统性能会下降的很快，但是在较少节点的情况下可以有不错的性能，并且分叉的几率很低。这也就是为什么PBFT主要用于联盟链。但是如果能够结合类似DPOS的见证人选举制度的话，它也可以应用于公链，TPS应该是远大于POW的。

PBFT还采用了一些优化方案来提高算法的性能。

首先，正如上文提到，节点间的通信验证会影响系统性能，所以PBFT想了三种办法来降低通信消耗。这里介绍其中一种，它的思路是尽量避免备份节点向客户端传递数据量大的响应结果。客户端请求委派其中一个备份节点传递完整的响应结果，而剩下的备份节点仅仅传递响应结果的摘要（digest）。

客户端可以通过摘要验证响应结果是否与其他节点传来的响应结果一致，从而判断那份完整的响应结果是否正确。这一方式能减少了节点们传递给客户端的总数据传递量，从而减少对系统的网络带宽占用和CPU资源占用。

此外，PBFT还针对其所使用的加密算法做了优化。PBFT采用两种加密算法数字签名和MAC（信息验证码），其中数字签名算法可以向第三方证明信息的准确性，MAC不行。而这种性质正是拜占庭容错问题所需要的。然而，越牛逼的加密算法往往也意味着会消耗越多的系统资源，加解密过程也会越久。如果PBFT算法每个需要加密的地方都用更牛逼的数字签名，就会导致系统的性能差，延迟高。

因此，好钢用在刀刃上，PBFT只在最需要的时候用数字签名，即主节点作恶了（系统面临的最高风险），需要选择新主节点的时候，采用数字签名，其他时候就采用常规一些，但是没那么费资源的MAC。

以上就是对PBFT的一个粗略介绍。其实，相比POW，POS这种更加直观易懂，甚至可以用讲故事的办法进行科普的角色来说，PBFT属于区块链中比较难理解的一个概念了。

因为它涉及到很多计算机的基础知识。本文也是试图略过一些计算机术语和代码，来更浅显地介绍PBFT，不过还是有些硬核。当然，也欢迎对此感兴趣的计算机相关技术人士，直接阅读PBFT的论文来更加详细地理解它。如果要从代码角度看它是如何具体实现的，可以到Github上查看Hyperledger Fabric源码的Consensus部分。

内容主编：招木

排版：大米