一、前言

本文是一篇針對的是區塊鏈的共識機制的序言，也可以說是“雜燴”。之後，還會詳細地針對共識機制描述的博文。

提及共識機制，我們不得不說到中本聰的在《Bitcoin: A peer-to-peer electronic cash system》文章中涉及的工作量證明（POW）。這種共識機制在去中心化的思想下解決了節點間相互信任的問題，使得區塊鏈能在眾多的節點上達到一種較為平衡的狀態。區塊鏈解決了在不可信通道上傳輸可信資訊、價值轉移的問題，而共識機制解決了區塊鏈如何在分散式場景下達成一致性的問題，奠定了比特幣系統的安全性。說到分散式一致性問題，其實由來已久。因為傳統分散式系統的一致性演算法是一個從上世紀70年代就開始研究的經典問題。Fischer, Lynch 和 Patterson在1985年發表《Impossibilityof Distributed Consensuswith One Faulty Process》，論文中提出了可以說是最重要的分散式系統定理：FLP不可能性；2000年，EricBrewer教授在PODC的研討會上提出了一個猜想：一致性、可用性和分割槽容錯性三者無法在分散式系統中被同時滿足，並且最多隻能滿足其中兩個；2002年，Lynch與其他人證明了Brewer猜想，從而把CAP上升為一個定理。這期間和之後，都湧現了一些很有名的分散式一致性演算法，如LeslieLamport在1989年提出的Paxos；1999年Castro和Liskov提出的PBFT，這是第一個得到廣泛應用的BFT演算法，IBM的Hyperledge fabric就是基於PBFT共識機制的。

所以現在的不少共識機制的都是修改自那些分散式領域的大拿的成果。

二、FLP不可能性

FLPImpossibility（FLP不可能性）是分散式領域中一個非常著名的結果，該結果在專業領域被稱為“定理”，其地位之高可見一斑。FLP給出了一個令人吃驚的結論：在非同步通訊場景，即使只有一個程序失敗，也沒有任何演算法能保證非失敗程序達到一致性！

因為同步通訊中的一致性被證明是可以達到的，因此在之前一直有人嘗試各種演算法解決以非同步環境的一致性問題，有個FLP的結果，這樣的嘗試終於有了答案。

三、CAP理論

在理論電腦科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem），它指出對於一個分散式計算系統來說，不可能同時滿足以下三點：

1.  一致性（Consistency)：同一個資料在叢集中的所有節點，同一時刻是否都是同樣的值。

2.  可用性（Availability）：叢集中一部分節點故障後，叢集整體是否還能處理客戶端的更新請求。

3.  分割槽容忍性（Partition tolerance）：是否允許資料的分割槽，分割槽的意思是指是否允許叢集中的節點之間無法通訊。

四、拜占庭將軍問題

4.1什麼是拜占庭將軍問題

拜占庭將軍問題是一個共識問題: 首先由Leslie Lamport與另外兩人在1982年提出，被稱為The Byzantine Generals Problem或者Byzantine Failure。核心描述是軍中可能有叛徒，卻要保證進攻一致，由此引申到計算領域，發展成了一種容錯理論。

關於拜占庭將軍問題，一個簡易的非正式描述如下：

拜占庭帝國想要進攻一個強大的敵人，為此派出了10支軍隊去包圍這個敵人。這個敵人雖不比拜占庭帝國，但也足以抵禦5支常規拜占庭軍隊的同時襲擊。基於一些原因，這10支軍隊不能集合在一起單點突破，必須在分開的包圍狀態下同時攻擊。他們任一支軍隊單獨進攻都毫無勝算，除非有至少6支軍隊同時襲擊才能攻下敵國。他們分散在敵國的四周，依靠通訊兵相互通訊來協商進攻意向及進攻時間。困擾這些將軍的問題是，他們不確定他們中是否有叛徒，叛徒可能擅自變更進攻意向或者進攻時間。在這種狀態下，拜占庭將軍們能否找到一種分散式的協議來讓他們能夠遠端協商，從而贏取戰鬥？這就是著名的拜占庭將軍問題。

應該明確的是，拜占庭將軍問題中並不去考慮通訊兵是否會被截獲或無法傳達資訊等問題，即訊息傳遞的通道絕無問。Lamport已經證明了在訊息可能丟失的不可靠通道上試圖通過訊息傳遞的方式達到一致性是不可能的。所以，在研究拜占庭將軍問題的時候，我們已經假定了通道是沒有問題的，並在這個前提下，去做一致性和容錯性相關研究。

4.2拜占庭問題的實質

根據上面非正式的描述，一群將軍想要實現某一個目標（一致進攻或者一致撤退），但是單獨行動行不通，必須合作，達成共識；由於叛徒的存在，將軍們不知道應該如何達到一致。而這裡“一致性”才是拜占庭將軍問題探討的內容。

但是，光靠“一致”就可以解決問題嗎？考慮一下，如果萬事俱備，客觀上每個忠誠的將軍只要進攻了就一定能夠勝利，但是卻因為叛徒的存在他們都“一致的”沒有進攻；反之，條件不利，將軍們不應該進攻，但是卻因為叛徒的存在所有人都“一致的”進攻了。

可以發現，只有“一致性”是不足以解決拜占庭將軍問題的，我們還需要提出一個“正確性”要求。這個要求是值得斟酌的，因為如果客觀來看或許會有“絕對正確的”判斷，但是針對每一個將軍，大家的判斷或許都不相同，我們如何定義“正確”呢？我們或許可以簡單地說，正確就是每個忠誠的將軍都正確的表達了自己的意思，不會因為叛徒讓別的將軍認為忠誠的將軍是叛徒而不採用他傳達的訊息。

至此，我們將拜占庭將軍問題簡化成了，所有忠誠的將軍都能夠讓別的將軍接收到自己的真實意圖，並最終一致行動；而形式化的要求就是，“一致性”與“正確性”。

如果將問題推廣開來，可以發現針對一致性和正確性的演算法並不要求命令必須是“進攻/撤退”或是“1/0”，而可以是“傳送訊息1/傳送訊息2/待機”或“x/y/z/w”，這意味著拜占庭將軍問題演算法可以為多種分散式系統提供啟發，比如電力系統或網路系統。

由此可見，這個問題說到底是一個關於一致性和正確性的演算法問題，這個演算法是針對的是忠誠的將軍，因為叛徒可以做出任何超出約定的判斷。我們就是要在有叛徒的干擾下，找到一個抗干擾的演算法。要解決這個演算法問題，我們需要將形式化要求具體化。

在經典的情形下，口頭協議和書面協議這兩種方法可以解決此問題。

四、傳統分散式一致性演算法

4.1 Paxos演算法

1998年Lamport提出Paxos演算法，後續又增添多個改進版本的Paxos形成Paxos協議家族，且Paxos都有共同點是不容易工程實現。Paxos被用於分散式系統中典型的例子就是Zookeeper，他是第一個被證明的共識演算法，其原理基於兩階段提交併擴充套件。

Paxos演算法中將節點分為三種類型：proposer：提出一個提案，等待大家批准為結案。往往是客戶端擔任該角色acceptor：負責對提案進行投票。往往是服務端擔任該角色learner：被告知結案結果，並與之統一，不參與投票過程。可能為客戶端或服務端基本過程包括 proposer 提出提案，先爭取大多數 acceptor 的支援，超過一半支援時，則傳送結案結果給所有人進行確認。一個潛在的問題是 proposer 在此過程中出現故障，可以通過超時機制來解決。極為湊巧的情況下，每次新的一輪提案的 proposer 都恰好故障，系統則永遠無法達成一致（概率很小）。Paxos 能保證在超過50%的正常節點存在時，系統能達成共識。

4.2PBFT演算法

1999年Castro和Liskov提出的PBFT演算法，它是第一個得到廣泛應用的BFT演算法。這是一種基於訊息傳遞的一致性演算法，演算法經過三個階段達成一致性，這些階段可能因為失敗而重複進行。

假設節點總數為3f+1，f為拜占庭錯誤節點：

1.  當節點發現leader作惡時，通過演算法選舉其他的replica為leader。

2.  leader通過pre-prepare （第一個協議階段）訊息把它選擇的 value廣播給其他replica節點，其他的replica節點如果接受則傳送 prepare（第二個協議階段），如果失敗則不傳送。

3.  一旦2f個節點接受prepare訊息，則節點發送commit（第三個協議階段）訊息。

4.  當2f+1個節點接受commit訊息後，代表該value值被確定 如下圖表示了4個節點，0為leader，同時節點3為fault節點，該節點不響應和發出任何訊息。最終節點狀態達到commited時，表示該輪共識成功達成。 注：預準備階段（pre-prepare）：主節點分配一個序列號n給收到的請求，然後向所有備份節點群發預準備訊息，預準備訊息的格式為<<PRE-PREPARE,v,n,d>,m>，這裡v是檢視編號，m是客戶端傳送的請求訊息，d是請求訊息m的摘要。準備階段（prepare）： 如果備份節點i接受了預準備訊息<<PRE-PREPARE,v,n,d>,m>，則進入準備階段。在準備階段的同時，該節點向所有副本節點發送準備訊息<PREPARE,v,n,d,i>，並且將預準備訊息和準備訊息寫入自己的訊息日誌。如果看預準備訊息不順眼，就什麼都不做。確認階段（commit）： 當(m,v,n,i)條件為真的時候，副本i將<COMMIT,v,n,D(m),i>向其他副本節點廣播，於是就進入了確認階段。

五、常見區塊鏈共識模型

5.1POW

依賴機器進行數學運算來獲取記賬權，資源消耗相比其他共識機制高、可監管性弱，同時每次達成共識需要全網共同參與運算，效能效率比較低，容錯性方面允許全網50%節點出錯。

5.2POS

Proofof Stake由Quantum Mechanic 2011年在bitcointalk首先提出。

存在一個持幣人的集合，他們把手中的代幣放入POS機制中，這樣他們就變成驗證者。假設在區塊鏈最前面一個區塊（區塊鏈中最新的塊），這時POS演算法在這些驗證者中隨機選取一個（選擇驗證者的權重依據他們投入的代幣多少，比如一個投入押金為10000代幣的驗證者被選擇的概率是一個投入1000代幣驗證者的10倍），給他們權利產生下一個區塊。如果在一定時間內，這個驗證者沒有產生一個區塊，則選出第二個驗證者來代替來產生新區塊。與POW一樣，以最長的鏈為準。

5.3DPOS

與PoS的主要區別在於節點選舉若干代理人，由代理人驗證和記賬。其合規監管、效能、資源消耗和容錯性與PoS相似。類似於董事會投票，持幣者投出一定數量的節點，代理他們進行驗證和記賬。

DPoS的工作原理為：去中心化表示每個股東按其持股比例擁有影響力，51%股東投票的結果將是不可逆且有約束力的。其挑戰是通過及時而高效的方法達到51%批准。為達到這個目標，每個股東可以將其投票權授予一名代表。獲票數最多的前100位代表按既定時間表輪流產生區塊。每名代表分配到一個時間段來生產區塊。所有的代表將收到等同於一個平均水平的區塊所含交易費的10%作為報酬。如果一個平均水平的區塊含有100股作為交易費，一名代表將獲得1股作為報酬。

5.4Casper（投注共識）

這是一種以太坊下一代的共識機制，屬於PoS。Casper的共識是按塊達成的而不是像PoS那樣按鏈達成的。

為了防止驗證人在不同的世界中提供不同的投注，還有一個簡單嚴格的條款：如果你有兩次投注序號一樣，或者說你提交了一個無法讓Casper合約處理的投注，你將失去所有保證金。從這一點我們可以看出，Casper與傳統的PoS不同的是Casper有懲罰機制，這樣非法節點通過惡意攻擊網路不僅得不到交易費，而且還面臨著保證金被沒收的風險。

Casper協議下的驗證人需要完成出塊和投注兩個活動。具體如下：

1.  出塊是一個獨立於其它所有事件而發生的過程：驗證人收集交易，當輪到他們的出塊時間時，他們就製造一個區塊，簽名，然後傳送到網路上。投注的過程更為複雜一些。目前Casper預設的驗證人策略被設計為模仿傳統的拜占庭容錯共識：觀察其他的驗證人如何投注，取33%處的值，向0或者1進一步移動。

2.  而客戶端的確認當前狀態的過程如下所示：

一開始先下載所有的區塊和投注，然後用上面的演算法來形成自己的意見，但是不公佈意見。它只要簡單的按順序在每個高度進行觀察，如果一個塊的概率高於0.5就處理它，否則就跳過它。在處理所有的區塊之後得到的狀態就可以顯示為區塊鏈的“當前狀態”。客戶端還可以給出對於“最終確定”的主觀看法：當高度k之前的每個塊，意見要麼高於99.999%或者低於0.001%，那麼客戶端就可以認為前k個塊已經最終確定。

六、總結

POW不足：目前bitcoin已經吸引全球大部分的算力，其它再用Pow共識機制的區塊鏈應用很難獲得相同的算力來保障自身的安全；挖礦造成大量的資源浪費；共識達成的週期較長。

POS不足：還是需要挖礦，本質上沒有解決商業應用的痛點；所有的確認都只是一個概率上的表達，而不是一個確定性的事情，理論上有可能存在其他攻擊影響。

DPOS不足：整個共識機制還是依賴於代幣，很多商業應用是不需要代幣存在的。