關於共識機制 | 你知道的與不知道的
共識機制 的發展史，代表著 區塊鏈技術 從1.0走向2.0以及更遠的未來。從某種程度上講，對於共識機制的突破與創新，直接決定了區塊鏈未來大規模商業化的應用。
如果將去中心化的區塊鏈技術比作一個生命體，那麼共識機制可以說就是它的生命之源。
什麼是共識機制？
相信每一位對區塊鏈技術有所瞭解的人，都或多或少的瞭解過一個相關的理論——“拜占庭將軍問題”，甚至對於很多人而言，拜占庭將軍問題是很多人瞭解區塊鏈技術原理的“第一扇大門”。
“拜占庭將軍問題”源自著名圖靈獎得主萊斯利·蘭波特在其同名論文中提出的分散式對等網路通訊容錯問題。根據維基百科的解釋，拜占庭將軍問題即：
在分散式計算中，不同的計算機通過通訊交換資訊達成共識，按照同一套協作策略行動。但有時候，系統中的成員計算機可能出錯而傳送錯誤的資訊，用於傳遞資訊的通訊網路也可能導致資訊損壞，使得網路中不同的成員關於全體協作的策略得出不同結論，從而破壞系統一致性。
拜占庭是古代東羅馬帝國的首都，由於當時帝國的國土幅員遼闊，為了達到防禦的目的，因此每個軍隊都分散駐守，將軍與將軍之間只能依靠郵差進行通訊。當戰爭的發生時，所有將軍需要達成一致的共識共同出擊才能取得成功，否則就會失敗。但是軍隊內部可能存在叛徒或間諜，因此將軍們需要一種機制保證所有的將軍都對進攻的時間有一個相同的認識，也就是——即使信使真的有奸細，而且他採用了任何他能想到的措施，其餘忠誠的將軍也可以在不受叛徒的影響下達成一致的協議。
OK區塊鏈工程院認為，這是區塊鏈共識機制產生的根源所在，“共識”就是在一個由多方組成的系統中，在某一個步驟中讓一個系統中所有的節點對一個值達成一致。
也就是說，在區塊鏈系統中，每一個共識機制都需要回答下面的問題（包括但不限於）：
What——下一個區塊應包含哪些交易？
Who——下一個區塊應該由誰來生成？
When——下一個區塊應該何時產生？
Evolution——如何升級共識協議？
Immunity——如何解決交易歷史的競爭問題？
OK區塊鏈工程院認為，共識機制的目標就是找到這些問題的答案，並確保其健壯性以抵制攻擊者試圖獲得網路的控制權。實際上，獲得控制就意味著獲得了單方面審查交易的能力。共識機制也應當能健壯地抵禦攻擊者利用在不同計算機上的資料庫狀態中的臨時不一致性獲取好處。
共識機制可以解什麼問題？
在回答“共識”究竟能解決什麼問題之前，我們必須瞭解兩個在分散式系統中已經被證明的結論：CAP定理和FLP不可能性定理。
CAP定理指的是在一個分散式系統中，在Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性）中，最多隻能實現兩點，不可三者兼得。
其中，一致性代要求在分散式系統中的所有資料，在同一時刻達到同樣的值，也就是說所有節點訪問同一分最新的資料副本；可用性要求，系統中部分節點出現故障以後，系統整體可以正常相應，不被故障節點影響；分割槽容錯性則要求，系統如果不能在時限內達成資料的一致性，就必須在C和A之間做出選擇。
FLP不可能性定理則是指，對於允許節點失效情況下，純粹非同步系統無法確保一致性在有限時間內完成。
OK區塊鏈工程院認為，FLP不可能性定理已經證明，在一個非同步網路中我們永遠也達不成一致。而CAP定理，則讓我們在設計演算法時所有傾向，是使用CP演算法（高一致性演算法），還是AP演算法（高可用演算法）。
共識演算法本身可以描述為在某一個步驟中讓一個系統中所有的節點對一個值達成一致，即使系統中存在故障, 我們也要忽略掉這些故障節點的噪音讓整個系統繼續正確執行, 而問題的難點就在於在一個非同步網路中將這些噪音降到最小。
不得不談的去中心化
至此，我們可以清晰地看到一些區別所在：
在一箇中心化的結構體系中，整個系統的共識可以由中心來決定，各個節點只需要接受中心所下達的“命令”即可，這也是中心化系統運作更加高效的原因所在。而在去中心的體系中，所有參與系統的節點是處於一個平等的地位，當節點之間出現分歧時，就需要依靠設計巧妙的共識機制來使其順利地運轉下去。
因此，共識機制也被很多人稱作是去中心化系統的核心靈魂所在，二者相輔相成、缺一不可。只有在保證去中心化的前提下共識才能保持一致，如果確保共識的節點數量較小或者受到中心化的控制，那麼就很容易被攻擊。
在OK區塊鏈工程院看來，判斷一個協議是不是去中心化，需要看這個協議能不能在全部節點都永久性刪除後，僅依靠一個節點仍然能夠恢復過來正常運作。如同一個菌絲體藉助單細胞就能恢復過來一樣。我們稱之為完全去中心化，但逃脫不了生物學界的一個事實，多細胞生物比單細胞生物更高階，即以損失一定程度的去中心化為代價。
其實，我們在討論一個專案是不是去中心化的時候，有所爭議的往往是此節。比如對於EOS這種DPOS共識機制是否是去中心化的爭論：
提問方問的是系統治理的去中心化程度，而回答者則回答其他兩者的去中心化程度。如此溝通如何達成一致？因此我們有對去中心化分層的必要，並從以下三個層面來理解去中心化：
首先是系統部署的去中心化。在現實世界中，基於docker（一個開源的應用容器引擎）等虛擬技術和運用這些技術的雲端計算平臺，以下三個問題往往很難拆分：
①系統有多少節點組成？
②部署在幾臺物理計算機中？
③分數多少個地區？
但是最終我們想實現系統部署去中心化的目的是一樣的，就是降低同一時間節點崩潰的數量，例如地震、海嘯、雲平臺安全事件等。
其次是系統邏輯去中心化；在系統的執行流程中，這個系統是由一種角色組成？還是多種角色合作組成？或者說，是由一臺完整的單一裝置組成，還是多種不同種類的裝置組裝的小組？舉個例子，針對一個系統，我們在任意一個時刻，將系統分成2份，系統都能完整的獨立執行下去麼？如果以後兩部分又合二為一了，系統還能正常執行麼？
第三，系統治理去中心化；針對一個區塊鏈專案，有兩個重要的許可權控制：系統修改許可權和系統資料許可權。針對系統修改許可權，有多少個人或者組織，對組成系統的計算機擁有最終的控制權？針對系統資料許可權，許可權控制是否虧歸屬於每個個體？有多少涉及管理，檢視非自身資料的許可權？以及如何制定權利邊界？
其實，我們不僅需要對區塊鏈的去中心化進行分層理解，更重要的是，目前區塊鏈技術已經發展到了2019年，從某種程度上講，單純用“中心化”和“去中心化”無法準確的描述我們目前所用到的方案。
更多區塊鏈資訊：www.qukuaiwang.com.cn/news
宣告：登載此文出於傳遞更多資訊之目的，並不意味著贊同其觀點或證實其描述。