這一篇我們來下說PBFT共識：
PBFT基本流程
算法的核心三個階段分別是pre-prepare階段（預準備階段），prepare階段（準備階段），commit階段（提交階段）。圖中的C代表客戶端，0，1，2，3代表節點的編號，打叉的3代表可能是故障節點或者是問題節點，這裏表現的行爲就是對其它節點的請求無響應。0是主節點。整個過程大致是：
首先，客戶端向主節點發起請求，主節點0收到客戶端請求，會向其它節點發送pre-prepare消息，其它節點就收到了pre-prepare消息，就開始了這個核心三階段共識過程了。
Pre-prepare階段：節點收到pre-prepare消息後，會有兩種選擇，一種是接受，一種是不接受。什麼時候纔不接受主節點發來的pre-prepare消息呢？消息過期，消息超前
Prepare階段：節點同意請求後會向其它節點發送prepare消息。這裏要注意一點，同一時刻不是隻有一個節點在進行這個過程，可能有n個節點也在進行這個過程。因此節點是有可能收到其它節點發送的prepare消息的。在一定時間範圍內，如果收到超過2/3個不同節點的prepare消息，就代表prepare階段已經完成。
Commit階段：於是進入commit階段。向其它節點廣播commit消息，同理，這個過程可能是有n個節點也在進行的。因此可能會收到其它節點發過來的commit消息，當收到2/3個commit消息後（包括自己），代表大多數節點已經進入commit階段，這一階段已經達成共識，於是節點就會執行請求，寫入數據。
兩種命令發出方案:
cosmos —> leader出塊
泰嶽鏈—> 羣發塊
泰嶽鏈 pbft 和鏈的交互
- pbft 委員會會產生一名leader, leader 節點負責pbft的消息的準備和發出
- leader 節點會通過 FetchFastBlock通過中間層pbft_agent 去鏈上產生一個fastblock ，獲取到塊後會打包 fastBlock 到Proposal（preprepare) 消息並分發給每一個委員會成員節點。（期間委員會節點會分發消息)
- 所有委員會節點會收到並驗證Proposal消息中的塊，收到並驗證成功後進入prevote(prepare)
消息中的塊，收到並驗證成功後進入prevote(prepare) - prevote ,Precommit(commit) 這兩個階段會把自己對於塊的驗證結果（VerifyFastBlock)同意或反對發送給所有收到並統計收到節點票數，當超過2/3的節點數