一、为什么是n>3f (n=3f+1) ?
n是总节点数，f是拜占庭节点数，拜占庭节点可能不发送消息可能发送错误消息。
如果要达成一致，在f个拜占庭节点都不发送消息的情况下，必须要收到n-f个消息才可进行共识，所以n-f是需要收到的消息最小应答数目。
节点如果收到n-f个消息想进行共识就需要这n-f个消息中的正确节点发送消息数大于拜占庭节点发送的消息。
n-f个消息中拜占庭节点最多有f个消息，所以正确消息数n-f-f，共识条件n-f-f>f,即n>3f, n_min=3f+1.
二、PBFT三阶段消息流程
三个阶段：pre-prepare, prepare, commit.
三种角色：client, Replicas(分为Primary和Backups).
三种状态：prepared(m,v,n,i), committed(m,v,n), committed-local(m,v,n,i)
上图其中C是Client,0是Primary,3是拜占庭节点，1、2正常Backup,0、1、2是Replicas.
简略流程：
1）Client发送请求（request）给Primary，采用点对点方式.
2）Primary将请求(request)发送给所有Backup,(采用组播方式)且所有收到请求的Replicas(包括Primary和Backup)将对请求的回复(reply to the request)发送给Client.
3）Client收到f+1个正确的回复(reply to the request)再接受.
详细过程：(Primary用p表示，request用m表示)
1）pre-prepare预准备阶段：
p发送预准备消息给backup节点，消息内容为<pre-prepare,v,n,d>,v是视图号，n是请求消息m的序列号，d是请求消息m的摘要.
2）prepare准备阶段：
- 如果backup i(i为节点编号)检验之后接受<pre-prepare,v,n,d>，则会采用组播方式发送<prepare,v,n,d，i>给所有的Replicas且写入自己的消息日志。（检验是指查看预准备/准备/确认消息的视图号v与replicas的当前视图号一致、数字签名正确、消息序号在水位界限H&h之间，下同）
- Replica接收到准备消息<prepare,v,n,d，i>并检验后会将其写入自己的消息日志。
- 准备阶段完成的标志：当且仅当replica i发现自己的消息日志中有2f个（加上自己的就是2f+1个）来自不同backup的prepare消息与pre-prepare消息相匹配（通过视图号v,消息序号n，消息摘要d来判断是否匹配），记该节点i的prepared(m,v,n,i)为真。
3）commit确认阶段：
定义两种状态：committed(m,v,n)和committed-local(m,v,n,i).
- 定义committed(m,v,n)为真当且仅当任意f+1个正常replica节点的prepared(m,v,n,i)为真。
- 定义committed-local(m,v,n,i)为真当且仅当该节点的prepared(m,v,n,i)为真且i已经接收到2f+1(包括自己)个经检验后正确的确认消息<commit,v,n,D(m)，i>.
两种状态的关系：committed-local(m,v,n,i)为真那么committed(m,v,n)为真。
当Replica i发现自己的prepared(m,v,n,i)状态为真的时候就组播自己的确认消息<commit,v,n,D(m)，i>给其他的Replica。收到消息的Replica在检验确认之后将收到的commit消息写入自己的消息日志。 当committed-local(m,v,n,i)为真（即i接收到2f+1(包括自己)个经检验后正确的确认消息<commit,v,n,D(m)，i>. ）的时候，replica节点就执行请求m，并将结果发给Client，Client收到f+1个回复之后接受。
以上就是PBFT进行共识的流程。
参考文献：CASTRO M．Practical byzantine fault tolerance[C]//OSDI．１９９９:１７３-１８６.
https://www.jianshu.com/p/fb5edf031afd
https://www.cnblogs.com/gexin/p/9256194.html