【go共識算法】-PBFT

實用拜占庭容錯系統介紹

由來

原始的拜占庭容錯系統因爲須要展現理論上的可行性而缺少實用性。另外，算法的複雜度也是隨節點的增長而呈指數級增長。實用拜占庭容錯系統（Practical Byzantine Fault Tolerance, PBFT）下降了拜占庭協議的運行復雜度，從指數級別下降到多項式級別，使拜占庭協議在分佈式系統中應用成爲可能。

什麼是實用拜占庭容錯系統

實用拜占庭容錯系統是一類「狀態機」拜占庭系統（這裏的狀態機能夠理解爲「系統狀態」，以區塊鏈記帳爲例，系統每新增一個區塊，帳本就更新到一個新的狀態。前面講過，拜占庭容錯系統是一個強一致性協議，每次記帳後系統都會達成新的狀態。），要求系統全部節點共同維護一個狀態，全部節點採起的行動一致。

實用拜占庭容錯系統須要運行三類基本協議：

• 一致性協議：解決如何達成共識
• 檢查點協議：相似於操做系統的還原點
• 視圖更換協議：系統的每一個服務器節點在一樣的配置信息下工做，該配置信息被稱爲「視圖」。配置信息由主節點肯定，主節點更換，視圖也隨之變化。

咱們主要關注支持系統平常運行的一致性協議。

PBFT 的 一致性協議

一致性協議至少包含請求（request）、序號分配（pre-prepare）、響應（reply）三個階段。根據協議設計的不一樣，可能包含相互交互(prepare) 、序號確認(commit)等階段。

PBFT系統一般假設故障節點個數爲m個，而整個服務節點數爲3m+1個。

上圖顯示了一個簡化的 PBFT 的協議通訊模式，其中C爲客戶端，N0~N3爲服務節點，N0爲主節點，N3爲故障節點。協議的節本過程以下：

1. Request：客戶端發送請求，激活主節點的服務操做

2. 當主節點接收請求後，啓動三階段的協議以向各從節點廣播請求

   • Pre-Prepare：主節點給請求賦值一個序列號n，廣播序號分配消息和請求消息，並構造PRE-PREPARE消息給各從節點
   • Prepare：從節點接收PRE-PREPARE消息，並向其餘服務節點廣播PREPARE消息
   • Commit：各節點對視圖內的請求和次序進行驗證後，廣播COMMIT消息，執行收到的客戶端的請求並給客戶端以響應
3. Reply：客戶端等待來自不一樣節點的響應，如有m+1個響應相同，則該響應即爲運算的結果

PBFT 演示

在 n ≥ 3m + 1 的情況下一致性是可能解決的，其中，n爲總節點數，m爲惡意節點總數。咱們模擬一下PBFT：
n = 4, m = 0

節點	獲得數據	最終結果
A	1111	1
B	1111	1
C	1111	1
D	1111	1

n = 4, m = 1

節點	獲得數據	最終結果
A	1110	1
B	1101	1
C	1011	1
D	0111	1

n = 4，m = 2

節點	獲得數據	最終結果
A	1100	1
B	1001	1
C	0011	1
D	0110	1

go 實現簡單PBFT

下載代碼

git clone https://github.com/bigpicturelabs/consensusPBFT.git

編譯

go build main.go

測試

新打開 5 個終端

./main Apple

./main MS

./main Google

./main IBM

curl -H "Content-Type: applicaton/json" -X POST -d '{"clientID":"ahnhwi","operation":"GetMyName","timestamp":859381532}' http://localhost:1111/req