本次介绍Fabric中pbft在知乎上看到一个比较好的回答，部分搬运过来
如何通俗的理解IBM区块链技术HyperLedger/fabric中的共识算法PBFT(拜占庭容错)？
拜占庭问题
-
一般的分布式选举只需要保证一半以上的节点响应就可以得出一致意见（Raft和Paxos算法），但如果成员里面出现了“内奸”，问题就要复杂一点：将军A
告诉你“进攻”，告诉将军B“撤退”;将军B接到A的消息后又通知你“撤退”;这时,你怎么办?！
-
这就是拜占庭将军问题，以上例子可以看出来（其实需要很复杂的数学方法证明），当有n个内奸，而总成员数>3n+1时，这个问题才有解！就是说如果有
1个内奸，那就得4个节点一起投票才能把这个内奸找出来；2个内奸，就需要7个节点；以此类推。
PBFT图解
- C是客户端，0-3是分布式系统里的成员节点，其中0是主节点，其他为备份节点；3节点发生了故障，或者是“内奸”，发送的消息无效
Q&A
- Q:为什么需要一个主节点?
- A:客户端可能会同时发起多个请求，但pbft算法一次只能处理一个，所以要以请求到达主节点的顺序来处理。
Q&A
- Q:主节点挂了怎么办?
- A:每个备份节点和主节点之间有超时机制，当怀疑主节点有问题后，会群发消息要求换主节点，得到一致结果以后，进行主节点切换；为了避免主节点挂
了，不能接收到客户端请求，实际实现的时候，C的请求是群发给所有客户端的，当发生切换后请求会被继续处理。
Q&A
- Q:如何选举下一个主节点？
- A:每个加入分布式系统的节点都是有编号的，依次轮流做主节点。每更换一次主节点，叫做一次视图切换（view change），视图序号会被包含在
所有的通讯消息中，保证不同视图的消息不会混乱；
Q&A
- Q:主节点是“内奸”怎么解决
- A:场景1,主节点修改客户的请求发给了所有的备份节点？客户端发起请求时，会对请求做签名，当得到响应时会去验证过程中请求是否被篡改过。
- 场景2,主节点发给不同备份节点不同的请求？参照Q2解决。
- 场景3,主节点发给不同备份节点时，调整请求的顺序？prepare阶段结束时，每个节点会校验主节点和其他备节点的消息是否一致；
Q&A
- Q：为什么要有prepare阶段？
- A：参照Q7场景3