Practical Byzantine Fault Tolerance
概述
当出现恶意节点的时候，需要一定的容错能力才能保证共识，PBFT 能容忍 (n-1)/3 个恶意节点。
恶意节点：由于网络原因或主机原因节点下线，无法正常回复消息，或者恶意回复错误的消息。
过程
总的会执行 三阶段 协议
-
预准备阶段：客户端请求，主节点 Primary 广播给其他节点 Secondary
-
准备阶段：分别各自广播消息给其他节点；其他人不能直接执行，因为他们都不能确定自己收到消息和别人的都一样，可能收到假消息
-
提交阶段：当收到 2f 个一致的准备消息后悔提交，将提交请求广播给别的节点
-
最后客户端只要收到：2f+1 个相应请求证明大部分的节点已经达成共识
image.png
上图中：XXXX 为恶意节点，模拟不回复消息的情况。
无需想的过于复杂，其本质还是抽屉原理，只是在每个节点上，都需要收到大多数的消息，才认为这个消息时真的而已。
最终可以看到，BCD 节点在 提交阶段都会收到对应的大多数正确消息；从而反馈给客户端 A 的时候 A 同时也需要验证是否为大多数，以保证容错。
要点
PBFT 中的质疑
其实对于 PBFT 中，第一次提出了质疑的操作，我不相信你来的一定是对的，我需要得到其他节点的确认，只有每个人都得到了大多数的确认，每个人才知道自己是对的，最终才能知道谁是对的。
请求顺序
request里面包含了时间戳，按照时间戳排序执行
消息广播次数多
消息被广播次数过多，你可以看到，其实每个消息都在被广播，而这样的广播对于每个收到消息的节点来说又要进行处理而下一阶段又要被广播。所以适用于小型的系统中。
总结
raft 协议虽然用的地方很多，但是建立在所有节点都被信任的基础之上，不能有节点恶意在广播错误信息。
而 pbft 一定程度上解决了这个问题，在小型的系统中能有一定的容错能力。
实际的 pbft 还有很多细节：
原始论文的地址 http://pmg.csail.mit.edu/papers/osdi99.pdf
论文翻译中文版 https://blog.csdn.net/DeveloperRen/article/details/82771710
网友评论