最开始在区块链领域引进pbft的是fabric0.6，pbft是使用拜占庭容错算法，通过多轮次的交互保证各节点执行一致性。下面分析初链的pbft实现。
pbft经典流程：
pbft的特点是流水线作业可以实现异步的拜占庭容错共识，而且需明确共识节点数量及身份标识。分析初链pbft共识的思路如下：
1）网络报文消息类型
2）共识流程是否满足上图所示三个步骤
3）当节点出现SPoF时，系统可否正常工作
4）是否支持异步拜占庭
5）是否考虑DPoS攻击
1消息类型
提案消息：Request Msg ，客户端将交易消息提交至区块链节点
预准备消息：PrePrepare Msg， 将交易信息进行打包封装后生成预准备消息。
投票消息：VoteMsg ，包括Prepare与Commit流程。
2提案消息处理流程
1）节点接受到交易请求，数据结构包括：客户端编号、交易序列号、时间戳等参数。
2）将交易请求打包生成PrePrepare信息，进行交易广播，但发现问题在交易广播前需进行身份绑定，程序中没有发现类似签名机制来保证系统安全。
3 预准备消息处理流程
1）节点接受到预准备消息后，存储到对应的state槽中。每个预准备消息之间没有关联性，这种设计方式优劣各半，可以提高系统共识的并发能力，但没有存储前块Hash。降低恶意攻击成本，攻击者只修改某块消息而不会对其他产生影响。
2）将预提交报文重新封装成Prepare报文进行广播至其他共识组成员。这里有的地方需要注意：假设区块链节点数为N =3f + 1, 容错个数为f。如果N != 3f + 1的时候就要注意容错个数的计算。
4 Prepare消息处理流程
1） 接受prepare消息，判定是否已经满足大于2/3.
2）接受到的prepare满足了2/3，节点封装commit消息进行广播。
5 Commit消息处理流程
1） 接受Commit消息，判定是否已经满足大于2/3.
2）接受到的Commit满足了2/3，进行reply处理。
至此，pbft的基本流程都已经完成。
评审意见：
1）
评审维度：安全性
评审意见：发送的preprepare没有看到签名表明自身身份。
2）
评审维度：安全性
评审意见：直接使用http通信需要考虑自己设计传输压缩，如果有需求切换tls也不是很快捷。
3）
评审维度：完备性
评审意见：输出到控制台不便于进行日志管理，也不具有分级输出能力、日志滚动。
4）
评审维度：可用性
代码截图：
评审意见：目前并行共识技术可以高效的处理交易请求，提高系统的交易吞吐量。
5）
评审维度：健壮性
代码截图：
评审意见：由于在公有链中选择节点进行pbft，可以增加一些惩罚措施，如果在pbft过程中，大量重复投票，或者投恶意票，可进行链上惩罚扣除token。
6）
评审维度：可用性
评审意见：使用secp256k1曲线目前是安全的，但ed25519签名算法的效率被椭圆曲线效率高出一个数量级，可以考虑将算法做成可插拔，更换高速签名算法。
7）
评审维度：可用性
代码截图：
评审意见：拜占庭容错节点计算方式N >= 3f + 1 f <= (N + 1)/3, 这里不一定是问题但是需要注意。
8）
评审维度：可读性
代码截图：
评审意见：代码命名规则统一，易懂易读，且英文注释较多。外部人员可以非常快速的上手初链。
