區塊鏈共識機制介紹

做者：qinyutong、chengyueqiang

共識機制（Consensus Mechanism）是區塊鏈事務達成分佈式共識的算法，隨着區塊鏈這一技術不斷被推廣，共識機制做爲區塊鏈的核心，也越發受到人們的關注。共識機制在保護數據的一致性方面具備重要做用。本文選取了 8 種經常使用的共識機制，根據機制的原理、運行過程當中的角色、算法流程以及優缺點等方面，對工做量證實、權益證實、容量證實等機制進行詳細介紹。同時，文章也對類似的機制進行對比分析。從而加深人們對共識機制的瞭解，加速區塊鏈技術的發展。

1   引言

區塊鏈是比特幣的底層技術，相似於數據庫帳本，而共識機制是去中心化的分佈式帳本中的規則核心，決定了區塊鏈的安全性、可擴展性和去中心化程度等許多重要特性。

共識機制是指以去中心化的方式就網絡的狀態達成統一協議的過程。也被稱爲共識算法，有助於驗證和驗證信息被添加到分類帳簿，確保只有真實的事務記錄在區塊鏈上 [12]。所以，共識機制負責安全地更新分佈式網絡中的數據狀態。已經硬編碼到協議中的規則確保在全球計算機網絡中老是能找到惟一的數據來源並達成一致。這些規則保護整個網絡，實現無需信任的網絡，而無需中央數據或中介。

共識機制是決定按照哪個參與節點記帳，和確保交易安全完成的重要手段。[8] 共識機制須要平衡效率和安全的關係，安全措施越複雜，相應的處理時間越慢。而想要提升處理速度，簡化安全措施的複雜度是很是重要的一步。

共識機制同時知足一致性和有效性。一致性是指全部誠實節點保存的區塊鏈前綴部分徹底相同，而有效性是指由某誠實節點發布的信息終將被其餘全部誠實節點記錄在本身的區塊中 [11]。共識機制確保區塊鏈是容錯的，所以是可靠和一致的。與中心化系統不一樣，用戶沒必要信任系統中的任何人，區塊鏈共識機制中嵌入的協議規則能夠確保只有有效和真實的交易才能夠被記在公共透明的帳簿中，嵌入網絡的協議規則保證了公共分類賬的狀態老是隨着大衆的共識變換而更新。

區塊鏈的去中心化的一個重要優點是分配受權，任何人都能在同一個基礎上參與進來。而共識機制能夠確保區塊鏈不存在區別對待，從而達到公平分配。因爲公共區塊鏈具備開源這一特性，使任何人均可以監督並驗證底層源代碼對網絡中的全部參與者是否公平 [7]。

共識機制能夠經過激勵好的行爲，在某些狀況下，懲罰壞的行爲者來實現這一點。例如在工做量證實這一機制中，經過獎勵比特幣給礦工這一方式，獎勵他們每一筆交易的擔保和驗證。任何運算和安全維護都須要大量的算力和錢財，而共識機制可使這些資源將更好地用於爲系統工做，而不是針對系統。

常見的共識機制有：PoW（工做量證實）、PoS（權益證實）、DPoS（委任權益證實）、PBFT（實用拜占庭容錯算法）、POOL（驗證池）等。

2   PoW：Proof of Work（工做量證實）

2008 年，在比特幣白皮書（Bitcoinswhitepaper）上，PoW 第一次獲得重視。PoW 是依賴機器進行數學運算（與或運算，計算出一個知足規則的隨機數）來得到本次記帳權 [1]，向全網其餘節點發送本次須要記錄的數據，由其餘節點驗證後，達成共識後對數據進行存儲。PoW 最先是一個經濟學名詞，它是指系統爲達到某一目標而設置的度量方法。簡單理解就是一份證實 [3]，用來確認你作過必定量的工做。監測工做的整個過程一般是極爲低效的，而經過對工做的結果進行認證來證實完成了相應的工做量，則是一種很是高效的方式。

舉例說明，10+？=12，誰先解出來答案，誰就收穫。

一句話歸納：乾的越多，收的越多（有且僅有實際勞動，才能得到成果）

​

圖 1: PoW 的工做原理圖示

2.1   名詞解釋

哈希函數 Hash 哈希函數是一個單向加密函數，哈希算法可以獲取任意數量的數據，並返回一個固定長度的字符串 [6]，該字符串對於特定的輸入是徹底惟一的。

Nonce  一個只能使用一次的隨機數。

礦工 Miners  加密貨幣網絡中獨立的交易處理器，其目標是驗證交易。一般也被稱做Full Node或Node。

2.2   角色

工做者 須要完成的工做必須有必定的量，這個量由工做驗證者給出；

工做者沒法找到很快完成工做的辦法；

工做者沒法本身」 創造工做」，必須由驗證者發佈工做。

驗證者 能夠迅速的檢驗工做量是否達標。

2.3   優勢

1. 算法簡單，容易實現。

2. 節點間無需交換額外的信息便可達成共識（節點間自由進出）。

3. 破壞系統須要投入極大的成本。

4. 須要全網全部節點參與，徹底去中心化。

2.4   缺點

1. 目前比特幣已經吸引全球大部分的算力，新的區塊鏈必須找到一種不一樣的散列算法，很難使用與過去相同的算力獲得相同的安全保障。

2. 大量的資源浪費。

3. 共識達成的週期較長，不適合商業應用（容易產生分叉，須要等待多個確認，區塊的確認時間難以縮短）。

4. 永遠沒有最終性，須要檢查點機制來彌補最終性。

2.5   應用實例

比特幣中，使用 PoW 確認區塊的有效性（只要該 CPU 耗費的工做量可以知足該工做量的證實機制，那麼除非從新完成至關的工做量，該區塊的信息就不可更改）

2.6   問題解釋

爲何說 PoW 消耗能源的問題嚴重？

——由於礦工（Miners）的每個猜想（guess）都須要消耗一臺計算機產生必定數量的能量。目前，整個比特幣網絡的哈希率（Hash rate）爲～17，000，000 TH/s，即整個網絡每秒 17,000,000,000,000,000,000 個猜想（guess）。這種能源需求與匈牙利的消費量大體相同。 

3   PoS：Proof of Stake（權益證實）

2012 年，PoS 做爲點點幣（Peercoin）的介紹首次被提出。PoS 是 PoW 的一種升級共識機制，不須要消耗電力來進行運算，根據每一個節點記帳權的得到難度，令其與節點持有的權益成反比，等比例的下降挖礦難度，從而加快找隨機數的速度。爲了保證其簡單，PoS 中沒有礦工（Miners），而是改成了驗證員（Validators）。仍然是基於哈希運算競爭獲取記帳權的方式，容錯性與PoW 相同。PoS 是基於礦工們目前擁有的數字貨幣數量分配，一種根據你持有貨幣的量和時間進行利息分配的制度，在 PoS 模式下，你的「挖礦」收益與你的幣齡成正比，而與電腦的計算性能無關。

舉例說明，PoS 類比成咱們手中的鈔票。當咱們擁有的鈔票越多，那在生活中所得到的權益就越多。一句話歸納：持有越多，得到越多（在銀行存錢得利息）

3.1   名詞解釋

驗證員 Validators 驗證器，要驗證交易，驗證器必須下注必定數量的stake，stake的大小決定了驗證器驗證下一區塊的可能性。

3.2   優勢

1. 在必定程度上縮短了共識達成的時間，轉帳效率提升。

2. 再也不須要大量消耗能源和算力挖礦。

3.3   缺點

1. 仍是須要挖礦，本質上沒有解決商業應用的痛點。

2. 全部的確認都只是一個機率上的表達，而不是一個肯定性的事情，理論上有可能存在其餘攻擊影響。

3. 去中心化程度，容易出現強者恆強的狀況，持幣大戶持幣生息，從而出現壟斷問題。

3.4   問題解釋

PoS 在改善了PoW 消耗能源的問題後，還有哪些問題須要考慮？

——諸多問題中擁有最大爭議的問題是，若是過多的權重被賦予很是多的財富或舊節點，網絡會很快變得不公平。

​

表 1: PoW 和 PoS 的比較

4   DPoS：Delegated Proof of Stake（委任權益證實）

與 PoS 的主要區別在於節點選舉若干代理人，向代理人受權選票後，由代理人驗證和記帳，錢包即爲狀態監視器。其合規監管、性能、資源消耗和容錯性與 PoS 類似。相似於董事會投票，持幣者投出必定數量的節點，由節點選擇代理人，代理他們進行驗證和記帳。

舉例說明，若是持幣者 A 支持了代理人 50 個幣，持幣者 B 支持了代理人 10 個幣，那麼 A 的投票權重是 B 的 5 倍。

一句話歸納：節點選舉若干代理人，由代理人驗證和記帳

4.1   組成部分

1. 選出一組區塊生產者：選舉過程由token 持有者決定，選舉出的生產者的表現會影響到整個網絡的工做狀況，進而影響到 token 持有者的利益。

2. 調度生產

4.2   算法流程（以正常操做和少數分叉爲例）

1. 正常操做：正常狀況下區塊生產者按順序進行生產，間隔時間是3s。沒有人錯失生產，以下即是最長的鏈（箭頭指向前一個區塊）。

​

圖 2: 正常操做

2. 少數分叉：當不超過 1/3 的節點有惡意或不能工做，而產生一個分叉時，以下圖的 B，這條分叉每 8 秒出一個塊，而正常工做的節點每 8 秒出 2 個塊 [13]。緣由是按照 A,B,C,A... 的順序，每一個節點要等待相應時間才能夠出塊。根據最長鏈原則，系統依然能運行。

​

圖 3: 少數分叉

4.3   優勢

1. 大幅縮小參與驗證和記帳節點的數量，能夠達到秒級的共識驗證。

2. 經過同意投票制，能夠確保即便一我的擁有50％的有效投票權，也不能獨自選擇一個出塊人，保證算法安全。

3. 大多數出塊人出現問題時，DPoS 仍能夠繼續工做。

4.4   缺點

1. 整個共識機制仍是依賴於代幣，不少商業應用是不須要代幣存在的。

2. 弱中心化，去中心化程度不高。

4.5   應用實例

EOSIO：EOSIO 由委託證實 (DPoS) 系統維護，該系統最初是由 Larimer 建立的，如今仍被 Steemit 使用。Dan Larimer 第一次在 BitShares 使用 DPOS，它當即成爲最快的區塊鏈之一。後來BM 將 DPOS 引入 Steem，Steem被認爲是最快和最穩定的區塊鏈項目之一，天天處理超過 100 萬交易，而只使用其容量的百分之一。

5   PBFT：Practical ByzantineFault Tolerance（實用拜占庭容錯算法）

PBFT 是一種狀態機副本複製算法，通常包括三種協議：一致性協議 (agreement)、檢查點協議 (checkpoint) 和視圖更換協議 (view change)。在保證活性和安全性（liveness and safety）的前提下提供了 (n-1)/3 的容錯性。在分佈式計算上，不一樣的計算機透過訊息交換，嘗試達成共識；但有時候，系統上協調計算機（Coordinator / Commander）或成員計算機（Member/Lieutanent）可能因系統錯誤並交換錯的訊息，致使影響最終的系統一致性[9]。拜占庭將軍問題就根據有多少錯誤計算機來尋找可能的解決辦法，雖然沒法找到一個絕對答案，但只能夠用來驗證一個機制是否有效。而拜占庭問題的可能解決方法爲：在 N ≥ 3F + 1的狀況下一致性是可能解決。其中，N爲計算機總數，F爲有問題計算機總數。信息在計算機間互相交換後，各計算機列出全部獲得的信息，以大多數的結果做爲解決辦法。

一句話歸納：每一個「將軍」根據內部狀態和新消息結合運行計算或操做，從而達成我的決定，個體將決定共享，根據所有決定肯定共識決定。

5.1   協議

一致性協議至少包含若干個階段：請求（request）、序號分配（pre-prepare）和響應（reply）。根據協議設計的不一樣，可能包含相互交互（prepare），序號確認（commit）等階段。

檢查點協議算法設置週期性的檢查點協議, 將系統中的服務器同步到某一個相同的狀態，系統會設置一個 check-point 的時間點，在這個時刻能夠按期地處理日誌、節約資源並及時糾正服務器狀態。

視圖更換協議某個副本節點 i 檢測出主節點做惡或者下線，會產生超時機制，啓動視圖更換，並將視圖編號 v 變動爲 v+1，同時再也不接受除檢查點消息（checkpoint）、視圖更換消息 (view-change) 和新視圖消息（new-view）外的其餘消息請求。

基於全同態加密的 PSI 全同態加密技術使得對於明文的數學操做能夠直接在密文上進行而不須要先將密文解密。早期的全同態加密十分低效，而它的性能在近幾年纔有所提升。使用全同態加密技術的 PSI 協議，經過擁有較小集合的一方將本身的集合加密之後發送給另外一方，而另外一方負責基於密文求兩個集合的交集，而後將結果交給對方解密。使用全同態加密實現 PSI 能夠達到相對較小的交互複雜度，但它的計算複雜度一般很是高，致使協議效率低下。因此，在不犧牲太多交互複雜度的狀況降低低計算複雜度是基於全同態加密的 PSI 協議主要面臨的挑戰。

5.2   算法流程

1. 客戶端發起消息：客戶端 C 向主節點發送操做請求 <REQUEST,o,t,c>

   o: 請求執行狀態機操做

   t: 客戶端追加的時間戳

   c: 客戶端標誌

   REQUEST: 包含消息內容 m，以及消息摘要 d(m) 等

2. 預準備階段: 在預準備階段，主節點對收到的客戶端請求消息簽名進行驗證，驗證經過，基於當前視圖 v 分配一個序列號 n 給收到的客戶端請求，而後向全部備份節點羣發送預準備消息 < <PRE-PREPARE, v, n , d>, m>

  v：視圖編號m：客戶端發送的請求消息d：請求消息m 的摘要n：預準備消息序號

預準備消息的目的是做爲一種證實，肯定該請求已在視圖v 中被賦予了序號 n，從而在視圖變動的過程當中消息仍可被追溯。

3. 準備階段: 副本節點 i 收到主節點的 PRE-PREPARE 消息，須要進行如下校驗：

•   主節點 PRE-PREPARE 消息簽名是否正確。

•   當前副本節點是否已經收到了一條在同一v 下而且編號也是 n，可是簽名不一樣的PRE-PREPARE 信息。

•   d 與 m 的摘要是否一致。

•   n 是否在區間 [h, H] 內。

校驗經過後，副本節點 i 向全部副本節點發送準備消息 <PREPARE,v, n, d, i>，並將預準備消息和準備消息在節點i 進行保存，用於 View Change 過程當中恢復未完成的請求操做。當節點 i 收到接超過 2f+1 個節點的準備消息後，就能夠進入確認階段。其中會檢查這些消息的視圖編號 v，消息序號 n 和摘要 d。

4. 確認階段：進入確認階段的節點向其餘節點包括主節點發送一條<COMMIT, v, n, d, i> 確認消息。當節點i 接受到 2f+1 個 m 的確認消息後並知足相應條件後，消息m 變動爲 committed-local 狀態，節點執行 m 的請求。在完成 m 請求的操做以後，每一個副本節點都向客戶端發送回覆。進入 reply 階段。

5. 迴應客戶端：節點 i 返回 <REPLY, v, t, c, i, r> 給客戶端，r：請求操做結果。客戶端若是收到f+1 個相同的 REPLY 消息，說明客戶端發起的請求已經達成全網共識，不然客戶端須要判斷是否從新發送請求給主節點。

​

圖 4: 注：副本 0 是主節點，副本 3 是失效節點，C 是客戶端。

5.3   優勢

1. 系統運轉能夠脫離幣的存在，PBFT 算法共識各節點由業務的參與方或者監管方組成，安全性與穩定性由業務相關方保證。

2. 共識的時延大約在 2~5 秒鐘，基本達到商用實時處理的要求。

3. 共識效率高，吞吐量高，可知足高頻交易量的需求。

4. 不使用工做量證實的耗電模式，更加節能環保。

5.4   缺點

1. 受到節點數量的限制以及節點須要選舉或許可，可擴展性及去中心化程度較弱。

2. 容錯性較低，當有 1/3 或以上記帳人中止工做後，系統將沒法提供服務；當有 1/3 或以上記帳人聯合做惡，且其它全部的記帳人被剛好分割爲兩個網絡孤島時，惡意記帳人可使系統出現分叉，可是會留下密碼學證據。

6   POOL（驗證池）

驗證池機制是基於傳統的分佈式一致性技術和數據驗證機制的結合，它使得在成熟的分佈式一致性算法（Paxos、Raft）基礎上，不須要代幣也能實現秒級共識驗證。

6.1   優勢

1. 不須要代幣也能夠工做，在成熟的分佈式一致性算法（Paxos、Raft）基礎上，實現秒級共識驗證。

2. 提升應用程序的運行速度，改善效率並下降開銷。

6.2   缺點

1. 去中心化程度不如比特幣。

2. 更適合多方參與的多中心商業模式。

7   PoC：Proof of Capacity（容量證實）

2015 年，該理念被 Dziembowski 等進行了形式化定義。PoC 經過分配必定數量的內存或磁盤空間用於解決服務提供者所提供挑戰的方式，顯示了某我的對某個服務（例如發送郵件）具備合法的興趣。雖然 Ateniese 等人的論文 名稱也是「Proof-of-space」，但它事實上一種採用 MHF（Memory Hard Function，一種計算代價取決內存的哈希算法）的 PoW 協議。PoC 是使用緩存大量數據的方法來對計算時間進行節省。

舉例說明，將彩票填滿硬盤驅動器，生成一個隨機數，而後檢查匹配數字最多的人。若是你有最匹配的號碼，你就會贏得獎勵。

一句話歸納：儲存空間越大，收的越多（有且僅有實際勞動，才能得到成果）

7.1   名詞解釋

哈希值 Shabal Shabal算法是一種很慢的算法，容許輸入任意長度的有序位序列，甚至是一個空序列。也適應任何長度的字節流，可是因爲考慮到安全性，適用長度最好小於 27位。輸入長度能夠是任何整數值和8的倍數。假如給定一個 bit 序列，按其左右順序索引編號，即第一位的索引爲0。使用左和右來描述有序的位序列：序列中的第一位稱爲最左位，最後一位稱爲最右位。

Plotting 繪圖產生存儲大量預計算哈希值的文件，在存儲器充滿哈希值的文件後，仍能夠參與塊的建立過程。這個過程叫作繪圖。

7.2   算法流程

1. 硬盤驅動器的繪圖：根據硬盤驅動器的大小，製做獨特的繪圖文件可能須要幾天甚至幾周的時間。繪圖時使用被稱爲 Shabal 的很是慢的哈希值。與 SHA-256 哈希值不一樣，Shabal 是比特幣礦商快速使用的哈希值。因爲Shabal 哈希值很難計算，因此咱們必須預先計算它們並將它們存儲在硬盤上。這個過程稱爲繪製硬盤驅動器。

2. 塊的實際挖礦：計算 0 到 4085 之間的剷鬥數。假設你的計算結果是42。而後你會去舀 42 勺nonce 1 而後用舀的數據來計算一段時間，這叫作截止時間[5]。對硬盤上的全部 nonces 重複此過程。在計算完全部的截止日期後，你會選擇最小的截止日期。截止日期表示「在容許您僞造一個塊以前，自最後一個塊被僞造以來必須通過的秒數」。若是在這段時間內沒有其餘人鍛造了一個塊，你能夠鍛造一個塊並得到一個塊獎勵。

​

圖 5: PoC 的工做過程圖示

7.3   優勢

1. 你可使用任何普通硬盤，這樣其餘礦商就不會從購買專門設備中得到優點，好比用 ASIC 挖礦比特幣。

2. 使用硬盤驅動器的能源效率是基於ASIC 的採礦的 30 倍。

3. 容量證實更加分散，由於每一個人都有一個硬盤驅動器。你甚至能夠從你的 Android 手機的硬盤上進行挖礦。

4. 礦商不須要不斷升級設備。舊硬盤能夠像新硬盤同樣存儲數據。

5. 完成挖礦後能夠清除硬盤驅動器，並將其用於最初的目的。

7.4   缺點

1.  產能開採的廣泛證據可能會致使另外一場軍備競賽。今天人們使用tb 的硬盤，可是咱們最終會看到 pb、exabytes 和 zettabytes。

2. 容量證實是一項相對較新的技術，在現實世界中沒有通過嚴格的測試和挑戰。

3. 目前，硬盤驅動器繪製的數據除了挖礦用途外是無用的。然而，有計劃將硬盤用做重要開源信息的冗餘存儲。硬盤能夠存儲地圖、維基百科文章或其餘值得保存的信息。

4. 已經有惡意軟件在人們的電腦上挖礦比特幣。若是容量證實變得流行起來，你可能會看到惡意軟件在密謀人們的硬盤。

7.5   問題解釋

爲何說 PoC 是一種低電力消耗的共識機制？

——在容量證實的環境下，因爲機械硬盤天生對（相對的）電力不敏感，電力成本短時間內再也不是礦工加入網絡的敲門 磚，而機械硬盤的普遍適配性，更進一步下降了礦工加入網絡的難度，目前家用電腦經常使用之1~2T 硬盤便可成爲挖礦設備。更進一步，容量證實實際上不儲存網絡數據，即便硬盤損壞也不會致使網絡內容丟失，避免了FIlecoin 時空證實中數據丟失對網絡使用性的影響。

​

圖 6: PoC 和 PoW 的比較

8   Paxos

Paxos 由 Lamport 於 1888 年在《The Part-Time Parliament》論文中首次公開。Paxos算法解決的問題正是分佈式一致性問題，即一個分佈式系統中的各個進程如何就某個值（決議）達成一致。

Paxos 算法運行在容許宕機故障的異步系統中，不要求可靠的消息傳遞，可容忍消息丟失、延遲、亂序以及重複。它利用大多數 (Majority) 機制保證了 2F+1 的容錯能力，即 2F+1 個節點的系統最多容許 F 個節點同時出現故障 [2]。一個或多個提議進程 (Proposer) 能夠發起提案 (Proposal)，Paxos 算法使全部提案中的某一個提案，在全部進程中達成一致。系統中的多數派同時承認該提案，即達成了一致。最多隻針對一個肯定的提案達成一致。

8.1   角色

Proposer  提出提案(Proposal)。Proposal信息包括提案編號(Proposal ID)和提議的值(Value)。

Acceptor 參與決策，迴應Proposers的提案。收到Proposal後能夠接受提案，若Proposal得到多數Acceptors的接受，則稱該 Proposal 被批准。

Learner 不參與決策，從Proposers/Acceptors學習最新達成一致的提案（Value）。

8.2   原則

8.2.1   安全原則

 保證不能作錯的事。 

1. 針對某個實例的表決只能有一個值被批准，不能出現一個被批准的值被另外一個值覆蓋的狀況；(假設有一個值被多數 Acceptors 批准了，那麼這個值就只能被學習)。

2. 每一個節點只能學習到已經被批准的值，不能學習沒有被批准的值。

8.2.2   存活原則

 只要有多數服務器存活而且彼此間能夠通訊，最終都要作到的下列事情：

1. 最終會批准某個被提議的值。

2. 一個值被批准了，其餘服務器最終會學習到這個值。

8.3   算法流程

 1. 第一階段：Prepare 階段。Proposer 向 Acceptors 發出 Prepare 請求，Acceptors 針對收到的 Prepare 請求進行 Promise 承諾。

2. 第二階段：Accept 階段。Proposer 收到多數 Acceptors 承諾的 Promise 後，向 Acceptors 發出 Propose 請求， Acceptors 針對收到的 Propose 請求進行 Accept 處理。

3. Learn 階段。Proposer 在收到多數 Acceptors 的 Accept 以後，標誌着本次 Accept 成功，決議造成，將造成的決議發送給全部 Learners。

8.3.1   算法描述

 1. Prepare: Proposer 生成全局惟一且遞增的 Proposal ID (可以使用時間戳加 Server ID)，向全部 Acceptors 發送Prepare 請求，這裏無需攜帶提案內容, 只攜帶 Proposal ID 便可。 

2. Propose: Proposer 收到多數 Acceptors 的 Promise 應答後，從應答中選擇 Proposal ID 最大的提案的 Value，做爲本次要發起的提案。若是全部應答的提案 Value 均爲空值，則能夠本身隨意決定提案 Value。而後攜帶當前 Proposal ID，向全部 Acceptors 發送 Propose 請求。

3. Acceptors 收到 Prepare 請求後，作出「兩個承諾，一個應答」。

4. Accept: Acceptor 收到 Propose 請求後，在不違背本身以前做出的承諾下，接受並持久化當前Proposal ID 和提案 Value。

5. Learn: Proposer 收到多數 Acceptors 的 Accept 後，決議造成，將造成的決議發送給全部 Learners。 

​

圖 7: Paxos 算法過程

8.3.2   兩個承諾，一個應答 [4]

 1. 兩個承諾：再也不接受 Proposal ID 小於等於當前請求的 Prepare 請求；再也不接受 Proposal ID 小於當前請求的Propose 請求。

2. 一個應答：不違背之前做出的承諾下，回覆已經Accept 過的提案中 Proposal ID 最大的那個提案的 Value 和 Proposal ID，沒有則返回空值。

8.4   優勢

1. 高效，節點通訊無須驗證身份簽名。

2. Paxos 算法有嚴格的數學證實，系統設計精妙。

3. 容錯性能: 容許半數之內的 Acceptor 失效、任意數量的 Proposer 失效，都能運行。一旦 value 值被肯定，即便半數之內的 Acceptor 失效，此值也能夠被獲取，並不會再修改。

8.5   缺點

1. 工程實踐比較難，達到工業級性能須要進行不一樣程度的工程優化，而有時工程設計的誤差會形成整個系統的崩潰。

2. 只適用於 permissionedsystems(私有鏈)，只能容納故障節點 (fault)，不容納做惡節點 (corrupt)。

3. 持 CFT(Crash FaultTolerant)，不支持拜占庭容錯 (ByzantineFault Tolerance)。

8.6   問題解釋

Multi-Paxos 和 Paxos 的關係？ 

——樸素Paxos 算法經過多輪的 Prepare/Accept 過程來肯定一個值，咱們稱這整個過程爲一個 Instance。Multi-Paxos 是經過 Paxos 算法來肯定不少個值，並且這些值的順序在各個節點徹底一致，歸納來說就是肯定一個全局順序 [10]。

9   Raft

Raft 最初是一個用於管理複製日誌的共識算法，它是一個爲真實世界應用創建的協議，主要注重協議的落地性和可理解性。Raft 是在非拜占庭故障下達成共識的強一致協議，是一種管理複製日誌的一致性算法。它的首要設計目的就是易於理解，因此在選主的衝突處理等方式上它都選擇了很是簡單明瞭的解決方案。Paxos 有效的基本保障是：任意兩個法定集合，一定存在一個公共的成員。分佈式系統除了提高整個體統的性能外還有一個重要特徵就是提升系統的可靠性。提供可靠性能夠理解爲系統中一臺或多臺的機器故障不會使系統不可用（或者丟失數據）。保證系統可靠性的關鍵就是多副本（即數據須要有備份），一旦有多副本，那麼久面臨多副本之間的一致性問題。一致性算法正是用於解決分佈式環境下多副本之間數據一致性的問題的。 

業界最著名的一致性算法就是大名鼎鼎的 Paxos（Chubby 的做者曾說過：世上只有一種一致性算法，就是Paxos）。

但 Paxos 是出了名的難懂，而 Raft 正是爲了探索一種更易於理解的一致性算法而產生的。

9.1   角色

Raft 要求系統在任意時刻最多隻有一個 Leader，正常工做期間只有 Leader 和 Followers。

Leader 領導者接受客戶端請求，並向Follower同步請求日誌，當日志同步到大多數節點上後告訴Follower提交日誌。全部對系統的修改都會先通過Leader，每一個修改都會寫一條日誌 (Log Entry)。Leader 收到修改請求後的過程以下，這個過程叫作日誌複製(Log Replication)：

​

 圖 8: 日誌複製

Follower 跟從者全部結點都以Follower的狀態開始。若是沒收到Leader消息則會變成Candidate狀態。接受並持久化 Leader 同步的日誌，在 Leader 告之日誌能夠提交以後，提交日誌。

Candidate 候選人Leader選舉過程當中的臨時角色。會向其餘結點「拉選票」，若是獲得大部分的票則成爲Leader。

​

圖 9: 三個角色之間的關係圖

9.2   算法流程

1. Leader Election 領導人選舉：當 Follower 在選舉超時時間內未收到 Leader 的心跳消息，則轉換爲 Candidate狀態。爲了不選舉衝突，這個超時時間是一個 150~300ms 之間的隨機數。通常而言，在 Raft 系統中：

•   任何一個服務器均可以成爲一個候選者Candidate，它向其餘服務器 Follower 發出要求選舉本身的請求。

•   其餘服務器贊成了，發出 OK。注意，若是在這個過程當中，有一個 Follower 宕機，沒有收到請求選舉的要求，此時候選者能夠本身選本身，只要達到 N/2+1 的大多數票，候選人仍是能夠成爲Leader 的。

•   這樣這個候選者就成爲了 Leader 領導人，它能夠向選民也就是 Follower 發出指令，好比進行記帳。

•   經過心跳進行記帳的通知。

•   一旦這個 Leader 崩潰了，那麼 Follower 中有一個成爲候選者，併發出邀票選舉。

•   Follower 贊成後，其成爲 Leader，繼續承擔記帳等指導工做。

2. Log Replication 日誌複製：Raft 的記帳過程按如下步驟完成：

​

圖 10: 記帳過程

對於每一個新的交易記錄，重複上述過程。在這一過程當中，若發生網絡通訊故障，使得 Leader 不能訪問大多數 Follower 了，那麼 Leader 只能正常更新它能訪問的那些 Follower 服務器。而大多數的服務器 Follower 由於沒有了 Leader，他們將從新選舉一個候選者做爲 Leader，而後這個 Leader 做爲表明與外界打交道，若是外界要求其添加新的交易記錄，這個新的 Leader 就按上述步驟通知大多數 Follower。當網絡通訊恢復，原先的 Leader 就變成 Follower，在失聯階段，這個老 Leader 的任何更新都不能算確認，必須所有回滾，接收新的Leader 的新的更新。

9.3   優勢

1. 比 Paxos 算法更容易理解，並且更容易工程化實現。

2. Raft 與 Paxos 同樣高效，效率上 Raft 等價於 (multi-)Paxos。

3.  適用用於 permissionedsystems(私有鏈)，只能容納故障節點（CFT），不支持做惡節點。最大的容錯故障節點是(N-1)/2，其中 N 爲集羣中總的節點數量。強化了 Leader 的地位，整個協議能夠分割成兩個部分：Leader在時，由 Leader 向 Follower 同步日誌；Leader 失效了，選一個新 Leader。

4. 強調合法 Leader 的惟一性協議，它們直接從 Leader 的 度描述協議的流程，也從 Leader 的角度出發論證正確性。

9.4   缺點

1. 只適用於permissioned systems (私有鏈)，只能容納故障節點 (CFT)，不容納做惡節點。

​

表 2: Raft 和 Multi-Paxos 的比較

參考文獻

[1]  Beccuti, J., and Jaag, C. The bitcoin mining game:On the optimality of honesty in proof-of-work consensus mechanism. WorkingPapers (2017).

[2]  From Wikipedia, t. f. e. Paxos (computer science). https://en.wikipedia.org/wiki..._(computer_science).

[3]  From Wikipedia, t. f. e. Proof of work. https://en.wikipedia.org/wiki..._of_work.

[4]  Lamport, L.  Paxos madesimple.  https://www.microsoft.com/en-...

made-simple/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Flamport%2Fpubs%2Fpaxos-simple.pdf.

[5]  Team, E. Proof of capacity explained: Theeco-friendly mining algorithm. https://www.coinbureau.com/ed...

[6] 杜江天. 區塊鏈工做量證實機制中的哈希算法探討. 電腦編程技巧與維護 _No.394_, 4 (2018), 42–44.

[7] 楊宇光, and 張樹新. Review and research for consensus mechanism of block chain信息安全研究_004_, 4 (2018), 369–379.

[8] 梁斌. 從」 比特幣挖礦」 看區塊鏈技術的共識機制. 中國金融電腦, 9 (2016), 45–46.

[9] 甘俊, 李強, 陳子豪, and 張超. 區塊鏈實用拜占庭容錯共識算法的改進.計算機應用, 7 (2019).

[10] 祝朝凡, 郭進偉, and 蔡鵬. 基於 paxos 的分佈式一致性算法的實現與優化.華東師範大學學報 _(_天然科學版_)_, 10 (2019), 168–177.

[11] 程書芝, 師文軒, and 劉儷婷. 區塊鏈技術綜述.

[12] 韓璇, and 劉亞敏. 區塊鏈技術中的共識機制研究. 信息網絡安全, 9 (2017).

[13] 黃嘉成, 許新華, and 王世純. 委託權益證實共識機制的改進方案. 計算機應用, 7 (2019),2162–2167