[區塊鏈] 共識算法之爭（PBFT，Raft，PoW，PoS，DPoS，Ripple）

　　近幾天對區塊鏈中幾種常見的共識機制（PBFT，Raft，PoW，PoS，DPoS，Ripple）進行了總結。儘可能使用簡單易懂語言，篇幅較大，想了解的能夠只讀每一個算法介紹中前邊的原理。本篇文章主要參考《區塊鏈技術指南》，首先表示感謝！ 

　　---Begin---

　　區塊鏈架構是一種分佈式的架構。其部署模式有公共鏈、聯盟鏈、私有鏈三種，對應的是去中心化分佈式系統、部分去中心化分佈式系統和弱中心分佈式系統。

　　在分佈式系統中，多個主機經過異步通訊方式組成網絡集羣。在這樣的一個異步系統中，須要主機之間進行狀態複製，以保證每一個主機達成一致的狀態共識。然而，異步系統中，可能出現沒法通訊的故障主機，而主機的性能可能降低，網絡可能擁塞，這些可能致使錯誤信息在系統內傳播。所以須要在默認不可靠的異步網絡中定義容錯協議，以確保各主機達成安全可靠的狀態共識。

　　所謂共識，簡單理解就是指你們都達成一致的意思。其實在現實生活中，有不少須要達成共識的場景，好比開會討論，雙方或多方簽定一份合做協議等。而在區塊鏈系統中，每一個節點必需要作的事情就是讓本身的帳本跟其餘節點的帳本保持一致。若是是在傳統的軟件結構中，這幾乎就不是問題，由於有一箇中心服務器存在，也就是所謂的主庫，其餘的從庫向主庫看齊就好了。在實際生活中，不少事情人們也都是按照這種思路來的，好比企業老闆發佈一個通知，員工照着作。可是區塊鏈是一個分佈式的對等網絡結構，在這個結構中沒有哪一個節點是「老大」，一切都要商量着來。

　　因此在區塊鏈系統中，如何讓每一個節點經過一個規則將各自的數據保持一致是一個很核心的問題，這個問題的解決方案就是制定一套共識算法，實現不一樣帳本節點上的帳本數據的一致性和正確性。這就須要借鑑已有的在分佈式系統中實現狀態共識的算法，肯定網絡中選擇記帳節點的機制，以及如何保障帳本數據在全網中造成正確、一致的共識。

　　共識算法其實就是一個規則，每一個節點都按照這個規則去確認各自的數據。咱們暫且拋開算法的原理，先來想想在生活中咱們會如何解決這樣一個問題：假設一羣人開會，這羣人中沒有一個領導或者說老大，你們各抒己見，那麼最後如何統一出一個決定出來呢？實際處理的時候，咱們通常會在某一個時間段中選出一我的，那我的負責彙總你們的內容，而後發佈完整的意見，其餘人投票表決，每一個人都有機會來作彙總發表，最後誰的支持者多就以誰的最終意見爲準。這種思路其實就算是一種共識算法了。然而在實際過程當中，若是人數很少而且數量是肯定的，還好處理；若是人數不少且數量也不固定，那就很難經過這種方式投票決定了，效率過低。咱們須要經過一種機制篩選出最有表明性的人，在共識算法中就是篩選出具備表明性的節點。

　　那如何篩選呢？其實就是設置一組條件，就像篩選尖子生同樣，給一組指標讓你們來完成，誰能更好地完成指標，誰就能有機會被選上。在區塊鏈系統中，存在着多種這樣的篩選方案，好比PBFT（Practical Byzantine Fault Tolerance，實用拜占庭容錯算法）、PoW（Proof of Work，工做量證實）、PoS（Proof of Stake，權益證實）、DPoS（Delegate Proof of Stake，委託權益證實）、Ripple（瑞波）等，各類不一樣的算法，其實就是不一樣的遊戲玩法。

 

---

 

一.拜占庭容錯技術（Byzantine Fault Tolerance，BFT）

　　拜占庭容錯技術（Byzantine Fault Tolerance，BFT）是一類分佈式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，因爲硬件錯誤、網絡擁塞或中斷以及遭到惡意攻擊等緣由，計算機和網絡可能出現不可預料的行爲。拜占庭容錯技術被設計用來處理這些異常行爲，並知足所要解決的問題的規範要求。

　　拜占庭容錯技術來源於拜占庭將軍問題（猛擊！查看該問題）。

　　在分佈式系統中，特別是在區塊鏈網絡環境中，也和拜占庭將軍的環境相似，有運行正常的服務器（相似忠誠的拜占庭將軍），有故障的服務器，還有破壞者的服務器（相似叛變的拜占庭將軍）。共識算法的核心是在正常的節點間造成對網絡狀態的共識。

　　一般，這些發生故障節點被稱爲拜占庭節點，而正常的節點即爲非拜占庭節點。

　　拜占庭容錯系統是一個擁有n臺節點的系統，整個系統對於每個請求，知足如下條件：

　　1）全部非拜占庭節點使用相同的輸入信息，產生一樣的結果；

　　2）若是輸入的信息正確，那麼全部非拜占庭節點必須接收這個信息，並計算相應的結果。

　　拜占庭系統廣泛採用的假設條件包括：

　　1）拜占庭節點的行爲能夠是任意的，拜占庭節點之間能夠共謀；

　　2）節點之間的錯誤是不相關的；

　　3）節點之間經過異步網絡鏈接，網絡中的消息可能丟失、亂序並延時到達，但大部分協議假設消息在有限的時間裏能傳達到目的地；

　　4）服務器之間傳遞的信息，第三方能夠嗅探到，可是不能篡改、僞造信息的內容和驗證信息的完整性。

　　原始的拜占庭容錯系統因爲須要展現其理論上的可行性而缺少實用性。另外，還須要額外的時鐘同步機制支持，算法的複雜度也是隨節點增長而指數級增長。

二.PBFT：Practical Byzantine Fault Tolerance，實用拜占庭容錯算法。

　　實用拜占庭容錯系統（PBFT）下降了拜占庭協議的運行復雜度，從指數級別下降到多項式級別（Polynomial），使拜占庭協議在分佈式系統中應用成爲可能。

　　PBFT是一種狀態機副本複製算法，即服務做爲狀態機進行建模，狀態機在分佈式系統的不一樣節點進行副本複製。每一個狀態機的副本都保存了服務的狀態，同時也實現了服務的操做。將全部的副本組成的集合使用大寫字母R表示，使用0到|R|-1的整數表示每個副本。爲了描述方便，一般假設故障節點數爲m個，整個服務節點數爲|R|=3m+1個，這裏m是有可能失效的副本的最大個數。儘管能夠存在多於3m+1個副本，可是額外的副本除了下降性能以外不能提升可靠性。

　　PBFT要求共同維護一個狀態，全部節點採起的行動一致。爲此，須要運行三類基本協議，包括一致性協議、檢查點協議和視圖更換協議。咱們主要關注支持系統平常運行的一致性協議。一致性協議至少包含若干個階段：請求（request）、序號分配（pre-prepare）和響應（reply）。根據協議設計的不一樣，可能包含相互交互（prepare），序號確認（commit）等階段。

PBFT協議通訊模式

　　上圖爲PBFT協議通訊模式，每個客戶端的請求須要通過5個階段，經過採用兩次兩兩交互的方式在服務器達成一致以後再執行客戶端的請求。因爲客戶端不能從服務器端得到任何服務器運行狀態的信息，PBFT中主節點是否發生錯誤只能由服務器監測。若是服務器在一段時間內都不能完成客戶端的請求，則會觸發視圖更換協議。其中C爲客戶端，N₀~N₃表示服務節點，特別的，N₀爲主節點，N₃爲故障節點。整個協議的基本過程以下：

1）客戶端發送請求，激活主節點的服務操做。

2）當主節點接收請求後，啓動三階段的協議以向各從節點廣播請求。

［2.1］序號分配階段，主節點給請求賦值一個序列號n，廣播序號分配消息和客戶端的請求消息m，並將構造PRE-PREPARE消息給各從節點；

［2.2］交互階段，從節點接收PRE-PREPARE消息，向其餘服務節點廣播PREPARE消息；

［2.3］序號確認階段，各節點對視圖內的請求和次序進行驗證後，廣播COMMIT消息，執行收到的客戶端的請求並給客戶端以響應。

3）客戶端等待來自不一樣節點的響應，如有m+1個響應相同，則該響應即爲運算的結果。

 

　　PBFT在不少場景都有應用，在區塊鏈場景中，通常適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級帳本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識算法。

三.Raft協議。

　　在這些分佈式系統的實用場景下，其假設條件不須要考慮拜占庭故障，而只是處理通常的死機故障。在這種狀況下，採用Paxos等協議會更加高效。Paxos是Lamport設計的保持分佈式系統一致性的協議。但因爲Paxos很是複雜，比較難以理解，所以後來出現了各類不一樣的實現和變種。Raft是由Stanford提出的一種更易理解的一致性算法，意在取代目前廣爲使用的Paxos算法。目前，在各類主流語言中都有了一些開源實現，好比本文中將使用的基於JGroups的Raft協議實現。關於Raft的原理，強烈推薦動畫版Raft講解 （猛擊！查看該視頻）。

　　Raft最初是一個用於管理複製日誌的共識算法，它是一個爲真實世界應用創建的協議，主要注重協議的落地性和可理解性。Raft是在非拜占庭故障下達成共識的強一致協議。

　　在區塊鏈系統中，使用Raft實現記帳共識的過程能夠描述以下：首先選舉一個leader，接着賦予leader徹底的權力管理記帳。leader從客戶端接收記帳請求，完成記帳操做，生成區塊，並複製到其餘記帳節點。有了leader簡化了記帳操做的管理。例如，leader可以決定是否接受新的交易記錄項而無需考慮其餘的記帳節點，leader可能失效或與其餘節點失去聯繫，這時，系統就會選出新的leader。

　　在Raft中，每一個結點會處於下面三種狀態中的一種：

• follower：全部結點都以follower的狀態開始。若是沒收到leader消息則會變成candidate狀態
• candidate：會向其餘結點「拉選票」，若是獲得大部分的票則成爲leader。這個過程就叫作Leader選舉(Leader Election)
• leader：全部對系統的修改都會先通過leader。每一個修改都會寫一條日誌(log entry)。leader收到修改請求後的過程以下，這個過程叫作日誌複製(Log Replication)： 
  
  • 複製日誌到全部follower結點(replicate entry)
  • 大部分結點響應時才提交日誌
  • 通知全部follower結點日誌已提交
  • 全部follower也提交日誌
  • 如今整個系統處於一致的狀態

Raft階段主要分爲兩個，首先是leader選舉過程，而後在選舉出來的leader基礎上進行正常操做，好比日誌複製、記帳等。

1.Leader Election　

　　當follower在選舉超時時間內未收到leader的心跳消息，則轉換爲candidate狀態。爲了不選舉衝突，這個超時時間是一個150~300ms之間的隨機數。

　　通常而言，在Raft系統中：

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

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

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

　　4）之後經過心跳進行記帳的通知。

　　5）一旦這個leader崩潰了，那麼follower中有一個成爲候選者，併發出邀票選舉。

　　6）follower贊成後，其成爲leader，繼續承擔記帳等指導工做。

2.Log Replication

　　Raft的記帳過程按如下步驟完成：

　　1）假設leader領導人已經選出，這時客戶端發出增長一個日誌的要求；

　　2）leader要求follower聽從他的指令，都將這個新的日誌內容追加到他們各自日誌中；

　　3）大多數follower服務器將交易記錄寫入帳本後，確認追加成功，發出確認成功信息；

　　4）在下一個心跳中，leader會通知全部follower更新確認的項目。

　　對於每一個新的交易記錄，重複上述過程。

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

四.POW：Proof of Work，工做證實。

　　從去中心化帳本系統的角度看，每一個加入這個系統的節點都要保存一份完整的帳本，但每一個節點卻不能同時記帳，由於節點處於不一樣的環境，接收到不一樣的信息，若是同時記帳的話，必然會致使帳本的不一致，形成混亂。所以，須要有共識來達成哪一個節點有權記帳。比特幣區塊鏈經過競爭記帳的方式解決去中心化的記帳系統的一致性問題, 即以每一個節點的計算能力即「算力」來競爭記帳權的機制。　

　　在比特幣系統中，大約每10分鐘進行一輪算力競賽，競賽的勝利者，就得到一次記帳的權力，並向其餘節點同步新增帳本信息。然而，在一個去中心化的系統中，誰有權斷定競爭的結果呢？比特幣系統是經過一個稱爲「工做量證實」（Proof of Work，PoW）的機制完成的。

　　簡單地說，PoW就是一份確認工做端作過必定量工做的證實。PoW系統的主要特徵是計算的不對稱性。工做端須要作必定難度的工做得出一個結果，驗證方卻很容易經過結果來檢查工做端是否是作了相應的工做。

　　舉個例子，給定字符串「blockchain」，咱們給出的工做量要求是，能夠在這個字符串後面鏈接一個稱爲nonce的整數值串，對鏈接後的字符串進行SHA256哈希運算，若是獲得的哈希結果（以十六進制的形式表示）是以若干個0開頭的，則驗證經過。爲了達到這個工做量證實的目標，咱們須要不停地遞增nonce值，對獲得的新字符串進行SHA256哈希運算。按照這個規則，須要通過2688次計算才能找到前3位均爲0的哈希值，而要找到前6位均爲0的哈希值，則需進行620969次計算。

1 blockchain1 → 4bfb943cba9fb9926df93f33c17d64b378d56714e8a29c6ba8bdc9690cea8e27  
2 blockchain2 → 01181212a283e760929f6b1628d903127c65e6fb5a9ad7fe94b790e699269221 ……
3 blockchain515 → 0074448bea8027bebd6333d3aa12fd11641e051911c5bab661a9b849b83958a7……
4 blockchain2688 → 0009b257eb8cf9eba179ab2be74d446fa1c59f0adfa8814260f52ae0016dd50f……
5 blockchain48851: 00000b3d96b4db1a976d3a69829aabef8bafa35ab5871e084211a16d3a4f385c……
6 blockchain6200969: 000000db7fa334aef754b51792cff6c880cd286c5f490d5cf73f658d9576d424

　　經過上面這個計算特定SHA256運算結果的示例，咱們對PoW機制有了一個初步的理解。對於特定字符串後接隨機nonce值所構成的串，要找到這樣的nonce值，知足前n位均爲0的SHA256值，須要屢次進行哈希值的計算。通常來講，n值越大，須要完成的哈希計算量也越大。因爲哈希值的僞隨機特性，要尋找4個前導0的哈希值，預期大概要進行2¹⁶次嘗試，這個數學指望的計算次數，就是所要求的「工做量」。

　　比特幣網絡中任何一個節點，若是想生成一個新的區塊並寫入區塊鏈，必須解出比特幣網絡出的PoW問題。這道題關鍵的3個要素是工做量證實函數、區塊及難度值。工做量證實函數是這道題的計算方法，區塊決定了這道題的輸入數據，難度值決定了這道題所須要的計算量。

　　1.工做量證實函數 及 區塊數據計算過程

　　比特幣系統中使用的工做量證實函數就是SHA256（猛擊！查看該問題）。

　　比特幣區塊結構以下圖所示：

　　比特幣的區塊由區塊頭及該區塊所包含的交易列表組成。區塊頭的大小爲80字節，由4字節的版本號、32字節的上一個區塊的哈希值、32字節的Merkle根哈希值、4字節的時間戳（當前時間）、4字節的當前難度值、4字節的隨機數組成。區塊包含的交易列表則附加在區塊頭後面，其中的第一筆交易是coinbase交易，這是一筆爲了讓礦工得到獎勵及手續費的特殊交易。

　　擁有80字節固定長度的區塊頭，就是用於比特幣工做量證實的輸入字符串。所以，爲了使區塊頭能體現區塊所包含的全部交易，在區塊的構造過程當中，須要將該區塊要包含的交易列表，經過Merkle樹算法（猛擊）生成Merkle根哈希值，並以此做爲交易列表的哈希值存到區塊頭中。其中Merkle樹的算法圖解以下圖所示。

　　

　　

　　上圖展現了一個具備4個交易記錄的Merkle樹的根哈希值的計算過程。首先以這4個交易做爲葉子結點構造一棵徹底二叉樹，而後經過哈希值的計算，將這棵二叉樹轉化爲Merkle樹。

首先對4個交易記錄：Txa~Txc，分別計算各自的哈希值H_A~H_C，而後計算兩個中間節點的哈希值H_AB=Hash（H_A+H_B）和H_CD=Hash（H_C+H_D），最後計算出根節點的哈希值H_ABCD=Hash（H_AB+H_CD）。

 

　　而構造出來的簡化的區塊鏈結構如上圖所示。We find that: 全部在給定時間範圍須要記錄的交易信息被構形成一個Merkle樹，區塊中包含了指向這個Merkle樹的哈希指針，關聯了與該區塊相關的交易數據，同時，區塊中也包含了指向前一區塊的哈希指針，使得記錄了不一樣交易的單個區塊被關聯起來，造成區塊鏈。

　　2.挖礦難度

　　難度值是比特幣系統中的節點在生成區塊時的重要參考指標，它決定了節點大約須要通過多少次哈希運算才能產生一個合法的區塊。比特幣的區塊大約每10分鐘生成一個，若是要在不一樣的全網算力條件下，新區塊的產生都基本保持這個速率，難度值必須根據全網算力的變化進行調整。簡單地說，難度值被設定在不管節點計算能力如何，新區塊產生速率都保持在每10分鐘一個。

　　難度的調整是在每一個完整節點中獨立自動發生的。每2016個區塊，全部節點都會按統一的公式自動調整難度，這個公式是由最新2016個區塊的花費時長與指望時長（指望時長爲20160分鐘，即兩週，是按每10分鐘一個區塊的產生速率計算出的總時長）比較得出的，根據實際時長與指望時長的比值，進行相應調整（或變難或變易）。也就是說，若是區塊產生的速率比10分鐘快則增長難度，比10分鐘慢則下降難度。　

　　這個公式能夠總結爲：新難度值=舊難度值×（過去2016個區塊花費時長/20160分鐘）

　　工做量證實須要有一個目標值。比特幣工做量證實的目標值（Target）的計算公式：目標值=最大目標值/難度值

　　其中最大目標值爲一個恆定值：0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

　　目標值的大小與難度值成反比。比特幣工做量證實的達成就是礦工計算出來的區塊哈希值必須小於目標值。

　　3.PoW過程　

　　比特幣PoW的過程，能夠簡單理解成就是將不一樣的nonce值做爲輸入，嘗試進行SHA256哈希運算，找出知足給定數量前導0的哈希值的過程。而要求的前導0的個數越多，表明難度越大。比特幣節點求解工做量證實問題的步驟大體概括以下：

　　1）生成鑄幣交易，並與其餘全部準備打包進區塊的交易組成交易列表，經過Merkle樹算法生成Merkle根哈希；

　　2）把Merkle根哈希及其餘相關字段組裝成區塊頭，將區塊頭的80字節數據做爲工做量證實的輸入；

　　3）不停地變動區塊頭中的隨機數，即nonce的數值，並對每次變動後的區塊頭作雙重SHA256運算（即SHA256（SHA256（Block_Header））），將結果值與當前網絡的目標值作對比，若是小於目標值，則解題成功，工做量證實完成。

　　比特幣的工做量證實，就是俗稱「挖礦」所作的主要工做。

　　4.PoW可否解決拜占庭將軍問題　

　　關於比特幣PoW共識機制可否解決拜占庭將軍問題一直在業界有爭議。2015年，Juan Garay對比特幣的PoW共識算法進行了正式的分析，得出的結論是比特幣的PoW共識算法是一種機率性的拜占庭協議（Probabilistic BA）。Garay對比特幣共識協議的兩個重要屬性分析以下。

　　1）一致性（Agreement）

　　在不誠實節點總算力小於50%的狀況下，同時每輪同步區塊生成的概率不多的狀況下，誠實的節點具備相同的區塊的機率很高。用數學的嚴格語言說應該是：當任意兩個誠實節點的本地鏈條截取K個節點，兩條剩下的鏈條的頭區塊不相同的機率隨着K的增長呈指數型遞減。

　　2）正確性（Validity）

　　大多數的區塊必須由誠實節點提供。嚴格來講，當不誠實算力很是小的時候，才能使大多數區塊由誠實節點提供。

　　所以能夠看到，當不誠實的算力小於網絡總算力的50%時，同時挖礦難度比較高，在大約10分鐘出一個區塊狀況下，比特幣網絡達到一致性的概念會隨確認區塊的數目增多而呈指數型增長。但當不誠實算力具必定規模，甚至不用接近50%的時候，比特幣的共識算法並不能保證正確性，也就是，不能保證大多數的區塊由誠實節點來提供。

　　所以，咱們能夠看到，比特幣的共識算法不適合於私有鏈和聯盟鏈。其緣由首先是它是一個最終一致性共識算法，不是一個強一致性共識算法。第二個緣由是其共識效率低。提供共識效率又會犧牲共識協議的安全性。另外，比特幣經過巧妙的礦工獎勵機制來提高網絡的安全性。礦工挖礦得到比特幣獎勵以及記帳所得的交易費用使得礦工更但願維護網絡的正常運行，而任何破壞網絡的非誠信行爲都會損害礦工自身的利益。所以，即便有些比特幣礦池具有強大的算力，它們都沒有做惡的動機，反而有動力維護比特幣的正常運行，由於這和它們的切實利益相關。

　　PoW機制存在明顯的弊端。一方面，PoW的前提是，節點和算力是均勻分佈的，由於經過CPU的計算能力來進行投票，擁有錢包（節點）數和算力值應該是大體匹配的，然而隨着人們將CPU挖礦逐漸升級到GPU、FPGA，直至ASIC礦機挖礦，節點數和算力值也漸漸失配。另外一方面，PoW太浪費了。比特幣網絡每秒可完成數百萬億次SHA256計算，但這些計算除了使惡意攻擊者不能輕易地假裝成幾百萬個節點和打垮比特幣網絡，並無更多實際或科學價值。固然，相對於容許世界上任何一我的在瞬間就能經過去中心化和半匿名的全球貨幣網絡，給其餘人幾乎沒有手續費地轉帳所帶來的巨大好處，它的浪費也許只算是很小的代價。

　　有鑑於此，人們提出了權益證實（Proof of Stake，PoS）。

五.POS：Proof of Stake，股權證實。

　　PoS相似於財產儲存在銀行，這種模式會根據你持有數字貨幣的量和時間，分配給你相應的利息。 
　　簡單來講，就是一個根據你持有貨幣的量和時間，給你發利息的一個制度，在股權證實PoS模式下，有一個名詞叫幣齡，每一個幣天天產生1幣齡，好比你持有100個幣，總共持有了30天，那麼，此時你的幣齡就爲3000，這個時候，若是你發現了一個PoS區塊，你的幣齡就會被清空爲0。你每被清空365幣齡，你將會從區塊中得到0.05個幣的利息(假定利息可理解爲年利率5%)，那麼在這個案例中，利息 = 3000 * 5% / 365 = 0.41個幣，這下就頗有意思了，持幣有利息。

　　點點幣（Peercoin）是首先採用權益證實的貨幣，點點幣在SHA256的哈希運算的難度方面引入了幣齡的概念，使得難度與交易輸入的幣齡成反比。在點點幣中，幣齡被定義爲幣的數量與幣所擁有的天數的乘積，這使得幣齡可以反映交易時刻用戶所擁有的貨幣數量。實際上，點點幣的權益證實機制結合了隨機化與幣齡的概念，未使用至少30天的幣能夠參與競爭下一區塊，越久和越大的幣集有更大的可能去簽名下一區塊。

　　然而，一旦幣的權益被用於簽名一個區塊，則幣齡將清爲零，這樣必須等待至少30日才能簽署另外一區塊。同時，爲防止很是老或很是大的權益控制區塊鏈，尋找下一區塊的最大機率在90天后達到最大值，這一過程保護了網絡，並隨着時間逐漸生成新的幣而無需消耗大量的計算能力。點點幣的開發者聲稱這將使得惡意攻擊變得困難，由於沒有中心化的挖礦池需求，並且購買半數以上的幣的開銷彷佛超過得到51%的工做量證實的哈希計算能力。

　　權益證實必須採用某種方法定義任意區塊鏈中的下一合法區塊，依據帳戶結餘來選擇將致使中心化，例如單個首富成員可能會擁有長久的優點。爲此，人們還設計了其餘不一樣的方法來選擇下一合法區塊。

　　PoS機制雖然考慮到了PoW的不足，但依據權益結餘來選擇，會致使首富帳戶的權力更大，有可能支配記帳權。股份受權證實機制（Delegated Proof of Stake，DPoS）的出現正是基於解決PoW機制和PoS機制的這類不足。

六.DPOS：Delegated Proof of Stake，委任權益證實

　　比特股（Bitshare）是一類採用DPoS機制的密碼貨幣，它指望經過引入一個技術民主層來減小中心化的負面影響。

　　比特股的DPoS機制，中文名叫作股份受權證實機制（又稱受託人機制），它的原理是讓每個持有比特股的人進行投票，由此產生101位表明 , 咱們能夠將其理解爲101個超級節點或者礦池，而這101個超級節點彼此的權利是徹底相等的。從某種角度來看，DPOS有點像是議會制度或人民表明大會制度。若是表明不能履行他們的職責（當輪到他們時，沒能生成區塊），他們會被除名，網絡會選出新的超級節點來取代他們。DPOS的出現最主要仍是由於礦機的產生，大量的算力在不瞭解也不關心比特幣的人身上，相似演唱會的黃牛，大量囤票而絲絕不關心演唱會的內容。

　　比特股引入了見證人這個概念，見證人能夠生成區塊，每個持有比特股的人均可以投票選舉見證人。獲得總贊成票數中的前N個（N一般定義爲101）候選者能夠當選爲見證人，當選見證人的個數（N）需知足：至少一半的參與投票者相信N已經充分地去中心化。

　　見證人的候選名單每一個維護週期（1天）更新一次。見證人而後隨機排列，每一個見證人按序有2秒的權限時間生成區塊，若見證人在給定的時間片不能生成區塊，區塊生成權限交給下一個時間片對應的見證人。DPoS的這種設計使得區塊的生成更爲快速，也更加節能。

　　DPoS充分利用了持股人的投票，以公平民主的方式達成共識，他們投票選出的N個見證人，能夠視爲N個礦池，而這N個礦池彼此的權利是徹底相等的。持股人能夠隨時經過投票更換這些見證人（礦池），只要他們提供的算力不穩定，計算機宕機，或者試圖利用手中的權力做惡。

　　比特股還設計了另一類競選，表明競選。選出的表明擁有提出改變網絡參數的特權，包括交易費用、區塊大小、見證人費用和區塊區間。若大多數表明贊成所提出的改變，持股人有兩週的審查期，這期間能夠罷免表明並廢止所提出的改變。這一設計確保表明技術上沒有直接修改參數的權利以及全部的網絡參數的改變最終需獲得持股人的贊成。

七.Ripple共識算法。

　　Ripple（瑞波）是一種基於互聯網的開源支付協議，能夠實現去中心化的貨幣兌換、支付與清算功能。在Ripple的網絡中，交易由客戶端（應用）發起，通過追蹤節點（tracking node）或驗證節點（validating node）把交易廣播到整個網絡中。追蹤節點的主要功能是分發交易信息以及響應客戶端的帳本請求。驗證節點除包含追蹤節點的全部功能外，還可以經過共識協議，在帳本中增長新的帳本實例數據。　　

　　Ripple的共識達成發生在驗證節點之間，每一個驗證節點都預先配置了一份可信任節點名單，稱爲UNL（Unique Node List）。在名單上的節點可對交易達成進行投票。每隔幾秒，Ripple網絡將進行以下共識過程：

　　1）每一個驗證節點會不斷收到從網絡發送過來的交易，經過與本地帳本數據驗證後，不合法的交易直接丟棄，合法的交易將彙總成交易候選集（candidate set）。交易候選集裏面還包括以前共識過程沒法確認而遺留下來的交易。

　　2）每一個驗證節點把本身的交易候選集做爲提案發送給其餘驗證節點。

　　3）驗證節點在收到其餘節點發來的提案後，若是不是來自UNL上的節點，則忽略該提案；若是是來自UNL上的節點，就會對比提案中的交易和本地的交易候選集，若是有相同的交易，該交易就得到一票。在必定時間內，當交易得到超過50%的票數時，則該交易進入下一輪。沒有超過50%的交易，將留待下一次共識過程去確認。　　

　　4）驗證節點把超過50%票數的交易做爲提案發給其餘節點，同時提升所需票數的閾值到60%，重複步驟3）、步驟4），直到閾值達到80%。

　　5）驗證節點把通過80%UNL節點確認的交易正式寫入本地的帳本數據中，稱爲最後關閉帳本（Last Closed Ledger），即帳本最後（最新）的狀態。

 Ripple共識過程節點交互示意圖

 

Ripple共識算法流程

　　在Ripple的共識算法中，參與投票節點的身份是事先知道的，所以，算法的效率比PoW等匿名共識算法要高效，交易的確認時間只需幾秒鐘。固然，這點也決定了該共識算法只適合於權限鏈（Permissioned chain）的場景。Ripple共識算法的拜占庭容錯（BFT）能力爲（n-1）/5，便可以容忍整個網絡中20%的節點出現拜占庭錯誤而不影響正確的共識。

 

---

 

　　以上主要是目前主流的共識算法。 但提及哪一種共識機制更好或更具替代做用？ 我認爲DPOS來單獨替代POW，POS或者POW＋POS不太可能，畢竟存在即合理。每種算法都在特定的時間段、場景下具備各自的意義，不管是技術上，仍是業務上。若是跳出技術者的角度，更多結合政治與經濟的思考方式在裏面，或許還會不斷出現更多的共識機制。

　　對於算法的選擇，一句話總結以下：

「 在區塊鏈網絡中，因爲應用場景的不一樣，所設計的目標各異，不一樣的區塊鏈系統採用了不一樣的共識算法。通常來講，在私有鏈和聯盟鏈狀況下，對一致性、正確性有很強的要求。通常來講要採用強一致性的共識算法。而在公有鏈狀況下，對一致性和正確性一般無法作到百分之百，一般採用最終一致性（Eventual Consistency）的共識算法。」

　　通俗點就是：共識算法的選擇與應用場景高度相關，可信環境使用paxos 或者raft，帶許可的聯盟可以使用pbft ，非許可鏈能夠是pow，pos，ripple共識等，根據對手方信任度分級，自由選擇共識機制。

 

---

【時間倉促，若有錯誤，歡迎指正！ ||   歡迎留下您的評語！  你們一塊兒探討、學習區塊鏈!】

【轉載請註明出處！http://www.cnblogs.com/X-knight/】

---

 

REFERENCE

1. Diego Ongaro and John Ousterhout Stanford University In Search of an Understandable Consensus Algorithm (Extended Version)
2. 《區塊鏈技術指南》鄒均，張海寧，唐屹，李磊 著
3. Raft協議 https://blog.csdn.net/dc_726/article/details/48832405/