區塊鏈中的共識機制分析與對比

做者：鄭翊

目錄

1. 什麼是共識機制
2. 拜占庭將軍問題
3. CAP原理
   1. 定義
   2. 應用
4. 拜占庭問題的常規解法
   1. 口頭協議
   2. 書面協議
   3. PBFT
5. 比特幣中對於拜占庭問題的解法
   1. PoW
      1. Bitcoin
      2. Ethereum
   2. PoS
      1. Peercoin PoS v1
      2. Blackcoin PoS v2
      3. Blackcoin & Qtum PoS v3
      4. Ethereum Casper
   3. Delegated Methods
      1. EOS DPOS
      2. NEO DBFT
6. 非拜占庭問題下的解法
   1. Paxos
   2. Raft
7. 總結
8. 參考資料

什麼是共識機制

區塊鏈從本質上而言是一種分佈式帳本技術。傳統的帳本，一般會以數據庫的形式，集中存儲在銀行或公司的服務器節點上。而在區塊鏈的網絡中，每一個節點都會保有一份完整的帳本，且全部節點的帳本內容徹底一致。每一個節點均可以根據本身本地的帳本去查找交易，也能夠往帳本中添加交易。

這樣就帶來了一個問題，若是全部節點同時一塊兒寫入帳本數據，那麼確定數據會不一致。所以須要一種機制來保證區塊鏈中的每一區塊只能由一個節點來負責寫入，而且讓全部其餘節點一致認同此次寫入。如何選出寫入帳本數據的節點，這就是共識機制。

拜占庭將軍問題

拜占庭將軍問題[1][2]（Byzantine Generals Problem）是對上述場景的一種建模。拜占庭將軍問題是一個共識問題: 首先由Leslie Lamport與另外兩人在1982年提出，被稱爲The Byzantine Generals Problem或者Byzantine Failure。核心描述是軍中可能有叛徒，卻要保證進攻一致，由此引伸到計算領域，發展成了一種容錯理論，即拜占庭容錯（BFT，Byzantine Fault Tolerance）。

拜占庭將軍問題能夠描述以下：

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

解決問題的難點在於，將軍中可能出現叛徒，叛徒能夠經過選擇性地發送消息，從而達到混淆進攻決策的目的。假設有9位將軍投票，其中1名叛徒。8名忠誠的將軍中出現了4人投進攻，4人投撤離的狀況。這時候叛徒可能故意給4名投進攻的將領送信表示投票進攻，而給4名投撤離的將領送信表示投撤離。這樣一來在4名投進攻的將領看來，投票結果是5人投進攻，從而發起進攻；而在4名投撤離的將軍看來則是5人投撤離。這樣各支軍隊的一致協同就遭到了破壞。

拜占庭將軍問題對應到分佈式系統中，能夠表述爲分佈式的節點間須要對某一個message達成共識（只要過半數節點認同這個message便可）。節點之間能夠交換信息，可是因爲惡意節點的存在，惡意節點會發布錯誤的消息，或是給不一樣的節點發送不一樣的消息。在這樣的場景下，怎樣設計一種機制去讓節點可以達成共識的問題。

拜占庭問題的傳統解法

口頭協議

首先明確口頭協議的定義。咱們將知足如下三個條件的方式稱爲口頭協議：

1. 每一個被髮送的消息都可以被正確的投遞
2. 信息接收者知道是誰發送的消息
3. 可以知道缺乏的消息

Lamport論證得出結論：將軍之間採用口頭協議進行通訊，若叛徒數少於1/3，則拜占庭將軍問題可解。也就是說，若叛徒數爲m，當將軍總數n至少爲3m+1時，問題可解。本文中再也不詳細介紹通訊機制和論證過程，有興趣的讀者能夠查閱文章[1]中「口頭協議」一節和[2]中的「Early solutions」下的第一種。

書面協議

在口頭協議上加上一個條件，使之成爲書面協議

1. 發送者對消息加上簽名，簽名不可僞造，一旦被篡改便可發現，而叛徒的簽名可被其餘叛徒僞造；
2. 任何人均可以驗證簽名的可靠性。

能夠論證，在將軍之間使用書面協議通訊的基礎上，無論將軍總數n和叛徒數量m，忠誠的將軍總能達到一致。書面協議的本質就是引入了簽名系統，這使得全部消息均可以追溯到底有誰認同了它。這一優點，大大節省了成本，他化解了口頭協議中1/3要求，只要採用了書面協議，忠誠的將軍就能夠達到一致。即惡意的節點不超過半數，分佈式系統就能達成共識。對推導細節感興趣的讀者能夠一樣參照[1][2]。

PBFT

實用拜占庭容錯協議（PBFT，Practical Byzantine Fault Tolerance）是Miguel Castro (卡斯特羅)和Barbara Liskov（利斯科夫）在1999年提出來的，解決了原始拜占庭容錯算法（即上文中的口頭協議）效率不高的問題，將算法複雜度由指數級下降到多項式級，使得拜占庭容錯算法在實際系統應用中變得可行。

PBFT算法的結論是n>=3f+1 n是系統中的總節點數，f是容許出現故障的節點數。換句話說，若是這個系統容許出現f個故障，那麼這個系統必須包括n個節點，才能解決故障。這和上文口頭協議的結論同樣，或者這麼說，PBFT是優化了口頭協議機制的效率，可是結論並未改變。

PBFT算法的步驟，詳見[1][3]

1. 取一個副本做爲主節點（圖中0），其餘的副本做爲備份；
2. 用戶（圖中C）向主節點發送消息請求；
3. 主節點經過廣播將請求發送給其餘節點（圖中一、二、3）；
4. 全部節點執行請求並將結果發回用戶端；
5. 用戶端須要等待f+1個不一樣副本節點發回相同的結果，便可做爲整個操做的最終結果。

CAP原理

爲了便於理解比特幣中對於拜占庭問題的解法（PoW、PoS等），先看一下著名的CAP原理[4]，對於共識算法的設計有指導意義。CAP 原理最先由 Eric Brewer 在 2000 年，ACM 組織的一個研討會上提出猜測，後來 Lynch 等人進行了證實。該原理被認爲是分佈式系統領域的重要原理。

定義

分佈式計算系統不可能同時確保一致性（Consistency）、可用性（Availability）和分區容忍性（Partition），設計中每每須要弱化對某個特性的保證。

• 數據一致性(Consistency)：若是系統對一個寫操做返回成功，那麼以後的讀請求都必須讀到這個新數據；若是返回失敗，那麼全部讀操做都不能讀到這個數據，對調用者而言數據具備強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)
• 服務可用性(Availability)：全部讀寫請求在必定時間內獲得響應，可終止、不會一直等待
• 分區容錯性(Partition-tolerance)：在網絡分區的狀況下，被分隔的節點仍能正常對外服務

在某時刻若是知足AP，分隔的節點同時對外服務但不能相互通訊，將致使狀態不一致，即不能知足C；若是知足CP，網絡分區的狀況下爲達成C，請求只能一直等待，即不知足A；若是要知足CA，在必定時間內要達到節點狀態一致，要求不能出現網絡分區，則不能知足P。C、A、P三者最多隻能知足其中兩個。

分區容錯性

這裏重點講一下對分區容錯性的理解，便於你們理解CAP。Partition字面意思是網絡分區，即因網絡因素將系統分隔爲多個單獨的部分，有人可能會說，網絡分區的狀況發生機率很是小啊，是否是不用考慮P，保證CA就好。要理解P，咱們看回CAP證實中P的定義：

In order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another.

網絡分區的狀況符合該定義，網絡丟包的狀況也符合以上定義，另外節點宕機，其餘節點發往宕機節點的包也將丟失，這種狀況一樣符合定義。現實狀況下咱們面對的是一個不可靠的網絡、有必定機率宕機的設備，這兩個因素都會致使Partition，於是分佈式系統實現中P是一個必須項，而不是可選項。

弱化一致性

對結果一致性不敏感的應用，能夠容許在新版本上線後過一段時間才更新成功，期間不保證一致性。

例如網站的CSS、JS等，一般都設置了必定的緩存時間。超過緩存時間纔會從新去服務器獲取最新的版本。

弱化可用性

對結果一致性很敏感的應用，特別是交易相關的應用場景，一般會用到鎖、事務等概念。

例如銀行取款機，當系統故障時候會拒絕服務。Paxos、Raft 等算法，主要處理這種狀況。

弱化分區容忍性

現實中，網絡分區出現機率減少，但較難避免。某些關係型數據庫、ZooKeeper 即爲此設計。一旦有部分節點網絡通訊出現故障，則暫停這部分節點，再也不提供對外服務。

比特幣中對於拜占庭問題的解法

拜占庭問題之因此難解，在於任什麼時候候系統中均可能存在多個提案（由於提案成本很低），而且要完成最終的一致性確認過程十分困難，容易受干擾。可是一旦確認，即爲最終確認。

比特幣的區塊鏈網絡在設計時提出了創新的 PoW（Proof of Work） 算法思路。一個是限制一段時間內整個網絡中出現提案的個數（增長提案成本），另一個是放寬對一致性確認的需求，約定好你們都確認並沿着已知最長的鏈進行拓寬。系統的最終確認是機率意義上的存在。這樣，即使有人試圖惡意破壞，也會付出很大的經濟代價（付出超過系統一半的算力）。

或者通俗來講，比特幣的PoW共識弱化了拜占庭問題中對於一致性的要求，在同一時刻訪問不一樣比特幣的節點，所獲得的共識並不一致，且一致性還會隨着時間改變（分叉的狀況）。可是可用性和分支容錯性都獲得了提高。

後來的各類 PoX 系列算法，也都是沿着這個思路進行改進，採用經濟上的懲罰來制約破壞者。

PoW

Bitcoin

Bitcoin的共識協議，能夠參照Mastering Bitcoin[5]中有詳細的描述。其步驟以下：

1. 本地維持全部未被確認的交易，稱之爲交易池，每新接收到一筆交易就加入到交易池中
2. 本地維持整個區塊鏈，每新接收到一個block，則加入到區塊鏈中，並根據最長鏈原則肯定主鏈
3. 當新接收到的block加入到區塊鏈的時候，開始挖礦
   1. 構建一個空的block，選取交易池中費率最高的交易填充block，費率的定義爲 交易費/交易大小
   2. 根據主鏈，填充block header中的previous block hash字段
   3. 根據block中全部交易的交易費和挖礦獎勵，構建coin base交易。挖礦獎勵大約 每四年（或準確說是每210,000個塊）減小一半，開始時爲2009年1月每一個區塊獎勵50個比特幣
   4. 修改block header中的nonce, timestamp, merkle root(經過修改coinbase data)，讓hash(block header) < difficulty，其中difficulty是根據近期block的產出時間來計算的，保證每一個block產出的時間大體是10分鐘左右
   5. 因爲知足hash要求的block head只能經過大量遍歷得到，因此挖礦的過程須要消耗大量的算力，直到獲得合適的字段取值爲止
   6. 發佈獲得的block，其餘節點驗證經過後加入區塊鏈中

2010 年左右，挖礦仍是一個頗有前途的行業。可是如今，建議仍是不要考慮了，由於從機率上說，因爲當前參與挖礦的計算力實在過於龐大（已經超出了大部分的超算中心），得到比特幣的收益已經眼看要 cover 不住電費了。

從普通的 CPU（2009 年）、到後來的 GPU（2010 年） 和 FPGA（2011 年底）、到後來的 ASIC 礦機（2013 年初，目前單片算力已達每秒數百億次 Hash 計算）、再到如今衆多礦機聯合組成礦池。短短數年間，比特幣礦機的技術走完了過去幾十年的集成電路技術進化歷程，而且還很有創新之處。

Ethereum

因爲ASIC礦機被大量運用在比特幣的挖礦過程當中，因此若是出現其餘基於hash運算達到共識的區塊鏈，則很容易受到本來服務於比特幣的ASIC礦機攻擊。所以Ethereum在設計其PoW共識算法的時候，就意識到應該讓算法在普通的我的電腦上運行更有優點，從而避免被ASIC進行攻擊。

Ethash設計時就明確兩大目標：

1. 抵禦礦機性能（ASIC-resistance），團隊但願CPU也能參與挖礦得到收益。
2. 輕客戶端可快速驗證（Light client verifiability）。

基於以上兩個目標，開發團隊最後倒騰出來的Ethash挖礦時基本與CPU性能無關，卻和內存大小和內存帶寬成正相關。不過在實現上仍是借鑑了SHA3的設計思路，可是使用的」SHA3_256」 ,」SHA3_512」與標準實現很不一樣。

Ethash基本流程是這樣的[6]：對於每個塊，首先計算一個種子（seed），該種子只和當前塊的信息有關；而後根據種子生成一個32M的隨機數據集（Cache）；緊接着根據Cache生成一個1GB大小的數據集合（DAG），DAG能夠理解爲一個完整的搜索空間，挖礦的過程就是從DAG中隨機選擇元素（相似於比特幣挖礦中查找合適Nonce）再進行哈希運算。能夠從Cache快速計算DAG指定位置的元素，進而哈希驗證。此外還要求對Cache和DAG進行週期性更新，每1000個塊更新一次，而且規定DAG的大小隨着時間推移線性增加，從1G開始，每一年大約增加7G左右。

PoS

能夠看到，PoW會存在兩點問題：

1. 費電。不管是比特幣的共識仍是以太坊的Ethash，挖礦的過程當中都帶來了巨大的電力消耗。網上有報道稱，如今每挖一個比特幣的成本在6000-8000美圓之間；比特幣如今天天消耗的電量至關於一個小國家的耗電量。
2. 礦池的優點。隨着算力的不斷提高，單個礦機挖出一枚幣的機率降到了極低。所以，不少礦機的擁有者聯合在了一塊兒造成礦池。礦池中的礦機並行地分擔計算量，當挖出新的block得到獎勵後，再根據計算量的貢獻分享獎勵。礦池的出現致使了比特幣的中心化。從下圖中能夠看出，65%的算力集中在了5大礦池的手裏。若是這些礦池對比特幣網絡進行攻擊，則網絡會面臨較大的風險。

所以，業內提出了PoS（Proof of Stake）[7]的思想：

1. 把生產block的工做交給擁有更多token的人，擁有的越多，做爲block producer的機率越高
2. 生產block的過程當中獲得token獎勵，能夠理解爲持有token帶來的利息
3. 擁有大量token的人若是攻擊網絡，則會形成token價格的降低，對這些人是不利的，因此這些block producer攻擊網絡的意願較低
4. 生產block只需證實本身持有的token便可，不須要消耗多少算力，節約能源

圍繞以上PoS的思想，各個區塊鏈系統有不一樣的PoS實現，如下將依次介紹

Peercoin PoS v1

最初的一版PoS由Peercoin設計實現[8]。其中，用戶要產出block必須知足如下條件

hash(stake_modifier, current_time, UTXO) < coin(UTXO) * age(UTXO) * difficulty
複製代碼

具體解釋以下

1. 用戶在每一秒時間（current_time），遍歷本身全部的UTXO，代入上述公式中，看是否能知足不等式條件；若是知足，就把相應的UTXO記錄在block中，併發布block（見4）
2. stake_modifier是對前一個block中部分字段hash後的值，加入這一項是爲了防止用戶提早預知本身什麼時候有權挖礦
3. difficulty會根據近期的block產出時間動態調整，保證block產出時間間隔穩定
4. 因爲每秒只須要完成和本身UTXO數量相等的hash計算，因此須要的算力較低
5. 從不等式能夠看出，持有的UTXO越多、UTXO中token數額越大（coin(UTXO)）、UTXO持有時間越長（age(UTXO)，或稱之爲幣齡），不等式越容易成立，越容易進行挖礦
6. 生成block的獎勵設置爲了coin(UTXO) * age(UTXO)，即UTXO數額越大持有時間越長，獎勵越高
7. 爲了將符合條件的UTXO記錄進block，而且兼容本來的PoW模式，Peercoin設計了coinstake的邏輯
   1. 保留本來第一個transaction爲coinbase，但要求輸入數量必須等於1，且輸入的prevout字段必須置空值，輸出數量必須大於等於1
   2. 令第二個transaction爲coinstake，要求輸入數量大於等於1，且第一個輸入爲知足條件的UTXO，輸出數量大於等於2，且第一個輸出必須置空值，第二個輸出爲block獎勵

該版本的PoS面臨着以下的問題

1. 由於構造新的block沒有算力成本，因此當區塊鏈出現fork的時候，用戶有可能會傾向於同時在多個branch一塊兒挖礦來得到潛在更高的收益，這樣製造了大量的分支，破壞了一致性。這個問題屢次被以太坊團隊說起，並稱之爲nothing at stake問題[12]，以太坊在其PoS方案CASPER中致力於解決該問題，下文Ethereum Casper一節中將詳細描述
2. 出現了攢幣齡的現象，即關閉節點，直到age(UTXO)足夠大的時候再啓動節點挖礦，從而節省電力，這樣引發了在線節點數太少系統脆弱的問題
3. 能夠攢夠足夠的幣齡後，保證本身有足夠的UTXO可以連續生產block，從而發動double-spend攻擊

Blackcoin PoS v2

Blackcoin在Peercoin的基礎上進行了修改，從而緩解了上述問題，主要改動以下，所有改動參見[9]

1. 去掉了不等式公式右邊的age(UTXO)，從而解決了問題3中攢幣齡而後進行double-spend的現象；可是block獎勵仍是使用了幣齡，所以並不能徹底解決問題2中節點關閉的現象
2. 優化了stake_modifier的計算邏輯，讓用戶提早預知本身有權挖礦時間的難度更大了

Blackcoin & Qtum PoS v3

Blackcoin又在v2的基礎上改進獲得了v3[10]，而後Qtum對v3又進行了修改並應用[11]。主要改動點描述以下，所有改動請參照[10][11]

1. 把block獎勵改爲固定值，解決了問題2
2. 規定500個block以前的UTXO才能參與挖礦，緩解挖礦過於頻繁帶來的潛在風險

Ethereum Casper

Ethereum在其白皮書中承諾最終將從PoW過渡到PoC，而且其PoC的方案，名叫CASPER[12]，正在積極開發中。CASPER一個主要改進點是其將致力於解決nothing at stake問題，主要的方式是懲罰在多個分支上同時進行挖礦的用戶，甚至讓這些用戶失去用於stake的那部分token。其方案描述以下：

1. 用戶質押本身的一部分token進入智能合約，而後開始挖礦
2. 若是成功挖到block並被網絡接受，則用戶得到獎勵
3. 若是用戶被系統發現試圖進行nothing at stake行爲，則其質押的token將被銷燬

但對於nothing at stake問題，業界一直是有爭議的[13]。主要觀點就是執行這種攻擊的代價過高，並且對攻擊者是毫無收益的。這和PoW的前提假設同樣，擁有大量礦機的人能夠對比特幣發動double-spend等攻擊，可是這樣的攻擊對其並沒有收益，且會損失大量算力，因此這種攻擊並無大量發生。

Delegated Methods

以上的PoW和PoS的挖礦過程，是全網全部節點共同參與的，每一時刻都有成千上萬個節點同時去爭取產出下一個block，所以會時有發生區塊鏈分叉（fork）的問題。即同一時刻，兩個節點同時產出了next block，但因爲網絡時延的問題，block產出的時候兩個節點並不知道有其餘節點已經產出了另外一個block，所以這兩個block都被髮布到了網絡中。[5]中對分叉的問題有詳細的描述，能夠進行參考。

正是因爲分叉的存在，block的產出時間間隔不能過短。各區塊鏈經過動態調整的挖礦難度，將block時間間隔穩定在本身指望的水平。例如最初比特幣的間隔是10分鐘，後續的以太坊是15秒左右。若是時間間隔進一步調短（即下降挖礦難度），分叉問題就會大量顯現，不利於共識的達成和系統的穩定。

block產出時間過長致使了兩個問題：

1. 交易確認所需的時間過長。一般來講，一筆交易進入區塊鏈後，都建議通過6個block以後才真正確認交易，由於6個block以後想要再分叉而且追趕主鏈的難度已經超乎想象了。所以，在區塊鏈上確認交易須要分鐘級別的時間。
2. TPS (Transactions Per Second) 受到制約。TPS受到了block generation time和max block size的共同制約。其中max block size的存在是爲了防止DOS攻擊等因素[14]，有必定的天花板，於是縮減block generation time相當重要

爲了縮短block產出時間，delegated開頭命名的系列方法被提了出來。其基本思想就是，選出少許的表明來負責生產block。這樣即便縮短block的時間間隔，也不會有嚴重的分叉發生。甚至可使用PBFT這種沒有分叉的方法來達成表明之間的一致共識。

EOS DPOS

EOS提出的DPOS方案[15]，其步驟簡述以下

1. 持有token的用戶能夠對候選的block producer進行投票；雖然沒有看到對投票過程的詳細設計，可是相關文章中提到了一種可選的方法，即用戶在生成交易的時候，把本身的投票包含在交易中
2. 得票最高的n個用戶被選爲表明，在下一個週期中負責產出block，目前n=21
3. 打亂表明的順序後，各表明開始依次生產block。每一個表明都有本身固定的時間區間，須要在本身的區間中完成block的生產發佈。目前這個區間是3秒，即在正常狀況下每3秒產出一個block
4. 每一個表明在生產block的時候，須要找當時惟一的最長鏈進行生產，不能在其餘分支上進行生產
5. EOS論證了在這種機制下，只要n>=3f+1（n是系統中的總節點數，f是容許出現的惡意節點數），則共識可以達成

經過上述方法，EOS保證了較短的block生產時間（3秒），且由於給每一個生產者設置了固定的時間區間，則block的產出不會由於某個候選節點的延遲而延遲。EOS的文章中詳細論述了各類節點異常狀況下的共識達成，有興趣能夠參考。

NEO DBFT

NEO的共識機制也是先選表明，和EOS的不一樣之處在於，表明之間是按照PBFT的方式達成共識的。因爲上文中已經描述了PBFT算法，因此這裏就再也不解釋DBFT的原理了，有興趣的讀者能夠參照[16]

非拜占庭問題下的解法

以上的算法都是在拜占庭問題建模下的共識算法，如下將介紹「非拜占庭問題」。在拜占庭問題中，咱們認爲每一個節點是能夠進行惡意的攻擊的，即節點在傳遞消息的過程當中，能夠給不一樣節點傳遞不一樣的消息，從而破壞共識。這種場景是符合開放的網絡環境的。

而在較爲封閉的網絡環境中，好比咱們常說的私有鏈，或是公司內部的一些分佈式系統中，每一個節點是可信的，不會存在惡意的攻擊者。節點在傳遞消息的過程當中，只會由於網絡不穩定或是節點掛掉出現漏傳、重傳消息的情形。所以，有一類算法是用於解決在這種場景下的共識問題，所以咱們稱這種場景建模爲非拜占庭問題。

Paxos

早在1990年，Leslie Lamport（即 LaTeX 中的"La"，微軟研究院科學家，得到2013年圖靈獎）向ACM Transactions on Computer Systems (TOCS)提交了關於Paxos算法的論文The Part-Time Parliament。幾位審閱人表示，雖然論文沒什麼特別的用處，但仍是有點意思，只是要把Paxos相關的故事背景所有刪掉。Leslie Lamport心高氣傲，以爲審閱人沒有絲毫的幽默感，因而撤回文章再也不發表。直到1998年，用戶開始支持Paxos，Leslie Lamport從新發表文章，但相比1990年的版本，文章沒有太大的修改，因此仍是很差理解。因而在2001年，爲了通俗性，Leslie Lamport簡化文章發表了Paxos Made Simple，此次文中沒有一個公式。

但事實如何？你們不妨讀一讀Paxos Made Simple。Leslie Lamport在文中漸進式地、從零開始推導出了Paxos協議，中間用數學概括法進行了證實。多是由於表述順序的問題，致使這篇文章彷佛仍是很差理解。因此這裏我摘錄了一篇對Paxos描述的中文文檔[17]，供參考。

想要看懂Paxos中共識達成的機制較爲簡單，其基原本說就是一個二次確認的過程。

1. 首先由用戶向網絡中全部節點發出提議n，n是提議的編號
2. 節點收到提議n後
   1. 若編號n比以前接受的提議請求都要大，則承諾將不會接收提議編號比n小的提議，而且帶上以前接受的提議中編號小於n的最大的提議{n0, v0}，n0是編號，v0是內容（若是以前沒接受過提議則返回空的消息）
   2. 不然不予理會
3. 用戶獲得了多數節點的承諾後
   1. 若是發現承諾的節點返回的都是空，則向全部節點發送本身本次提議的{n, v}，讓你們接受
   2. 不然，從全部節點返回中選擇n0最大的v0，做爲提議的值，提議編號仍然爲n，即向全部節點發送{n, v0}讓你們接受
4. 節點接收到提議後，若是該提議編號不違反本身作過的承諾，則接受該提議。

Paxos證實了在這種機制下，只要掛掉的節點小於半數，則能實現系統的共識。

Raft

Paxos協議是第一個被證實的一致性算法，可是Paxos的論文很是難懂，致使基於Paxos的工程實踐和教學都十分頭疼，因而Raft在設計的過程當中，就從可理解性出發，使用算法分解和減小狀態等手段，目前已經應用很是普遍。能夠這麼理解，Raft改進了Paxos的機制，便於理解和在實際場景中編程實現。

Raft的詳細描述能夠參照[18]，因爲篇幅所限本文就不詳細介紹了。

總結

本文的目的是列舉目前區塊鏈系統中，已經應用的主流共識機制，並附帶介紹了Paxos和Raft這兩種非拜占庭問題下的共識算法，便於對全部共識算法有更好的理解。因爲所涉及的算法較多，因此本文並未對算法的細節進行特別詳細的描述，而是羅列了相關的參考文獻，便於讀者更加詳細地去了解算法細節。

本文的主要貢獻是描述了各個算法的設計思路、使用場景，也許可使讀者瞭解每一個算法是怎麼想出來的以及怎麼使用。另外，本文還對比了算法之間的優缺點，便於讀者去了解算法的不一樣。

還有一些正在測試中或是開發中的共識機制，將在後續文章中進一步闡述。

參考資料

[1] 拜占庭共識機制

[2] Byzantine fault tolerance

[3] 實用拜占庭容錯算法PBFT

[4] 分佈式系統理論基礎 - CAP

[5] 精通比特幣（第二版）——挖礦和共識

[6] Ethash

[7] Cryptocurrencies without Proof of Work

[8] PPC:一種P2P（點對點）的權益證實(Proof of Stake)密碼學貨幣

[9] BlackCoin's Proof-of-Stake Protocol v2

[10] Security Analysis of Proof-of-Stake Protocol v3.0

[11] The missing explanation of Proof of Stake Version 3

[12] Proof of Stake FAQ

[13] Qtum's PoS vs CASPER (and the nothing-at-stake problem)

[14] Block size limit controversy

[15] EOS.IO Technical White Paper

[16] NEO共識機制

[17] 微信PaxosStore：深刻淺出Paxos算法協議

[18] Raft一致性算法筆記