共識機制（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/Paxos_(computer_science).
[3] From Wikipedia, t. f. e. Proof of work. https://en.wikipedia.org/wiki/Proof_of_work.
[4] Lamport, L. Paxos madesimple. https://www.microsoft.com/en-us/research/publication/paxos-
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/education/proof-of-capacity-explained/.
[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