共識機制的概念，我們在前面的文章“淺說區塊鏈共識機制”中已經講解了一部分，但是，共識算法其實是一個非常大的話題，一篇文章肯定沒有辦法做到面面俱全。
那么今天的內容，我會將重點放在梳理技術的脈絡上，詳細分析的部分會少一點。如果你對共識算法有興趣的話，可以自行查找相關內容，也可以和其他的資料進行相互補充的閱讀。
從相親大會說起：分布式系統的模型
由於區塊鏈就是一種分布式系統，所以這篇文章我就從這一概念開始講起。 為了讓你更容易理解分布式系統，我們先來構建一個模型。
在“淺說區塊鏈共識機制”那篇文章中，我舉了一個村庄舉辦相親大會的例子，我們來回顧一下。
- 大村子因為人口增長變成11個小村落分散在地圖各地；
- 村落之間的通信只能依靠信鴿；
- 一只信鴿可能無法完全覆蓋所有村落，需要有中繼村落代為傳輸消息。
相親大會的舉辦權會為村子帶來巨大收益，為了產生合理的舉辦者，人們約定了幾條規則：
- 大會舉辦權從A和B兩個村子中產生，他們每一屆都是候選村；
- 投票時所有村落僅能投A或B；
- 用投票的方式產生舉辦者，少數服從多數。
所有村子會為了舉辦權都會使出渾身解數，比如延遲發送投票結果、篡改別人的投票結果、假裝沒有接收到通知等等。
其實這是一個典型的分布式系統，可以看成是我們簡化版的區塊鏈網絡環境，那么這個分布式系統會遇到什么樣的問題呢？
分布式系統面臨的問題
分布式系統面臨了幾個問題：一致性問題，可終止性問題、合法性問題。
可終止性可以理解為系統必須在有限的時間內給出一致性結果，合法性是指提案必須是系統內的節點提出。當然其中面對的最重要也是最基礎的問題，就是我們常說的一致性問題。
一致性是指在某個分布式系統中，任意節點的提案能夠在約定的協議下被其他所有節點所認可。
需要提醒你區分的一點是：這里的“認可”表示所有節點對外呈現的信息一致，而不是對信息的內容認可。一致性也分嚴格一致性、最終一致性，這些我們在后文會談到。
我們回到上面的例子，我們提到了所有的村子只能投A或B，其實這個投票的動作可以理解為提案。
在“投票過程被大家所認可”這個語境下，“被大家所認可”表示某個村落投票的結果已經被記錄，用於最后統計結果，而不是認可投給A或者投給B，這也是我在上述強調你要注意區分的一點。
那我們這里所說的一致性到底體現在那里呢？
主要體現在下面兩種類型的問題上。
- 非人為惡意的意外投票過程。非人為惡意篡改可歸類為信鴿半路掛掉、信鴿迷路、信鴿送錯目的地、信鴿送信途中下雨導致信件內容模糊、接收信件的人不在家、天氣變化信鴿延遲送達等等。這些對應到分布式系統面臨的問題就是：消息丟包、網絡擁堵、消息延遲、消息內容校驗失敗、節點宕機等。
- 人為惡意篡改投票過程。人為惡意篡改包括“精神分裂式投票”，中繼篡改上一個村落的投票信息。對應到分布式系統面臨的問題就是：消息被偽造、系統安全攻擊等等。發生的人為惡意篡改的過程就可以稱之為系統發生了拜占庭錯誤（Byzantine Fault)，如果系統可以容忍拜占庭錯誤而不至於崩潰，也就是在發生系統被惡意篡改的情況下仍然可以達成一致，我們將這樣系統稱作為做拜占庭容錯系統。
問題1我們已經有較成熟的方案了。分布式系統本質上是一種並行異步操作，如果通過中心化的手段將系統中的“並行不確定”操作變更為“同步串行”操作就能解決上述的問題。
比如讓第三方機構介入托管所有人的投票；或者構造一個不可偽造令牌，大家輪流將投票統一寫到令牌上。
這些也是現代分布式系統經常使用的方法。但是這些方法有個缺陷，如果在分布式系統中被過多地使用以后，系統便會越來越像單點系統。
我們設計分布式系統的初衷就是為了克服單點系統的可用性不足、擴展性不好、單點性能上限等缺陷，這種退化的方案可能不是我們想要的。
而問題2要求設計拜占庭容錯系統，這個在IT行業並不常見，因為多數IT系統是中心化的，所以如果我們想要解決問題2，這就引出了我們今天要介紹的共識算法與分布式一致性算法。
有關分布式系統的定理
我們在介紹具體的分布式一致性算法之前，先介紹兩個定理，做一下鋪墊。
- 第一個是FLP不可能性，簡單來說是：即使網絡通信完全可靠，只要產生了拜占庭錯誤，就不存在一個確定性的共識算法能夠為異步分布式系統提供一致性。換句話來說就是，不存在一個通用的共識算法可以解決所有的拜占庭錯誤。
- 第二個是CAP定理，CAP定理是分布式系統領域最重要的定理之一，這個我們在“理解區塊鏈的常見誤區”一文中稍微講到過。也就是在設計分布式系統的過程中，“一致性”“可用性”“分區容忍性”三者中，我們只能選擇兩個作為主要強化的點，另外一個必然會被弱化。
我們由CAP定理可以推導出嚴格一致性和最終一致性。嚴格一致性是指在約定的時間內，通常是非常短、高精度的時間內，系統達到一致性的狀態，這種系統很難實現，即使實現也很難有高的性能。
所以人們從工程的角度提出了最終一致性，最終一致性不要求嚴格的短時間內達到一致。為了其他兩個指標，我們相當於讓一致性在時間上做了妥協。區塊鏈滿足了最終一致性，而且處理過程時間比較長。
可用性其實是傳統技術后端架構上非常重要的指標，從單點到主備模式、從主備模式到異地多活，再到現在的Paxos和Raft協議。
我們從軟件架構上也經歷了基於ESB的模塊化SOA模式，到無狀態的微服務架構。從工程的角度來看，根據業務需求達到4個9、6個9就足夠了，只是肯定比不了區塊鏈近乎100%的可用性。
分區容忍性在企業內部極少出現，尤其是中心化的服務性應用，所以很少考慮。然而區塊鏈的P2P網絡環境十分復雜，所以必須要保證很高的分區容忍性。
通過以上我們可以發現比特幣、以太坊等公鏈是偏重高可用性、分區容忍性（AP），滿足最終一致性（C）且TPS較低的分布式系統。
所以如果有人號稱他們的區塊鏈能夠達到媲美中心化系統上萬的TPS，先別着急投資，你問問他們技術是不是知道CAP定理，再問問他們的去中心化程度如何。
這點我們也可以從EOS等高性能的區塊鏈身上佐證，EOS全球只有21個記賬節點，而以太坊全球有上萬個節點可以隨時參與記賬，所以越想去中心化，你的TPS就不可能高，這也就是為什么EOS的TPS高，而以太坊的TPS低。
接下來我來介紹一下經典的分布式一致性算法和區塊鏈的共識算法。經典的分布式一致性算法在多數的論文中一般被叫做共識算法，在這里，我為了與區塊鏈的共識算法做出區別，所以在命名上改成了分布式一致性算法，但是它們要解決的問題是一樣的。
共識算法與分布式一致性算法
1.經典的分布式一致性算法
經典分布式一致性算法有Raft協議，Raft協議是一種強Leader的一致性算法，它的吞吐量基本就是Leader的吞吐量，它無法抵御節點惡意篡改數據的攻擊。
稍微復雜一點的就是Paxos協議，Paxos能提供不同場合不同種類的一致性算法，所以Paxos有很多變種，經典Paxos是Leaderless的，有變種是強Leader型的，叫做Fast Paxos，有關Paxos的文獻非常豐富，這里就不贅述了。
以上兩種都是不提供拜占庭容錯的系統，下面介紹一種具有拜占庭容錯的一致性算法。
PBFT全稱實用性拜占庭容錯系統（Practical Byzantine Fault Tolerance, PBFT)，PBFT是一種狀態機，要求所有節點共同維護一個狀態，所有節點采取的行動一致，PBFT非常適合聯盟鏈等對性能具有較高要求的場合，超級賬本項目中的Fabric框架默認采用的就是PBFT的修改版本。
2.區塊鏈共識算法
區塊鏈的共識算法，我在某些場合直接稱作基於經濟學的博弈算法，以區別於經典分布式一致性算法思路，它的整體思路就是讓攻擊者的攻擊成本遠遠大於收益。
區塊鏈中的共識算法目前具有工業成熟度的是PoW，另外兩種比較成熟的是PoS和DPoS，其次還有一些變種和單一幣種使用的共識算法，例如Ripple共識、PoC共識（概念性證明）、PoE共識（存在性證明）。
在使用PoW共識算法的情況下，容錯閾值是50%，而PBFT及其變種的容錯閾值是33%左右，這里的百分比是指作弊節點占全網節點的比例。
PoX類的算法其實都延續了PoW的設計理念，相比較經典分布式一致性算法，PoX類算法通過概率選擇記賬者降低了潛在的提案者，另外是延長了達成最終一致性的時間。
第一條降低了系統通信復雜度，每次記賬系統的確定性其實是概率確定的，又由於被選中需要付出成本，此處才提高了記賬成本閾值，結合區塊鏈的基礎代幣設計，是一個非常天才的想法。
有關PoW、PoS、DPoS的內容，我在后面會有專文介紹。
總結
今天我們從相親大會開始說起，介紹了分布式系統所面臨的問題，之后，我們又引出了區塊鏈所要解決的拜占庭容錯問題，並重點介紹了分布式系統的基本定理，最后我還介紹了經典共識算法和區塊鏈算法。
區塊鏈並沒有逃離分布式系統這個理論框架，希望今天的內容能夠幫助你分辨出真實的區塊鏈項目。最后給你留一個思考題，區塊鏈行業有哪些公司使用了如PBFT、Paxos這樣的經典共識算法呢？你可以給我留言，我們一起討論。
感謝你的收聽，我們下期再見。