分布式一致性問題，區塊鏈裡體現就是共識問題。
共識機制就是在乙個群體中的個體通過某種方式達成一致性的一種機制，比如在乙個團隊、或者乙個公司裡的個體意見不一致時，就需要有乙個領導，由領導來做決定，保證團隊達成共識。
目前的共識演算法，主要有基於算力的pow，基於股權的pos和基於投票的dpos演算法，以及著名的拜占庭容錯演算法。
團隊裡的共識機制延伸到普通的分布式系統裡面，就是系統需要有乙個master，系統的所有決定都由master來達成共識，在分布式系統裡面master的選舉其實就是基於某種共識機制達成共識。
到了區塊鏈中，由於區塊鏈是一種去中心化的分布式系統，所以區塊鏈中是沒有類似於團隊裡的領導，以及分布式系統中的master的角色，這樣就需要有某種共識機制，以便保證系統一致性。
實際上當節點之間的通訊網路不可靠的情況下，系統是無法達成共識的，具體原因請參考「兩軍問題"。
即使在網路通訊可靠的情況下，乙個可擴充套件的分布式系統的共識問題也是無解的。這個結論被稱為」flp不可能性原理「。一般的把故障（不響應）即通道不可靠的情況稱為」非拜占庭錯誤「,惡意響應（即系統被攻擊）稱為」拜占庭錯誤「。
拜占庭將軍問題是乙個共識問題: 首先由leslie lamport與另外兩人在2023年提出，被稱為the byzantine generals problem或者byzantine failure。核心描述是軍中可能有叛徒，卻要保證進攻一致，由此引申到計算領域，發展成了一種容錯理論。
一群將軍想要實現某乙個目標（一致進攻或者一致撤退），但是單獨行動行不通，必須合作，達成共識；由於叛徒的存在，將軍們不知道應該如何達到一致。
1.兩軍問題和tcp協議
拜占庭將軍問題中並不去考慮通訊兵是否會被截獲或無法傳達資訊等問題，即訊息傳遞的通道絕無問。lamport已經證明了在訊息可能丟失的不可靠通道上試圖通過訊息傳遞的方式達到一致性是不可能的。所以，在研究拜占庭將軍問題的時候，我們已經假定了通道是沒有問題的，並在這個前提下，去做一致性和容錯性相關研究。
如果需要考慮通道是有問題的，這涉及到了另乙個兩軍問題，兩軍問題在經典情境下是不可解的，現代通訊系統中應用三次握手與tcp協議來處理此類問題，不過這也只是一種相對可靠的方式。
2.口頭協議演算法
對於這個演算法需要說明的是：
(1) 在第一輪將軍會把訊息傳送給所有的副官，第i個副官收到的記為 vi。如 1(這裡代表的是attack)
(2) 在第二輪裡面，li(即第i個副官)會懷疑將軍發來的訊息vi是對還是錯，於是他會問其餘的副官。這樣他就會得到剩下的(n-2)個副官的值。 i從1到n-1，所以每個副官都會得到剩餘的n-2個副官手裡的vi。在這一步驟裡，忠誠的副官j會直接將自己的 vj傳送給其它人。叛徒則會發假訊息。
在n=7,m=2的時候 如果將軍是忠臣的話，那麼在第二輪忠誠的副官確實已經可以判斷出要做的決定，因為他們會收到(1 1 1 0 0 )再加上將軍發來的1就是 1 1 1 1 0 0 但是這個演算法是遞迴的所有必須要到第三輪。並且如果將軍是個叛徒的話，那麼第二輪有情形是做不出決定的。
這裡對進入第三輪的解釋是，如l1收到其它l2~l6發來的vj, 但是他要懷疑準確性，比如l1會想l2發給自己是否是正確的呢？那麼就進入第三輪進行投票。
(3)在第三輪裡面，接著(2)中後面的問題。l1會依次詢問l3,4,5,6 ，問他們上一輪l2給他們發了什麼，然後l1會得到在(2)中 l2->l3, l2->l4,l2->l5, l2->l6的值 這樣再結合自己的l2->l1的值，從這5個裡面用majority函式投出決定得到l2發給自己的訊息值。依次再進行l3,l4,l5,l6在第二輪中發給自己的訊息的確認。
這樣l1就完成了第二輪的確認。之後l1再從第一步中將軍發給自己的vi和第二輪中確定的5個值中投出自己的決定。
其餘的l2，l3後續也進行同樣的步驟。
3.書面協議演算法
書面協議和口頭協議最大區別是，副官可以叛變並且說謊，也就是中國人講的口說無憑。
現在我們給訊息加上將軍的簽名，必須通過簽名來驗證，就是為了防止說謊。
在簽名演算法中加了兩個條件：
這裡lamport規定，每條訊息只可以複製，然後加上自己的姓名再發出去。
這裡借用乙個模擬（知乎[devin zeng]：
pbft演算法要求至少要4個參與者，乙個被選舉為總司令，3個師長。**對總司令下達命令，你們向前行軍500公里，總司令就會給3個師長發命令向前行軍500公里。3個軍長收到訊息後會執行命令，並匯報結果。a師長說我在首都以東500公里，b師長說我在首都以東500公里，c師長說我在首都以東250公里。總司令總結3個師長的匯報，發現首都以東500公里占多數（2票》1票），所以就會忽略c軍長的匯報結果，給**說，好了，現在部隊是在首都以東500公里了。1.五個概念
client：請求（request）資源者
replica：副本，所有參與提供服務的節點
primary：承擔起提供服務主要職責的節點
backup：其他副本，但相對於primary角色
view：處於存在primary-bakup場景中的相對穩定的關係，叫檢視。
如果primary出現故障，這種相對穩定的檢視關係就會轉變（transit），某個backup轉變為primary。
2.四個階段
client請求階段，客戶端請求資源。
預準備（pre-prepare）：主節點向所有backup節點傳送預準備訊息，其中包括當前檢視編號，client請求以及請求摘要，簽名是否一致等。
準備(prepare)：包括主節點在內的所有副本節點在收到準備訊息之後，對訊息的簽名是否正確，檢視編號是否一致，以及訊息序號是否滿足水線限制這三個條件進行驗證，如果驗證通過則把這個準備訊息寫入訊息日誌中。
確認(commit)：每個副本接受確認訊息的條件是：1）簽名正確；2）訊息的檢視編號與節點的當前檢視編號一致；3）訊息的序號n滿足水線條件，在h和h之間。一旦確認訊息的接受條件滿足了，則該副本節點將確認訊息寫入訊息日誌中。
回覆（reply）：結果反饋。
共識真的不能達成嗎
關於拜占庭等問題的討論只是學術上極端情況下的理論值，現實中的物理系統遠比這個要複雜，我們付出一定的代價總是能做到一定程度的共識。
參考拜占庭將軍問題深入**
共識演算法（三） Raft（分布式一致性演算法）
raft替代了paxos 太複雜 並提供了一種在計算系統集群中分布狀態機的通用方法，確保集群中的每個節點都同意一系列相同的狀態轉換，也就是說，它在提供的計算機集群分布狀態機時，有個別或者多個狀態機down掉了，從而使其狀態不統一並影響了consensus一致性，繼而影響了整個系統的執行，而raft演...
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...
分布式一致性
分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...