共識機制的發(fā)展史，代表著區(qū)塊鏈技術(shù)從1.0走向2.0以及更遠的未來。從某種程度上講，對于共識機制的突破與創(chuàng)新，直接決定了區(qū)塊鏈未來大規(guī)模商業(yè)化的應(yīng)用。

如果將去中心化的區(qū)塊鏈技術(shù)比作一個生命體，那么共識機制可以說就是它的生命之源。

什么是共識機制？

相信每一位對區(qū)塊鏈技術(shù)有所了解的人，都或多或少的了解過一個相關(guān)的理論——拜占庭將軍問題”，甚至對于很多人而言，拜占庭將軍問題是很多人了解區(qū)塊鏈技術(shù)原理的第一扇大門”。

拜占庭將軍問題”源自著名圖靈獎得主萊斯利·蘭波特在其同名論文中提出的分布式對等網(wǎng)絡(luò)通信容錯問題。根據(jù)維基百科的解釋，拜占庭將軍問題即：

在分布式計算中，不同的計算機通過通訊交換信息達成共識，按照同一套協(xié)作策略行動。但有時候，系統(tǒng)中的成員計算機可能出錯而發(fā)送錯誤的信息，用于傳遞信息的通訊網(wǎng)絡(luò)也可能導(dǎo)致信息損壞，使得網(wǎng)絡(luò)中不同的成員關(guān)于全體協(xié)作的策略得出不同結(jié)論，從而破壞系統(tǒng)一致性。

拜占庭是古代東羅馬帝國的首都，由于當(dāng)時帝國的國土幅員遼闊，為了達到防御的目的，因此每個軍隊都分散駐守，將軍與將軍之間只能依靠郵差進行通信。當(dāng)戰(zhàn)爭的發(fā)生時，所有將軍需要達成一致的共識共同出擊才能取得成功，否則就會失敗。但是軍隊內(nèi)部可能存在叛徒或間諜，因此將軍們需要一種機制保證所有的將軍都對進攻的時間有一個相同的認識，也就是——即使信使真的有奸細，而且他采用了任何他能想到的措施，其余忠誠的將軍也可以在不受叛徒的影響下達成一致的協(xié)議。

OK區(qū)塊鏈工程院認為，這是區(qū)塊鏈共識機制產(chǎn)生的根源所在，共識”就是在一個由多方組成的系統(tǒng)中，在某一個步驟中讓一個系統(tǒng)中所有的節(jié)點對一個值達成一致。

也就是說，在區(qū)塊鏈系統(tǒng)中，每一個共識機制都需要回答下面的問題（包括但不限于）：

What——下一個區(qū)塊應(yīng)包含哪些交易？

Who——下一個區(qū)塊應(yīng)該由誰來生成？

When——下一個區(qū)塊應(yīng)該何時產(chǎn)生？

Evolution——如何升級共識協(xié)議？

Immunity——如何解決交易歷史的競爭問題？

OK區(qū)塊鏈工程院認為，共識機制的目標(biāo)就是找到這些問題的答案，并確保其健壯性以抵制攻擊者試圖獲得網(wǎng)絡(luò)的控制權(quán)。實際上，獲得控制就意味著獲得了單方面審查交易的能力。共識機制也應(yīng)當(dāng)能健壯地抵御攻擊者利用在不同計算機上的數(shù)據(jù)庫狀態(tài)中的臨時不一致性獲取好處。

共識機制可以解什么問題？

在回答共識”究竟能解決什么問題之前，我們必須了解兩個在分布式系統(tǒng)中已經(jīng)被證明的結(jié)論：CAP定理和FLP不可能性定理。

CAP定理指的是在一個分布式系統(tǒng)中，在Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯性）中，最多只能實現(xiàn)兩點，不可三者兼得。

其中，一致性代要求在分布式系統(tǒng)中的所有數(shù)據(jù)，在同一時刻達到同樣的值，也就是說所有節(jié)點訪問同一分最新的數(shù)據(jù)副本;可用性要求，系統(tǒng)中部分節(jié)點出現(xiàn)故障以后，系統(tǒng)整體可以正常相應(yīng)，不被故障節(jié)點影響;分區(qū)容錯性則要求，系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)的一致性，就必須在C和A之間做出選擇。

FLP不可能性定理則是指，對于允許節(jié)點失效情況下，純粹異步系統(tǒng)無法確保一致性在有限時間內(nèi)完成。

OK區(qū)塊鏈工程院認為，F(xiàn)LP不可能性定理已經(jīng)證明，在一個異步網(wǎng)絡(luò)中我們永遠也達不成一致。而CAP定理，則讓我們在設(shè)計算法時所有傾向，是使用CP算法（高一致性算法），還是AP算法（高可用算法）。

共識算法本身可以描述為在某一個步驟中讓一個系統(tǒng)中所有的節(jié)點對一個值達成一致，即使系統(tǒng)中存在故障, 我們也要忽略掉這些故障節(jié)點的噪音讓整個系統(tǒng)繼續(xù)正確運行, 而問題的難點就在于在一個異步網(wǎng)絡(luò)中將這些噪音降到最小。

不得不談的去中心化

至此，我們可以清晰地看到一些區(qū)別所在：

在一個中心化的結(jié)構(gòu)體系中，整個系統(tǒng)的共識可以由中心來決定，各個節(jié)點只需要接受中心所下達的命令”即可，這也是中心化系統(tǒng)運作更加高效的原因所在。而在去中心的體系中，所有參與系統(tǒng)的節(jié)點是處于一個平等的地位，當(dāng)節(jié)點之間出現(xiàn)分歧時，就需要依靠設(shè)計巧妙的共識機制來使其順利地運轉(zhuǎn)下去。

因此，共識機制也被很多人稱作是去中心化系統(tǒng)的核心靈魂所在，二者相輔相成、缺一不可。只有在保證去中心化的前提下共識才能保持一致，如果確保共識的節(jié)點數(shù)量較小或者受到中心化的控制，那么就很容易被攻擊。

在OK區(qū)塊鏈工程院看來，判斷一個協(xié)議是不是去中心化，需要看這個協(xié)議能不能在全部節(jié)點都永久性刪除后，僅依靠一個節(jié)點仍然能夠恢復(fù)過來正常運作。如同一個菌絲體借助單細胞就能恢復(fù)過來一樣。我們稱之為完全去中心化，但逃脫不了生物學(xué)界的一個事實，多細胞生物比單細胞生物更高級，即以損失一定程度的去中心化為代價。

其實，我們在討論一個項目是不是去中心化的時候，有所爭議的往往是此節(jié)。比如對于EOS這種DPOS共識機制是否是去中心化的爭論：

提問方問的是系統(tǒng)治理的去中心化程度，而回答者則回答其他兩者的去中心化程度。如此溝通如何達成一致？因此我們有對去中心化分層的必要，并從以下三個層面來理解去中心化：

首先是系統(tǒng)部署的去中心化。在現(xiàn)實世界中，基于docker（一個開源的應(yīng)用容器引擎）等虛擬技術(shù)和運用這些技術(shù)的云計算平臺，以下三個問題往往很難拆分：

①系統(tǒng)有多少節(jié)點組成？

②部署在幾臺物理計算機中？

③分數(shù)多少個地區(qū)？

但是最終我們想實現(xiàn)系統(tǒng)部署去中心化的目的是一樣的，就是降低同一時間節(jié)點崩潰的數(shù)量，例如地震、海嘯、云平臺安全事件等。

其次是系統(tǒng)邏輯去中心化;在系統(tǒng)的運行流程中，這個系統(tǒng)是由一種角色組成？還是多種角色合作組成？或者說，是由一臺完整的單一設(shè)備組成，還是多種不同種類的設(shè)備組裝的小組？舉個例子，針對一個系統(tǒng)，我們在任意一個時刻，將系統(tǒng)分成2份，系統(tǒng)都能完整的獨立運行下去么？如果以后兩部分又合二為一了，系統(tǒng)還能正常運行么？

第三，系統(tǒng)治理去中心化;針對一個區(qū)塊鏈項目，有兩個重要的權(quán)限控制：系統(tǒng)修改權(quán)限和系統(tǒng)數(shù)據(jù)權(quán)限。針對系統(tǒng)修改權(quán)限，有多少個人或者組織，對組成系統(tǒng)的計算機擁有最終的控制權(quán)？針對系統(tǒng)數(shù)據(jù)權(quán)限，權(quán)限控制是否虧歸屬于每個個體？有多少涉及管理，查看非自身數(shù)據(jù)的權(quán)限？以及如何制定權(quán)利邊界？

其實，我們不僅需要對區(qū)塊鏈的去中心化進行分層理解，更重要的是，目前區(qū)塊鏈技術(shù)已經(jīng)發(fā)展到了2019年，從某種程度上講，單純用中心化”和去中心化”無法準(zhǔn)確的描述我們目前所用到的方案。