HPB50：主流共識算法分析

區塊鏈核心框架

區塊鏈是一個不斷增加的分佈式帳本[2]，帳本用「區塊」的形式銜接在一塊兒，區塊中包含交易， 時間戳，隨機數等元數據，每一個區塊中含有一個指針指向上一個交易連接，區塊鏈的設計是安 全的，由於其具備良好的拜占庭容錯能力。區塊鏈能夠歸納爲一個分佈式的高頻交易系統，如 下圖 1 所示，區塊鏈的核心技術能夠總結爲四部分：分佈式的數據庫，密碼學相關理論，共識機制和 P2P 網絡。

中分佈式數據庫負責數據的寫入與讀取，密碼學中非對稱密鑰和 HASH 等算法來標識交易者的身份和保證系統的完整性；對等網絡是系統運行的基礎；共識算法用來保證交易信息在整個帳本不一樣節點中寫入的一致性，經常使用的共識算法有 POW, POS, DPOS 等。

共識算法與 CAP 理論

共識算法是爲了解決在對等網絡中(P2P),相互獨立的節點如何達成一項決議問題的過程。簡而言之，共識算法是在解決分佈式系統中如何保持一致性的問題。關於此部分的討論較爲成熟和最爲普遍接受的理論是 CAP 理論。CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出[4]，並提出分佈式系統不能同時徹底知足 CAP 三個要求的假設，其中包括以下三個方面：

Consistency： 一致性 從不一樣節點讀取的數據一致。一致性是指數據的原子性，在經典的數據庫中經過事務來保障，事務完成時，不管成功或回滾，數據都會處於一致的狀態，在分佈式環境下，一致性是指多個節點數據是否一致。

Availability： 可用性是指服務及時非錯誤地響應，服務一直保持可用的狀態，當用戶發出一個請求，服務能在必定的時間內返回結果，響應可終止、不會一直等待。

Partition tolerance：分區容錯性便可靠性。可靠性的量化指標是週期內系統平均無端障運行時間. 即便有些消息延遲或者沒法到達，並不影響系統的總體運行。簡而言之，在網絡分區的狀況下，被分隔的節點仍能正常對外服務。

和全部分佈式系統同樣，區塊鏈共識算法設計也是在權衡上面的三個因素，假如區塊鏈中節點能當即確認交易數據，好處是不依賴其餘節點當即可用，知足了 CAP 理論中的 AP，可風險是失去了強一致性，其餘節點可能丟棄這個區塊，由於區塊所在的區塊鏈分叉在競爭性的選舉中失敗了[5]。 爲了得到 CP，客戶端應該等待區塊鏈大多數節點接受了這筆交易在真正接受它， 說明這筆交易所在分叉已經選舉勝利，得到大部分共識，得到了強一致性，可是風險是可能unavailable ，喪失 CAP 的 A，由於網絡分區通訊等問題可能阻止這種共識。

研究定位

區塊鏈系統是一個將交易數據正確地固化在分佈式節點上的系統。共識算法爲了解決如何更安全有效的將交易數據寫入到區塊鏈上，本質上講，共識算法旨在解決如下問題：

• 哪一個服務節點有權利生成下一個用新區塊？

• 上一個區塊與下一個區塊之間應如何銜接

• 下一個區塊什麼時間產生？

• 區塊中應該包含了哪些內容？

• 區塊的大小是多少，一個區塊中包含多少交易數據？

• 確認機制若是解決區塊鏈分叉的問題？

本文檔從多個角度分析不一樣共識算法關於以上問題的解決方案，旨在爲未來實際算法設計提供相關理論參考,分析方法爲如下兩點：

• 縱向分析：咱們以一個交易的被確認的完整過程，勾畫出整個區塊鏈系統的工做過程，縱向的分析共識算法在整個區塊鏈系統中所扮演的角色。

• 橫向對比：咱們陳列出當前加密貨幣中經常使用的共識算法，如 POW,POS,DPOS,PBFT 等，而後從算法的一致性，容錯性，網絡組織狀況等方面進行對比分析。

縱向定位分析

研究共識機制旨在設計更安全，高效的區塊產生方案。爲了讓讀者更加清晰的認識共識算法在整個區塊鏈中所扮演的角色，在本章中咱們勾畫出區塊產生的完整週期，並用以比特幣的例子詳細的講解區塊產生的過程。

圖 2. 交易數據在區塊鏈中被確認的過程

圖 2 中展現了交易數據在區塊鏈中一個完整的流轉過程，在起始階段，交易信息被客戶端組裝， 其中交易信息包含了交易的輸入金額，輸入帳戶信息和輸出帳戶信息等，客戶端能夠被認爲是 全節點錢包，輕錢包和各大交易平臺。在一個完整的交易被生成後被稱爲「原始交易（Raw

Transaction）」。 原始交易並不能被礦機接收，由於缺少相應轉帳人的簽名。在轉帳人簽名完成後容許將其廣播到區塊鏈系統中，礦機採集相關交易後，通過共識算法將交易數據打包並確認到對等網絡中的其餘節點上。下面咱們以比特的例子詳細闡述以上過程。

交易數據的組裝

假設用戶 A 給用戶 B 進行轉帳，用戶 A 的的公鑰爲 Pk_a，私鑰爲 Pr_b, 用戶 B 的的公鑰爲Pk_b，私鑰爲 Pr_b. 咱們按照表 1 給出的協議一步一步的給出最終可廣播的內容。備註: 如下數據均爲十六進制表示，咱們採用比特幣中最經常使用的 Pay-to-PubkeyHash 進行分解。通過客戶端的數據組合，咱們展現一個完整的交易協議以下，其中輸入數據 inputs 數據能夠從UTXO（Unspent Transaction Output，未開銷的比特幣交易輸出）中獲取。

表 1. 比特幣原始區塊鏈交易協議

	Version (版本)		01000000
	Input count (輸入長度)		01 |
	inputs	previous output hash (上一個腳本的 hash)	be66e10da854e7aea9338c1f91cd4897 68d1d6d7189f586d7a3613f2a24d5396 |
	inputs	previous output index (上一個交易的索引)	00000000 |
	inputs	scriptSig length (表示腳本的長度)	19 |
	inputs	scriptSig(腳本簽名，實際此部分爲腳本的前半部分)	76a914010966776006953d5567439e5e 39f86a0d273bee88ac |
	inputs	Sequence （序列）	ffffffff |
	outputs count (輸出長度)		01 |
	outputs	Value (須要轉出的比特幣的值，上面的輸入的值減去)	605af40500000000 |
	outputs	script length (表示腳本的長度）	19 |
	outputs	script(腳本簽名，實際此部分爲腳本的先後半部分)	76a914097072524438d003d23a2f23ed b65aae1bb3e46988ac |
	lock time (鎖定時間)		00000000 |

交易數據的簽名

交易數據的完成組裝後並不能當即被礦機所接受，由於交易的輸出方並無對其進行有效的簽名，咱們用 sha256 總體對上面的數據的 hash 進行簽名，咱們假設發送者的公鑰是 Pk_a, 簽名後的結果爲 Sig_a. 爲更好的理解簽名後在區塊鏈中執行的過程，咱們將上面 inputs 中的scriptSig 進行分解76a914010966776006953d5567439e5e39f86a0d273bee88ac 分解後的內容以下表格,表 2. 未簽名的 ScriptSig 數據格式分解，備註數字與操做符的對應關係能夠經過https://en.bitcoin.it/wiki/Script 查詢到,ScriptSig 格式以下：

	OP_DUP	76
	OP_HASH160	a9 |
	length	14 |
	pubKeyHash	010966776006953d5567439e5e39f86a0d273bee |
	OP_EQUALVERIFY	88 |
	OP_CHECKSIG	ac |

通過簽名以後咱們將簽名後的數據銜接在 ScriptSig 上面，所以最終的 ScriptSig 變成以下格式。表 3. 簽名後的 ScriptSig 數據格式分解。

	Sig_a	Sig_a.
	Pk_a	Pk_a |
	OP_DUP	76 |
	OP_HASH160	a9 |
	pubKeyHash	14010966776006953d5567439e5e39f86a0d273bee |
	OP_EQUALVERIFY	88 |
	OP_CHECKSIG	ac |

比特幣的區塊鏈中採用的是堆棧式的語言，ScriptSig 的執行過程描述以下 ：

	堆棧	腳本	描述
	空	Sig_a \	Pk_a | OP_DUP | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | 將 Sig_a 和 Pk_a 拋出 |
	Sig_a \	Pk_a	OP_DUP | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | 將常量加入到堆棧中 |
	Sig_a \	Pk_a\	Pk_a | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | OP_DUP 做用是複製 Pk_a， 目前狀態堆棧中有兩個 Pk_a |
	Sig_a \	Pk_a\	Pk_a_hash | pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | OP_HASH160 的做用是計算出最頂層 stack 的 hash |
	Sig_a \	Pk_a\	Pk_a_hash |pubKeyHash | OP_EQUALVERIFY | OP_CHECKSIG | 將 pubKeyHash 推入堆頂 |

	Sig_a \	Pk_a	OP_CHECKSIG	OP_EQUALVERIFY 是檢查棧頂的兩個值是否相同
	true	空	OP_CHECKSIG 做用是檢查棧頂的簽名是否正確，正確則返回 true

交易數據的廣播

在原始交易組裝完成後，講交易進行廣播出去。非嚴格意義上講，消息廣播出去分爲兩種形式：直接調用 API，自身加入 P2P 節點。

交易數據打包確認

交易數據的打包和確認非正式術語稱爲「挖礦」，進行挖礦以前，首先要將交易合併在區塊中， 區塊對於交易的數據打包採用的 Merkle tree 算法。將多個交易的 hash 合併到樹中，而後將Tree 的樹根合併到塊中。

須要說明的是在區塊中不只僅含有 Merkle root ，還有其餘的輔助信息如圖 4 所示。共識機制做用於此部分，共識算法旨在將上面的 Merkle Root 所在的區塊銜接在上一個區塊中，不一樣的區塊鏈產品所採用的共識算法不一樣，咱們將在下面的章節中選取典型的算法進行分析。

縱向分析總結

宏觀上講，共識算法做用於圖 4 中的打包確認階段，共識算法負責將交易數據打包到新的區塊中，同時負責將該區塊銜接到以前的鏈上。微觀上從服務節點的角度上講，共識算法包括 4 個階段，以下圖 5 所示，分發階段，驗證階段，挖礦階段，宣佈階段。礦機在分發階段進行對交易進行收集，驗證階段開始驗證交易的正確性，通過驗證的交易在挖礦階段進行確認，而後在T5 階段進行下一輪的共識。

橫向對比分析

在本章中咱們選取了的業界經常使用的共識算法進行分析，這些共識算法包括工做量證實POW, 權益證實 POS, 受權股權證實 DPOS, 瑞波共識算法 RC 和用於 Hyperledger 的拜占庭算法 PBFT。在工做量證實 POW 中咱們會以 Bitcoin 和 Ethereum 中不一樣的 POW 作闡述；權益證實 POS 主要以點點幣爲表明進行分析；受權股權證實 DPOS 分別以Bitshares 和 Casper 算法進行講解；瑞波共識算法 RC 和 拜占庭算法 PBFT 的分析依附於瑞波加密貨幣和 Hyperledger。同時在本章節的最後咱們會從網絡組織，算法的效率和貨幣的發行機制等多個方面進行橫向分析。

工做量證實 POW

工做量證實 POW（Proof-of-work）最先由 Markus Jakobsson 在反垃圾郵件系統實現中提出[6]。反垃圾郵件系統可以使垃圾郵件發送者須要更多的時間來發送郵件，就能夠增 大他們的成本， 起到抵擋攻擊的做用。2008 年被中本聰在論文《a peer to peer electronic cash system》[1] 中再次說起並使用，其設計理念是整個系統中每一個節點爲整個 系統提供計算能力(簡稱算力)，經過一個競爭機制，讓計算工做完成最出色的節點得到系統的獎勵， 完成新生成貨幣的分配。

目前採用 POW 的算法表明有 Bitcoin 和 Ethereum（早期版本），他們雖然同時都成爲POW，並都採用全節點競爭的方式對交易進行確認，但算法本質卻大相徑庭。咱們下面將對兩個系統不一樣的 POW 算法進行分析。

Bitcoin的POW 算法分析

下面咱們採用一個例子來描述在比特幣中挖礦的過程。 上面的區塊產生的過程章節中已經對下面的參數進行了交代，黃色的部分是塊頭，他將隨着交易一塊兒被被打包到區塊鏈，第一個交易稱爲 coinbase ， coinbase 是用來獎勵礦工的，它的具體的工做原理是coinbase收斂「正常交易」中的交易費組成一個新的交易，而後交易指向礦工的地址「正常交易」只指用來轉移比特幣用的交易。

圖 6. 比特幣區塊結構圖

Bitcoin 的 POW 核心機制是找 hash 碰撞, 從上面的分析咱們知道，區塊鏈是一個持續增加的順序塊組成的，區塊鏈是密碼上的安全，對於每一輪只要找到相應的 hash 的碰撞就算成功， hash 碰撞的意思能夠理解爲 hash 值的前多少位相同，咱們知道何難找到兩個 hash 如出一轍的文件，但咱們能夠找到前幾位相同的，咱們將一個完整的挖礦過程整理以下：

f(Di)>SHA256(SHA256(Hi−1||Ti||TXi||di||Ni)))

Hi−1 表示上一個區塊的 HASH，Ti 表示時間戳，di 表示本輪的難度，Ni 表示須要找出的隨機數。咱們從下圖 7（比特幣的官網上截取）能夠清晰的看出上一個區塊和下一個區塊之間的關係。直觀上講，下一個區塊比上一個區塊前面多個一個 0，就是前 N 位對撞成功。

Ethereum 的 Pow 算法分析

以太坊 Etherum 目前採用的是 Ethash 算法，最初設計的目標是「GPU 友好，阻斷 ASIC」鼓勵一個機器一票，抵制大型的集成電路挖礦，Ethash 是基於一個固定的只讀數據集的隨機路徑，受啓發與內存限制的工做證實謎題和相關的學術著做。Ethash 所使用的定製隨機功能是非標準的，難以進行密碼分析，但它們能夠進行簡單的統計測試。算法的主題思路是從緩存獲得固定數據集容易，反之十分困難，完整的算法描述以下：

固定數據集合代碼 :

緩存集合代碼 :

權益證實機制 POS

POS (Proof of Stake) 即權益證實機制，最先出如今點點幣的白皮書中 [7]，其核心思想是將貨幣持有人的數目和持有的時間累計做爲被選爲共識節點的資本。

協議描述

這種新型區塊裏 POS 是一種特殊的交易稱利息幣(coinstake)（依據 BTC 當中的一類特殊交易：幣基 coinbase 而命名，如上圖 6 中所說起）。在利息幣(coinstake) 交易中，區塊持有人能夠消耗幣齡得到利息，同時得到爲網絡產生一個區塊和用 POS 造幣的優先權。利息幣的第一個輸入被稱爲核心（Kernel），並須要符合某一 Hash 目標協議。由此 POS 區塊的產生具備隨機性，這一過程與 POW 類似。但有一個重要的區別在 POS 隨機散列運算是在一個有限制的空間裏完成的（具體來講爲 1 hash / 未消費錢包的輸出*秒），而不是像 POW 那樣在無限制的空間裏尋找，所以無需大量的能源消耗。

權益核心(kernel)所要符合的隨機散列目標是以在覈心中消耗幣齡的目標值（幣* 天 coin-day） 這與 BTC 的 POW 是不一樣的，BTC 的每一個節點都是相同的目標值。 所以核心消耗的幣齡越多， 就越容易符合目標協議。

點點幣源碼地址：https://github.com/peercoin/peercoin/blob/master/src/kernel.cpp

受權股權證實機制 DPOS

受權股權證實機制 (Delegated Proof of Stake) 是一種新的共識算法，有程序員 Daniel Larimer 提出 [8]，旨在優化 POW 和 POS 中的問題，這些問題集中在共識效率和嚴重集中化上。DPOS 使用技術民主用來抵消集中化的負面影響。

解決集中化的問題：

受權股權證實機制經過使用證人（稱爲表明）減輕集權化的潛在負面影響。總共 N 名證人簽署了這些區塊，並由分散在 P2P 網絡的節點進行投票，並進行了每一筆交易。經過使用分散的投票程序，DPOS 的設計比同類系統更加民主。每一個被簽名的區塊在被接收信任節點簽名以前都要被檢驗。

解決共識效率的問題：

DPOS 消除了在肯定事務以前必須等待必定數量的不可信節點進行驗證的過程。這減小了對確認的需求，提升了交易速度。經過網絡決定，經過有意向最可信賴的潛在的塊簽名者進行信任， 不須要施加人爲的負擔來減緩塊簽名過程。 DPOS 容許將多個事務包含在塊中，而不是工做證實或證據證實系統。DPOS 系統中的每一個客戶端都有能力決定誰是信任的，而不是將信任集中在資源最多的人手中。在受權的證據證實系統集權仍然發生，但它是受控制的。與其餘保護密碼安全網絡的方法不一樣，

DPOS 系統中的每一個客戶端都有能力決定誰是信任的，而不是將信任集中在資源最多的人手中。DPOS 容許網絡得到集中化的一些主要優勢，同時仍然保持一些計算的權力下放衡量標準。這個制度是經過公正的選舉程序執行的，任何人均可能成爲大多數用戶的表明。下面咱們選取了BitShares 和 Ethereum 的 DOPS 算法進行簡要分析。

BitShares 算法分析

BitShares 是第一個提出並採用 DPOS 的分佈式帳本 [8]。按照它的設計原則分類賬本必須按照正確的順序進行驗證和確認。以保證數據庫的的一致性和廣泛確認。

協議描述

在現實生活中見證人發揮着中立擔保的做用。例如一份重要的合同簽證每每須要公共仲裁機構的擔保。在 BitShares 系統中，見證人擔任着相同的角色，因爲它能夠驗證簽名和交易中的時間戳信息。

在 BitShares 系統設計中，利益相關者能夠選舉必定數量的見證人來生成區塊。每一個帳戶容許對每一個見證人投一票，這個投票的過程被稱爲「批准投票」。選擇出來的 N 個見證人被認爲是對至少 50％的投票利益相關者的表明。每次見證人產生一個區塊，見證人將獲得必定的獎勵，若是見證人由於違規沒有生成區塊，將不能到獎勵，而且會被加入「黑名單」，再次獲取 見證人的機會將會大大下降。

每組見證人的活躍狀態在每個週期將會被更新，這個週期的一般設置爲 1 天，隨後這組見證人將會被解散。每一個見證人給一個 2 秒的流起色會用來區塊，當全部的見證人被流轉完成，改組見證人也會被解散，若是一個見證人在它的時間週期內沒有產生區塊，他的時間機會將會被錯過，下一個見證人將產生下一個區塊。任何節點均可以經過觀察證人蔘與率來監控網絡健康情況。歷史上 BitShares 曾經維持了 99％的見證參與。

表明們以相似證人的方式當選。表明成爲特權賬戶的共同簽署者，該賬戶有權提出對網絡參數 的更改。這個賬戶被稱爲起源賬戶。這些參數包括從交易費用到塊大小，見證支付和塊間隔的 一切。在大多數表明批准了一項擬議的變動後，利益相關者將得到 2 周的審查期間，在此期間， 他們能夠對錶明進行投票，並根據建議變動或者取消。選擇這種設計是爲了確保表明在技術上 不具備直接的權力，全部對網絡參數的更改最終都獲得利益相關者的批准。這樣作是爲了保護 表明免受可能適用於加密貨幣的管理者或管理員的規定。在 DPOS 下，咱們能夠真正地說， 行政權力由用戶掌握，而不是表明或證人。

Casper 算法分析

Casper 是近期 Ethereum 改進型方案。下面咱們簡單的描述下 Casper 算法。

咱們給出如下定義, b（block）表示每一個塊，c (checkpoint)表示檢查點,其中b和c的關係能夠表示成下圖：

C0 被定義爲起始指針，一個「紀元」被定義爲兩個檢查點之間的連續的塊序列，這個塊序列包括後面的檢查點，而不是較早的檢查點。塊的「紀元「是包含該散列的歷元的索引，例如， 區塊 599 的紀元爲 5。

每一個表明都須要提交必定的準備金，和現實的世界同樣，這份準備金直接關係到未來的獎勵和違規罰金。系統中所說起的 2/3 的驗證者，實際並非 2/3 的節點，而是指擁有 2/3 保證金的節點。表明能夠廣播兩種類型的消息，第一種爲「準備消息」顯示格式爲 <prepare, h, e, h, e, S> ， 其中的含義以下圖所示。

「準備消息」 的內容描述 :

	符號	描述
	h	檢查點的 hash |
	e	檢查點的紀元 |
	h*	最近調整的 hash |
	e*	h* 的紀元 |
	S	每一個表明的簽名 |

另外一種爲「提交消息」 顯示格式爲 <commit, h, e, S> , 下表「提交消息」的含義描述

	符號	描述
	h	檢查點的 hash |
	e	檢查點的紀元 |
	S	每一個表明的簽名 |

協議描述

一個檢查點 h 知足如下條件是被認爲是「調整過的」，這個階段能夠認爲是選舉的階段。

• 2/3 的準備金持有表明已經發出 <prepare, h, e, h, e, S>消息

• h 自身被調整

一個檢查點 h 知足如下條件是被認爲是「被確認成功的」。這個階段能夠認爲是共識階段。

• h 被調整

• 2/3 的準備金持有表明已經發出<commit, h, e, S>消息

須要指出的是調整 h 時候有超過 2/3 表明的消息中必須含有相同的 h*. 同時起始指針 C0 默認爲是已經調整和已經確認過的。

協議規定

Casper 的創新點在於不可能兩個衝突的檢查點同時被確認，除非有超過 1/3 的人違反了規定， 規定的內容以下：

• 表明不得在同一紀元發佈兩個或多個不一致的準備消息。換句話說，一個表明在一個紀元只能發佈一個準備消息。

• 表明不能在同一個紀元發佈確認消息早於準備消息。言外之意，確認消息必定晚於準備消息。

若是表明違反了上面的協議，準備金將所有被沒收，用來獎勵發現它違規的見證人。咱們給出一個理想的例子，在紀元 n 期間,全部的表明準備好 Cn h* = Cn-1 同時提交了 Cn。

瑞波共識機制 RCA

RCA 即瑞波公式算法（ripple consensus algorithm），在分佈式支付系統老是會出現因爲網絡中全部節點同步通訊的要求致使節點遭受高延遲的問題 [9] 。瑞波共識算法經過在較大的網絡中利用集體可信的子網來解決這些問題。下面咱們將詳細的解讀瑞波共識算法.

參數定義

服務節點（Server）： 服務節點能夠是 P2P 網絡中的任意一個，用來參與共識算法。帳本

（Ledger）：用來記錄交易記錄的數據庫。帳本有服務節點在完成共識以後進行維護。最後 一個關閉的帳本（Last-Closed Ledger）：通過公式算法寫入的帳本，最近寫入的帳本，表明了網絡中帳本的最新狀態。活動帳本（Open Ledger）：每一個節點上會維護一個活動帳本， 共識的過程就是將活動帳本變爲最後一個關閉的帳本的過程。獨特節點列表（Unique Node

List）：每一個服務節點都會維護這一組服務節點列表，服務列表中的服務節點是被認爲是未來有能力進行選舉算法的， 咱們能夠認爲這些服務節點組成的網絡是可信網絡。提案人

（Proposer）：任何服務器均可以廣播交易，在一次交易循環開始的時候，每一個服務器都嘗

試着確認有效的交易，可是在這個確認過程當中，只有服務上的獨特節點列表的服務器確認的纔有效。

協議描述

第一步：全部的服務節點採集有效的交易，並將這些交易打包成一個「候選交易集合」。

第二步：每一個服務節點上的 UNL 合併「候選交易集合」，並驗證「候選交易集合」的真實性。

第三步：候選交易集合中的集合只有在收集到 UNL 足夠的認同後才能被選中，若是沒有得到足夠的認同，將被丟棄或者做爲新一輪的候選交易。

第四步： 一個交易須要 80%的服務節點上的 UNL 贊成，全部知足要求的交易才容許掛載到鏈上。一旦掛載成功，當前的鏈自動關閉。

詳細過程

以下圖所示：每一個區塊中都包含了帳本序號，帳戶信息，交易信息，時間戳等信息。整個帳本每隔幾秒會生成一個新的帳本，一個新的帳本用帳本序號進行標識。假如當前的帳本的序號爲

N，則前一個帳本的序號爲 N-1，下一個帳本的 N+1。

瑞波網絡由接受和處理事務的分佈式服務器（稱爲節點）和客戶端應用程序組成。客戶端應用程序向節點進行簽名和發送交易，客戶端應用程序包括錢包和金融機構的電子交易平臺。

接收，中繼和處理事務的節點能夠是跟蹤節點或驗證節點。跟蹤節點的主要功能包括分發來自客戶端的事務和響應關於帳本的查詢。驗證節點執行與跟蹤節點相同的功能，並另外有助於推動帳本序列。在接受客戶應用程序提交的交易時，每一個跟蹤節點使用最後一個驗證的帳本做爲起點。

網絡上的節點共享關於候選交易的信息。經過協商一致的過程，驗證節點就下一個帳本考慮的候選交易的特定子集達成一致。共識是一個迭代過程，其中節點轉發提案或一組候選事務。節點溝通和更新建議，直到超過多個對等節點（80%以上，可調整）贊成一組候選交易。這個 過程決定了哪些交易被接受，哪些交易被拋棄或者被載入到下一輪提案中。在交易選擇過程當中付出交易費用更多的節點更容易被接受。

當一組交易完成的時候，交易蔓延到不一樣的節點並進行簽名，當收集到足夠多的節點的時候， 當前的備選交易將被打包到區塊鏈中。若是網絡節點在交易繁忙或者交易共識將很難被達成， 此時算法能夠自主調節交易費用和等待時間。

總結

咱們將一個完整的交易週期總計以下：

	步驟	描述
	1. 一個交易被建立而且被簽名	|
	2. 交易信息被提交到網絡中	錯誤的格式的交易，將直接被拒絕 正確格式的數據暫時會被拒絕，可能下一輪 會被確認。 |
	3. 通過共識算法，交易將被打包到帳本中	驗證成功的交易被加入到帳本中。 |

瑞波共識算法面臨中心化的問題，使一組節點可以基於特殊節點列表達成共識。初始特殊節點列表就像一個俱樂部，要接納一個新成員，必須由 51%的該俱樂部會員投票經過。共識遵循這核心成員的 51%權力，外部人員則沒有影響力。因爲該俱樂部由「中心化」開始，它將一直是「中心化的」，而若是它開始腐化，股東們什麼也作不了。與比特幣及點點幣同樣，瑞波 系統將股東們與其投票權隔開，並所以比其餘系統更中心化。

拜占庭共識機制 PBFT

PBFT（Practical Byzantine Fault Tolerance），意爲實用拜占庭容錯算法，是目前最經常使用的 BFT 算法之一。該算法是 Miguel Castro (卡斯特羅)和 Barbara Liskov（利斯科夫）在

1999 年提出來的，解決了原始拜占庭容錯算法效率不高的問題，將算法複雜度由指數級下降到多項式級，使得拜占庭容錯算法在實際系統應用中變得可行。下面咱們來分析這個算法。

參數定義

• client：客戶端，發出調用請求的實體

• view：視圖，內容爲連續的編號

• replica：網絡節點

• primary：主節點，負責生成消息序列號

• backup：支撐節點，輔助總體共識過程

• state：節點狀態

協議描述

PBFT 算法要求整個系統流程要在同一個視圖（view）下完成，全部節點採起一致的行動。一個客戶端會發送請求<REQUEST, o ,t, c>給 replicas。其中，o 表示具體的操做，t 表示

timestamp，給每個請求加上時間戳，這樣後來的請求會有高於前面的時間戳。Replicas

接收到請求後，若是驗證經過，它就會將其寫入本身的 log 中。在此請求執行完成後，

replicas 會返回 client 一個回覆 <REPLY,v,t,c,i,r>，其中：v 是當前的 view 序號，t 就是對應請求的時間戳，i 是replica 節點的編號，r 是執行結果。每個replica 會與每個處於active 狀態的 client 共享一份祕鑰。祕鑰所佔據空間較少，加上會限制 active client 的數量，因此沒必要擔憂之後出現的擴展性問題。

PBFT 採用三階段協議來廣播請求給 replicas ： pre-prepare, prepare, commit 。pre-prepare 階段和 prepare 階段用來把在同一個 view 裏發送的請求排序，而後讓各個 replicas節點都承認這個序列，照序執行。prepare 階段和 commit 階段用來確保那些已經達到commit 狀態的請求即便在發生視圖改變（view change， 以後會提到）後，在新的 view 裏依然保持原有的序列不變，好比一開始在 view 0 中，共有 req 0， req 1， req2 三個請求依次進入了 commit 階段，假設沒有惡意節點，那麼這四個 replicas 即將要依次執行者三條請求並返回給Client。但這時主節點問題致使 view change 的發生，view 0 變成 view 1，在新的 view 裏，本來的 req 0，req1， req2 三條請求的序列將被保留。可是處於 pre-prepare 和 prepare 階段的請求在 view change 發生後，在新的 view 裏都將被遺棄。

pre-prepare 階段

主節點收到來自 Client 的一條請求並分配了一個編號給這個請求，而後主節點會廣播一條<<PRE-PREPARE,v,n,d>, m>信息給備份節點，這裏 v 是視圖編號，m 是客戶端發送的請求消息，d 是請求消息 m 的摘要（digest）。該信息會送達到每個備份節點，收到信息的備份節點會進行一系列驗證，驗證經過後會 accept 這條 PRE-PREPARE 信息。驗證內容主要爲：

• 請求和預準備消息的簽名正確，而且 d 與 m 的摘要一致。

• 當前視圖編號是 v。

• 該備份節點從未在視圖 v 中接受過序號爲 n 可是摘要 d 不一樣的消息 m。

• 預準備消息的序號 n 必須在水線（watermark）上下限 h 和 H 之間（水線存在的意義在於防止一個失效節點使用一個很大的序號消耗序號空間）。

當一個備份節點 accept 了這條 PRE-PREPARE 後，它就會進入下面的 prepare 階段。

prepare 階段

一個備份節點進入到本身的 prepare 階段後，開始將一條信息<PREPARE,v,n,d,i>，廣播給主節點和其它的備份節點，與此同時，該備份節點也會收到來自其它備份節點的 PREPARE 信息。該備份節點將驗證消息的簽名是否正確，視圖編號是否一致，以及消息序號是否知足水線限制， 而後綜合驗證信息作出本身對編號 n 的最終裁決。若是驗證經過，則把這個準備消息寫入消息日誌中。當一個備份節點收到來自至少 2/3 個節點的準備消息，而且驗證請求消息一致時，那麼咱們就說該請求在這個節點上的狀態是 prepared， 同時該節點也擁有了一個證書叫prepared certificate 。

commit 階段

緊接着 prepare 階段，當一個 replica 節點發現有一個 quorum 贊成編號分配時，它就會廣播一條 COMMIT 信息給其它全部節點告訴他們它有一個 prepared certificate 了。與此同時它也會陸續收到來自其它節點的 COMMIT 信息，若是它收到了至少 2/3 條 COMMIT 後，咱們就說該節點擁有了一個叫 committed certificate 的證書， 請求在這個節點上達到了committed 狀態。此時只經過這一個節點， 咱們就能判定該請求已經在一個有效團體（quorum）中到達了 prepared 狀態，即一個有效團體的節點們都贊成了編號 n 的分配。當請求 m 在一個節點中到達 commited 狀態後，該請求就會被該節點執行。

橫向分析小節

本章將從三個角度進行總結：貨幣控制權，貨幣發行機制，以上說起算法的綜合對比。

控制權的爭奪

比特幣的設計之初，系統默認節點和算力是均勻分佈的，由於經過 CPU 來進行投票，擁有錢包(節點)數和算力值應該是大體匹配的，每個比特幣錢包的擁有者都可以參與整個系統的決策機制， 若是有任何人試圖對系統做惡，或者某一部分節點收到損失，均可以讓其餘節點迅速補上，而且只要有 51%的節點(算力)投票就能夠選擇對系統發展更有利的方向。

在實際操做中 POW 的主要問題是算力過於集中的安全風險，這種風險體如今比特幣的控制權上， 挖礦的人和持有比特幣的人已經徹底被隔開，許多礦工可能徹底不瞭解比特幣的生態，甚至不關心比特幣的將來，卻擁有對比特幣的絕對控制權，由於他們是新幣產生的起始點。一種極端的想法，若是幾個大型的礦池聯合在一塊兒，那麼最新發行的幣將囤積，會形成原有幣種的進一步通貨緊縮。簡而言之，比特幣的命運掌握在並不必定關心比特幣命運的人手上，而持有比特幣的人並無控制權。

這就有點像，一個公司的命運並非那些持有公司股份的股東來決定的，而是那些有可能根本不擁有股份，而只要有錢的人來決定的。那些持有比特幣的人徹底沒法對比特幣的將來作出本身的決定。咱們彷彿從中本聰設定的一 CPU 一票的文明世界，一會兒淪爲純粹是靠蠻力，看誰力氣更大的原始社會。

DPOS 機制彷佛又從新把權利歸還到那些持有數字貨幣的人手上。DPOS 機制是讓每個持有 BTS 的人對整個系統資源當表明的人進行投票，而得到最多票數的 101 個表明進行交易打包計算。這個能夠理解爲 101 個礦池，而這 101 個礦池彼此的權利是徹底相等的。那些握着 BTS 選票的人能夠隨時經過投票更換這些表明(礦池)，只要他們提供的算力不穩定，計算機宕機、或者試圖利用手中的權力做惡，他們將會馬上被憤怒的選民踢出整個系統，然後備表明能夠隨時頂上去。

貨幣發行機制

整體而言，目前的共識算法所對應的貨幣發行機制有 3 種：以比特幣爲表明的經過挖礦產生新貨幣，以點點幣爲例子的經過持有者的利息產生新貨幣和以瑞波幣的恆量發行。

POW 的新增機制是「挖礦」，即礦工每完成必定量的計算，有可能得到一塊新 block 中的新增比特幣。這個過程是一個純粹的通脹過程，即無中生有新增比特幣。但得到新增的比特幣有必定的要求，必須全球第一個找出特定的 HASH 值。所以發行機制是算力比例分配的。

POS 和 DPOS 的新增機制是「利息」，即持有必定的 POS 幣必定時間，將得到必定量的固定「利息」。這部分「利息」是新增的幣。只要你持有 POS 幣並開機，你就能得到必定比例的「利息」。所以 POS 體系將新增 POS 幣投放社會的機制，其投向是以已有 POS 幣等比例增長的。

RCA 所對應的瑞波幣爲恆量發行，再也不增發，總髮行量1000 億個，瑞波幣計劃最終向外發行75% 的 Ripple 貨幣供應，並承諾永不增發。用戶在進行每次交易時要花費必定的 Ripple 幣（金額很是很是低，大約是 1/1000 美分），這個交易費不交給任何人，只是憑空消失。所以 Ripple 幣只會愈來愈少，但減小的速度很是慢。瑞波幣是一個不斷通貨緊縮的過程。

共識算法對比

		POW	POS	DPOS	RCA	PBFT
	一致性	最終一致性	最終一致性	最終一致性	最終一致性	強一致性 |
	容許失敗的 節點數目	<=25%	根據不一樣的算 法而定	<=33%	<=20%	<=33% |
	網絡擴展性	高	高	高	高	低 |
	區塊鏈類型	無權限	無權限	無權限	無權限	有權限 |
	交易速度	慢	快	快	極快	慢 |

結論

區塊鏈的共識算法是加密貨幣的核心，良好的區塊鏈算法能夠安全高效的解決分佈式加密貨幣系統中的「雙花」和交易數據一致性的問題，本文從縱向定位分析和橫向分析對比分析多角度研究了不一樣加密貨幣系統中共識算法，旨在爲區塊鏈項目設計本身的共識算法提供理論參考和設計依據。

引用

[1]. S. Nakamoto, 「Bitcoin: A peer-to-peer electronic cash system,」 Oct. 2008

[2]. 「Blockchain.」 Wikipedia. October 15, 2017. Accessed October 17, 2017. https://en.wikipedia.org/wiki/Blockchain.

[3]. RuJia . 「【區塊鏈技術系列】 區塊鏈共識機制總結(上).」 Ehcoo. October 09, 2017. Accessed October 17, 2017. http://www.ehcoo.com/blockchain_confirmation_mechanism.html.

[4]. Towards Robust Distributed Systems, Eric Brewer, 2000

[5]. Anon, (2017). [online] Available at: https://kknews.cc/finance/5m4ye5k.html [Accessed 17 Oct. 2017].

[6]. Jakobsson, Markus, and Ari Juels. 「Proofs of Work and Bread Pudding Protocols(Extended Abstract).」 Secure Information Networks, 1999, 258-72. doi:10.1007/978-0-387-35568-9_18.

[7]. Sunny King, Scott Nadal . PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. August 19th, 2012

[8]. 「Delegated Proof of Stake.」 Graphene Documentation. Accessed October 17, 2017. http://docs.bitshares.org/bitshares/dpos.html.

[9]. David Schwartz, Noah Youngs, Arthur Britto. The Ripple Protocol Consensus Algorithm.2014

[10]. 「The XRP Ledger Consensus Process.」 Ripple. Accessed October 17, 2017. https://ripple.com/build/xrp-ledger-consensus-process/#the-xrp-ledger-protocol-consensus-and-validation.

[11]. 梧桐樹. 「共識算法 區塊鏈實用手冊.」 區塊鏈實用手冊. Accessed October 17, 2017. http://wutongtree.github.io/hyperledger/consensus.

感謝HPB團隊整理。

 

關於我

藍蓮花（汪曉明），微信/QQ：263305605，公衆號：xm123798。朝夕網絡(zhaoxi.co)創始人。致力於推進區塊鏈應用落地。