PBFT(Practical Byzantine Fault Tolerance)算法由Miguel Castro 和Barbara Liskov在1999年提出來的，解決了原始拜占庭容錯算法效率不高的問題，將算法復雜度由指數級降低到多項式級，使得拜占庭容錯算法在實際系統應用中變得可行。
PBFT是壹種狀態機副本復制算法，壹般包括三種協議:壹致性協議(agreement)、檢查點協議(checkpoint)和視圖更換協議(view change)。該算法要滿足以下兩個性質：
安全性(safety)：safety means nothing bad happens. 活性(liveness)：liveness means that something good eventually happens.
在壹個拜占庭系統裏面，要容忍f個拜占庭節點錯誤，則replica數量至少為3f+1，這是滿足安全性的前提。因為網絡延遲或宕機，系統存在f個節點不回復響應（f個節點包括拜占庭節點和非拜占庭節點，最壞情況f個節點全是非拜占庭節點），剩下2f+1個響應中可能有f個拜占庭節點，從而得到n-2f>f，即響應中非拜占庭節點數目大於拜占庭節點數目（f+1>f）。
算法不依賴同步提供安全性，則必須依賴同步提供活性，否則違背FLP定理(在異步通信場景，即使只有壹個進程失敗了，沒有任何算法能保證非失敗進程能夠達到壹致性)。在拜占庭節點不超過f，並且delay(t)有界的情況下就能保證系統活性，delay(t)表示從消息發送到接受的時間間隔。
在壹個view裏面，會從replicas中選擇壹個primary，其余的replicas則叫backups。如果主節點行為發生異常，則進行view change換主。 ?
遊戲從client向primary發送請求 開始。 狀態機操作， 時戳。 遊戲從client至少收到f+1個replicas的響應 結束。 視圖編號， 時戳， 客戶端身份， replica編號， 請求結果。why f+1？因為在2f+1個committed中有f個拜占庭節點表面上同意請求，實際上根本不會回復請求
3.1 重彩大戲------三階段協議
Pre-prepare:
Primary為客戶端請求分配壹個序列號n，向所有backups發現預準備消息 。 視圖編號， 消息 的摘要。
Prepare:
若滿足以下條件，backups接受預準備消息： 1.客戶端請求和預準備消息具有正確簽名。 2.當前視圖編號是v。 ? 3.backups從未在當前視圖v接收過序列號為n但摘要不同的預準備請求。 ? 4.h<n<H。防止壹個拜占庭節點選擇壹個大的序號來消耗序號空間
如果上述條件滿足，backups接收預準備消息，進入prepare階段，向其他節點廣播準備消息 ，並將預準備和準備消息寫入日誌。
commit:
如果backups收到2f包括自己個與預準備消息壹致的準備消息，請求消息和預準備消息具有相同的視圖v和序列號n，並且已將相關消息寫入日誌，則進入commit階段，向其他節點廣播壹條確認消息 。如果各節點收到2f+1條相同的commits消息，則向客戶端發送壹條reply消息。
3.2 垃圾回收
? PBFT是壹種狀態機副本復制算法，replicas會將執行過消息記錄在本地日誌中，為了節省內存，需要壹種機制來清理日誌。何時來清理？在每次操作完後執行是不明智的，因為比較耗資源。可以定期清理，比如每100次清理壹次。我們將請求後執行的狀態稱為檢查點checkpoint；帶證明的檢查點稱為stable certificate，當節點收到2f+1個checkpoint消息時，可證明穩定檢查點是正確的。穩定檢查點之前的日誌消息均可刪除。
? 當清理檢查點時replica i向其他replicas廣播壹條檢查點協議 ， 是最近壹次正確執行請求序號， 是其當前狀態摘要。如果每壹個replica收到2f+1個具有相同序號 和摘要 的檢查點消息，這時每壹個replica可以清理序列號 小於等於n的日誌信息。
檢查點協議也用來更新水平線。低水平線 等於最近穩定檢查點的序號，高水平線 ， 為日誌大小。
3.3 視圖更改
當主節點掛掉，或者在commit階段有些節點收到2f+1個commit，有些沒有收到2f+1個commit，導致狀態不壹致，這些狀況都需要更改視圖來提供系統活性和安全性。
當請求超時，備份節點進入視圖v+1，廣播視圖更改消息 。 穩定檢查點序列號， 是穩定檢查點證明， 是壹個集合，包含對請求 （請求的序列號大於 ）相關消息集合 。 包含2f+1個相同的準備消息。
?當視圖v+1的主節點收到2f個相同個視圖更改消息，向其他副本廣播新視圖消息 ， 是2f+1個視圖更改消息， 的計算規則如下： 1.確定序列號 和 。其中 等於 中穩定檢查點序列號, 等於 中最大prepare消息序列號。 ? 2.主節點為 和 之間的每壹個序列號n分配pre-prepare消息。如果 中包含n對應的 組合，則對應的預準備消息為 （也就是說序列號n對應的請求有2f+1個prepare消息，在新視圖中依然提交這個請求）。如果 中不包含n對應的 組合，則提交null消息為 ，即不做任何處理。
副本收到新視圖消息後，廣播壹次prepare消息，進入v+1，視圖更換完成。