一、为什么是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).

1. 定义committed(m,v,n)为真当且仅当任意f+1个正常replica节点的prepared(m,v,n,i)为真。
2. 定义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．１９９９:１７３-１８６.

Practical Byzantine Fault Tolerance || 实用拜占庭容错三阶段消息流程理解

原文：https://www.cnblogs.com/naixil/p/13185602.html