區(qū)塊鏈的起源你得了解一些

今天一樣繼續(xù)來說區(qū)塊鏈的起源，探討“拜占庭容錯” PBFT（Practical Byzantine Fault Tolerance）。拜占庭容錯是一種基于嚴(yán)格數(shù)據(jù)證明的算法，至少需要經(jīng)過三個階段的信息交換和通過局部共識達至最終的一致性結(jié)果。

簡單來說，系統(tǒng)中有可信節(jié)點超過三分之二，有問題的節(jié)點不超過三分之一時，不管這些節(jié)點如何散播與傳達有問題的信息時，可信節(jié)點之間都一定能達到一致共識;

其實就是每一個收到訊息的節(jié)點不斷的重復(fù)與彼此雙雙交換訊息，互相驗證，讓其中可信的節(jié)點之間能確認(rèn)出正確的訊息，找出少數(shù)那些有問題的節(jié)點。以拜占庭帝國的例子來說，就是將軍們不斷重復(fù)彼此確認(rèn)訊息，來找出間諜，以及直到確認(rèn)接受到正確的命令。

所以能夠保證達到一致共識的拜占庭系統(tǒng)節(jié)點數(shù)至少為4個，容許出現(xiàn)1個壞的節(jié)點。亦即：節(jié)點總數(shù) ≥ 3有問題節(jié)點總數(shù) + 1，這就是“拜占庭容錯”。

只看滿滿的文字，實在還是很難理解拜占庭容錯的運篹方法，我們就來用圖表一段段解釋，《區(qū)塊鏈 Block chain – 共識機制之實用拜占庭容錯 PBFT》這篇文章對「拜占庭容錯」的步驟猜拆解非常詳細(xì)。

對于拜占庭將軍問題，PBFT 算法至少通過三個階段達成一致性的協(xié)議：《請求 Request、預(yù)準(zhǔn)備 Pre-Prepare、回復(fù) Reply 》，根據(jù)不同的協(xié)議設(shè)計，亦可能同時包含《準(zhǔn)備 Prepare、確認(rèn) Commit》

A. 首先背景套用上面拜占庭將軍的故事，同時 PBFT算法最少要求有4個參與者

B. C：元帥、0：司令、1：將軍1號、2：將軍2號、3：將軍3號。

C. 勝利條件：2/3以上的軍隊都共同發(fā)起“進攻”。

拜占庭容錯運作過程分解

拜占庭容錯運作過程分解 圖片來源：https://www.samsonhoi.com/570/blockchain-pbft

五大程序：

1、元帥命令司令“進攻”

（C 發(fā)送“請求”到 0）

2、司令收到“進攻”命令后，分別傳遞給所有的將軍

（0 發(fā)送“預(yù)準(zhǔn)備”到1、2、3）

3、將軍1號收到由司令和將軍2號的“進攻”通知，但遲遲沒有收到將軍3號的回應(yīng)，就將將軍3號忽略，并認(rèn)為“進攻”是正確的，就下令“進攻”。并把“進攻”命令傳遞給其余將軍

（1收到0、2的“準(zhǔn)備”，但并沒有收到3，1 發(fā)送“準(zhǔn)備”給2、3，發(fā)送 “確認(rèn)” 給0）

將軍2號收到由司令和將軍1號的“進攻”通知，但遲遲沒有收到將軍3號的回應(yīng)，就將將軍3號忽略，并認(rèn)為“進攻”是正確的，就下令“進攻”。并把“進攻”命令傳遞給其余將軍

（2收到0、1的“準(zhǔn)備”，但并沒有收到3，2 發(fā)送“準(zhǔn)備”給1、3、0，發(fā)送 “確認(rèn)” 給0）

4、將軍3號收到司令、將軍1號、將軍2號的“進攻”通知，這次不一樣的是，將軍3號沒有把“進攻”要求傳遞給其他將軍，而是害怕得臨陣逃跑了

（3并沒有發(fā)送“準(zhǔn)備”給0、1、2，而且沒有發(fā)送 “確認(rèn)” 給0）

5、最后，所有的將軍親自向元帥匯報執(zhí)行的情況（司令、將軍1號、軍2號將），而3號將軍并沒有回復(fù)，所以將其視為逃跑或陣亡了，也就不理會他的結(jié)果，元帥也就認(rèn)為大部份軍隊都“進攻”，而且勝利了，不過同時亦發(fā)現(xiàn)將軍3號有問題。

在以上這個過程，如在節(jié)點總數(shù) ≥ 3有問題節(jié)點總數(shù) + 1 的情況下，即使其中一位將軍逃跑了，沒執(zhí)行“進攻”，但最后仍取得勝利，但對國家造成危害（其中一個節(jié)點失效對系統(tǒng)造成的危害），亦會得知哪位將軍有問題，而在 PBFT 的共識機制下，雖然出現(xiàn)有問題的節(jié)點，但這是容許的，不影響最終一致性的結(jié)果，這就是所謂 PBFT 算法的流程。

責(zé)任編輯：ct