一、為什么是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