區塊鏈核心框架

區塊鏈是一個不斷增長的分散式賬本[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 的每個節點都是相同的目標值。 因此核心消耗的幣齡越多， 就越容易符合目標協議。

授權股權證明機制 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.

[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

感謝HPB團隊整理。

關於我

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