在上次的PBFT的第一篇介紹裡，專員大概的講了一下在區塊鏈技術領域什麼著名的拜占庭將軍 ，其實不管是POW，POS以及DPOS都是可以解決這些拜占庭的問題，只是不同的算法在拜占庭的容錯率不一樣。並且不同的算法針對不同的性質的區塊鏈，比如說針對於非許可鏈，也就是我們常說的公鏈，POW、POW以及DPOS等等會更好，但是在許可鏈領域，也就是我們經常說的PBFT，RAFT或許更好，並且在許可鏈中還區分可信環境以及非可信環境，而非可信環境的核心就是解決我們昨天說的那個拜占庭將軍問題，今天我就聽過我的簡單的理解來說一下PBFT算法。
PBFT即(Practical Byzantine Fault Tolerance)，翻譯成中文為實用拜占庭容錯算法。此算法是在1999年由Miguel Castro (卡斯特羅)和Barbara Liskov（利斯科夫）提出來的，解決了原始拜占庭容錯算法效率不高的問題，將算法複雜度大大降低了，使得拜占庭容錯算法在實際系統應用中變得可行。針對PBFT算法，還有一篇比較專業的論文，並發表在1999年的操作系統設計與實現國際會議上（OSDI99）了，感興趣的小夥伴可以Google一下，去讀一下。
首先我們先來說一下，PBFT其實沒有類似於POW以及POS的激烈機制，更多的只是通過數字簽名等手段，通過複雜的類似於投票機制的手段來做到了交易順序一致性的共識。並且整個算法在保證活性以及安全性的前提下提供了(n-1)/3的容錯性，比如現在區塊鏈節點有4個，整個網絡允許作惡的節點就是1個節點，如果說在四個節點中有超過一個節點一同作惡，整個區塊鏈網絡便不再安全。
同時PBFT較其他拜占庭容錯的算法有以下一些較為顯著的優化，比如在只讀消息中，PBFT能夠做到只用一次消息往返，在只寫消息中只使用兩次的消息往返，同時在正常的操作中摒棄了效率低下的公鑰加密的算法，只在發生失效的情況下使用，正常的情況下只使用消息驗證編碼，也就是我們經常聽到的MAC(Message Authentication Code)值。
接下來我來大致講一下PBFT中最著名的三階段提交的邏輯，PBFT也正是利用了此種邏輯來進行了一致性的保證。首先要介紹幾個名詞:視圖(View)，副節點(Replica)以及主節點(Primary)。PBFT本身就是是一種狀態機副本複製的算法，即服務作為狀態機進行建模，狀態機在分佈式系統的不同節點進行副本複製。每個狀態機的副本都保存了服務的狀態，同時也實現了服務的操作。所有的副本在一個被稱為視圖（View）的輪換過程（succession of configuration）中運作。主節點由公式p = v mod |R|計算得到，這裡v是現在的視圖編號，p是副本編號，|R|是副本集合的個數，由此來進行主節點的選取。
說完主節點的選出，就來說三階段了，如下圖所示，當客戶端發送一個Request的請求的同時，整個共識要分為三個階段分別是：pre-preare、prepare以及最後的commit階段。
1）pre-prepare階段
主節點收到客戶端請求，主節點分配一個序列號n給收到的請求，然後向所有備份節點群發預準備(pre-prepare)消息。如果從節點都統一這個序列號，則進入了prepare節點。
2）prepare階段
如果備份節點接受了預準備(pre-prepare)消息，則進入準備階段。在準備階段的同時，該節點向所有節點發送準備(prepare)消息，包括主節點在內的所有副本節點在收到準備消息之後，對消息的簽名是否正確，view編號是否一致，以及消息序號是否正確這三個條件進行驗證， 驗證通過後將預準備消息和準備消息寫入自己的消息日誌。
3）commit階段
當prepare消息全部驗證通過後，則節點將發送commit消息，每個副本接受確認消息，需要驗證簽名正確，消息的視圖編號以及消息的序號。當驗證通過後，則該副本節點將確認消息寫入消息日誌中。
至此，PBFT的三階段結束了，PBFT主要通過pre-prepare以及prepare的兩個階段來確保了其他節點都已經收到足夠多的信息來達成共識了，保證了交易順序的一致性。
綜上，PBFT的出現在一定程度上也是現階段聯盟鏈領域較好的共識算法，也能保證區塊鏈的正常運行。我覺得，我們在關注公鏈的同時，其實也可以關注一下聯盟鏈的發展，在現階段國內的情形，聯盟鏈反而是比較好落地的一個場景。但是不得不說，聯盟鏈有的時候也有一定的問題，應用場景也有限，大多侷限在金融領域，但是對於技術的推進，或者場景的落地卻也是有益的。
歡迎感興趣的朋友在評論區與專員互動！！
閱讀更多 區塊鏈技術專員 的文章
