本文爲萬向區塊鏈技術中心研究組撰寫，文章嘗試對PBFT算法的正確性證明以及算法優化等內容作一個介紹。
1. PBFT算法正確性證明
本部分介紹PBFT算法的正確性證明。
1.1 安全性（Safety）證明
PBFT算法提供的安全性（safety）的具體含義是，對於所有本地確認（commit locally）的客戶端請求來說，系統中所有正常副本節點都會就這些請求的消息序號達成一致。
上述的“達成一致”，其含義又分爲兩種：
同一視圖中的消息序號一致：對於所有在同一視圖中本地確認的客戶端請求來說，各正常副本節點就其消息序號會達成一致。
新舊視圖中的消息序號一致：對於在新舊視圖中本地確認的客戶端請求來說，各正常副本節點就其消息序號會達成一致。
接下來分別證明上述兩種“一致”是成立的。
1. 在同一視圖中，任何一個請求 m ，如果其已經本地確認過，也就是說，至少對於某一個正常副本節點 i 來說，prepared(m, v, n, i) 爲 true , 之前已經證明過，此時，對於任意的正常副本節點 j （j也可以是 i） 來說，prepared(m’, v, n, j) 都爲 false 。這裏 m’ 是不同於 m 的另一個請求，也就是說 D(m’) 不等於 D(m) 。這就意味着對於所有在同一視圖中本地確認的客戶端請求來說，各正常副本節點就其消息序號會達成一致，第一個性質成立。
2. 現在考慮存在視圖變更的情況。首先，在視圖 v 中，對於任意一個請求 m 來說，如果其在 某個正常副本節點 i 完成了本地確認，假設其消息序號爲 n 。那麼，就有 committed(m, v, n) 爲 true 。 這也意味着存在一個節點集合R1, 其中至少含有 f+1 個正常副本節點，並且對於其中每一個節點 i ，prepared(m, v, n, i) 爲 true。
然後，考慮系統最終變更視圖到 v' 的情況。在從視圖 v 變更到 v' 的過程中，此時變更沒有完成，正常副本節點在接收到 new-view 消息之前，不會接受視圖 v' 上的預準備消息。
但是，對於視圖 v 變更到 v'的任意一個有效的 new-view 消息來說，其中包含 2f+1 個有效的view-change 消息。這些消息來自不同的副本節點，記它們組成的集合爲R2。R1和R2至少有一個相同的元素，也就是相同的節點。不然的話，它們總的節點個數將爲(f+1) + (2f+1) = 3f+2，這與我們假定的系統總節點個數 3f+1 不符。
因此，假設這個共同的正常副本節點爲 k 。對於請求 m 來說，只有可能存在下面兩種情況：new-view 消息中，存在 view-change 消息，其中包含的最新穩定檢查點對應的消息序號大於 m 的序號 n 。new-view 消息中所有的 view-change 消息中包含的最新穩定檢查點對應的消息序號不大於m的序號n。
對於第一種情況，根據視圖變更協議，新視圖 v' 中，所有正常副本節點不會接受序號爲n或小於n的消息。
對於第二種情況，m 將會被傳播到新視圖 v'中，因爲根據視圖變更協議，min-s≤n。視圖變更完成後，在 v' 中，算法將針對編號爲 n 的請求 m 重新運行三階段協議。這就使得所有正常副本節點會達成一致，而不會出現下面這種情況：
另一個不同於 m 的請求 m' ， 其在視圖 v 中分配的序號爲 n ，且在新視圖中 v' 完成本地確認。
綜合上面 1 和 2 的證明，就證明了算法在同一視圖和視圖變更過程中，都會保證本地確認的請求的序號在所有正常副本節點中會達成一致，從而保證了算法的安全性（safety）。
1.2 活性（Liveness）保證
對於PBFT算法來說，爲了保證系統的活性（liveness），當節點無法執行客戶端請求時，需要變更到新的視圖。同時，視圖變更也需要進行合理控制，只在需要時才進行，否則頻繁的視圖變更會影響到系統的活性。這就需要保證以下兩點：
系統中至少 2f+1 個正常副本節點處於同一視圖中時，這種狀態儘可能長時間地保持；
每次視圖變更時，上述時間間隔需要快速增長，比如以指數形式增長。
PBFT算法通過如下三種方法來保證上述兩點：
1. 爲了防止視圖變更太快開始，當一個節點發送 view-change 消息後，在等待接收 2f+1 個 view-change消息時，會同時啓動定時器，其超時時間設置爲 T。如果視圖變更沒有在 T 時間內完成，或者在新視圖中請求沒有在該時間間隔內完成，則會觸發新的視圖變更。此時，算法會調整超時時間，將其設置爲原來的兩倍，即 2T 。
2. 除了上述的定時器超時觸發節點發送 view-change 消息外，當其接收到來自 f+1 個不同節點的有效view-change 消息，並且變更的目標視圖大於節點當前視圖時，也會觸發節點發送 view-change 消息。這可以防止節點過晚啓動視圖變更。
3. 基於上述第二點的規則，失效節點無法通過故意發送 view-change 消息來觸發頻繁的視圖變更從而干擾系統的運行。因爲失效節點最多隻能發送 f 條消息，達不到 f+1 的觸發條件。失效節點是主節點時，可能會觸發視圖變更，但是連續的視圖變更最多隻會是 f 個，之後主節點就是正常節點。因此，基於以上的規則，系統可以保證活性。
2. PBFT算法的優化
本部分介紹PBFT算法的優化。這些優化方式應用於算法的正常操作中，可以提升算法的性能，同時可以保持系統的安全性和活性。
2.1 減少系統通信量
可以採用三種方法減少系統通信量：
1. 向客戶端發送回覆的消息摘要，而不是回覆的原始內容客戶端指定一個特定的副本節點，從該節點接收完整的回覆內容，而只從其他所有節點處接收回復的摘要。通過判讀摘要與回覆的一致性以及對回覆計數，可以確保接收到正確的回覆。如果客戶端接收不到正確結果，就會按正常流程重新請求系統，並接收不同節點的完整回覆。
2. 請求在副本節點prepared後，節點即試探性地執行請求，併發送結果。客戶端只要收到 2f+1 個匹配的結果，就可以確保該結果的正確性。也就是說，該請求最終會確認（至少f+1 個正常副本節點的本地確認）。如果客戶端無法得到正確結果，就重新發送請求，系統執行正常流程。一個被試探性執行的請求，有可能在視圖變更過程中被中斷，並被替換爲一個空請求。此時，已經執行過請求的節點可以通過 new-view 消息中的最新的穩定檢查點或本地的檢查點來更新狀態（取決於哪個序號更大）。
3. 針對只讀操作，客戶端將請求廣播到每一個副本節點。各節點判斷請求確實爲只讀且滿足條件後，直接執行請求，併發送回復到客戶端。客戶端收到 2f+1 個相同的回覆，即爲正確結果；否則客戶端之前設置的重發請求定時器將觸發超時，使得客
戶端重發請求，系統執行正常流程。
這種優化的前提條件是，副本節點在執行請求之前，需確保之前所有請求都已確認，並且被執行。
2.1 加快消息驗證速度
使用公鑰簽名的方式驗證消息存在如下不足：
類似於RSA這樣的簽名算法，簽名速度比較慢；
其他公鑰密碼系統，如橢圓曲線公鑰密碼系統，雖然簽名更快，但是驗籤更慢。
PBFT算法實際上在正常流程中採用 MAC(Message Authentication Code，消息驗證碼) 認證消息，因爲它具有如下優點，使得算法相對於之前的算法性能提升了一個數量級以上：
MAC 計算速度快；
通過適當優化，可以減少其長度；
通過對authenticator（vector of MAC）的使用，可以使驗證時間爲常量，而生成時間只隨着節點數量線性增長。
具體來說，PBFT算法中使用 MAC 和公鑰簽名的具體場景是：
所有正常操作流程中使用 MAC 驗證消息；
視圖變更中的消息：view-change, new-view，以及出現錯誤時，使用公鑰簽名。這些場景的出現頻率相
對較低，從而對算法的性能影響較小。
相關閱讀：