NEO共識機制白皮書

一種用於區塊鏈的拜占庭容錯算法

張錚文 erik@vcage.com

摘要

本文提出了一種改進的拜占庭容錯算法，使其可以適用於區塊鏈系統。咱們假設在此網絡中，消息可能會丟失、損壞、延遲、重複發送，而且接受的順序與發送的順序不一致。此外，節點的行爲能夠是任意的：能夠隨時加入、退出網絡，能夠丟棄消息、僞造消息、中止工做等，還可能發生各類人爲或非人爲的故障。咱們的算法對由 𝑛 個共識節點組成的共識系統，提供 𝑓 = ⌊ (𝑛−1) / 3 ⌋ 的容錯能力，這種容錯能力同時包含安全性和可用性，並適用於任何網絡環境。

概述

區塊鏈是一種去中心化的分佈式帳本系統，它能夠用於登記和發行數字化資產、產權憑證、積分等，並以點對點的方式進行轉帳、支付和交易。區塊鏈技術最先是由中本聰在一個密碼學的郵件列表中提出的 [1]，也就是比特幣。此後，基於區塊鏈技術的各類應用紛紛出現，好比基於區塊鏈的電子現金系統、基於區塊鏈的股權交易系統、基於區塊鏈的智能合約系統等。區塊鏈系統與傳統的中心化帳本系統相比，具備徹底公開、不可篡改、防止多重支付等優勢，而且不依賴於任何的可信第三方。

然而，和任何分佈式系統同樣，區塊鏈系統會面臨網絡延遲、傳輸錯誤、軟件錯誤、安全漏洞、黑客入侵等問題。此外，去中心化的特色決定了此係統的任何一個參與者都不能被信任，可能會出現惡意節點，以及因各方利益不一致致使的數據分歧等問題。

爲了防範這些潛在的錯誤，區塊鏈系統須要一個高效的共識機制來確保每個節點都有一個惟一公認的全局帳本。傳統的針對某些特定問題的容錯方法，並不能徹底解決分佈式系統以及區塊鏈系統的容錯問題，人們須要一種可以容忍任何種類錯誤的容錯方案。

比特幣採用工做量證實機制 [1]，很是巧妙地解決了這個問題。可是代價也很明顯，那就是鉅額的電力成本和資源浪費。此外，新的區塊鏈必須尋找到一種與之不一樣的散列算法，用於避免來自比特幣的算力攻擊，如萊特幣採用了與比特幣的 SHA256 不一樣的 SCRYPT 算法。 拜占庭容錯技術是一種解決分佈式系統容錯問題的通用方案 [5]。本文在 Castro 和 Liskov 於 1999 年提出的 Practical Byzantine Fault Tolerance(PBFT)[3] 的基礎上，提出了一種改進的拜占庭容錯算法，使其可以適用於區塊鏈系統。

系統模型

區塊鏈是一個分佈式帳本系統，參與者經過點對點網絡鏈接，全部消息都經過廣播的形式來發送。系統中存在兩種角色：普通節點和共識節點。普通節點使用系統來進行轉帳、交易等操做，並接受帳本中的數據；共識節點負責向全網提供記帳服務，並維護全局帳本。 咱們假設在此網絡中，消息可能會丟失、損壞、延遲、重複發送，而且接受的順序與發送的順序不一致。此外，節點的行爲能夠是任意的：能夠隨時加入、退出網絡，能夠丟棄消息、僞造消息、中止工做等，還可能發生各類人爲或非人爲的故障。 咱們採用密碼學技術來保證消息傳遞的完整性和真實性，消息的發送者要對消息的散列值進行簽名。咱們定義 〈𝑚〉_𝜎𝑖 是節點 𝑖 對消息 𝑚 的電子簽名，D(𝑚)是消息 𝑚 的散列值。若是沒有特殊說明，本文所規定的簽名都是對消息散列值的簽名。

算法

咱們的算法同時提供了安全性和可用性，只要參與共識的錯誤節點不超過 ⌊ (𝑛−1) / 3 ⌋，就能保證整個系統正常運做，其中 𝑛 = |𝑅|表示參與共識的節點總數，𝑅 是共識節點的集合。令 𝑓 = ⌊ (𝑛−1) / 3 ⌋，則 𝑓 就表示系統所允許的錯誤節點的最大數量。因爲實際上全局帳本僅由共識節點來維護，所以系統中的普通節點不參與共識算法，但能夠看到完整的共識過程。 參與共識的節點，須要維護一個狀態表，用於記錄當前的共識狀態。一次共識從開始到結束所使用的數據集合，稱爲視圖。若是在當前視圖內沒法達成共識，則須要更換視圖。咱們爲每個視圖分配一個編號 𝑣，編號從 0 開始，並逐漸遞增，直到達成共識爲止。 咱們爲每個參與共識的節點分配一個編號，從 0 開始，最後一個節點的編號爲 𝑛 − 1。每一輪共識都須要有一個節點來充當議長，其它節點則爲議員。議長的編號 𝑝 由以下的算法來決定：假設當前共識的區塊高度爲ℎ，則 𝑝 = (ℎ − 𝑣) 𝑚𝑜𝑑 𝑛，其中 𝑝 的取值範圍爲 0 ≤ 𝑝 < 𝑛。每一次共識產生一個區塊，並附有至少 𝑛 − 𝑓 個共識節點的簽名。一旦有新的區塊產生，則當即開始新一輪的共識，同時重置 𝑣 = 0。

通常流程

假設系統要求每次產生區塊的時間間隔爲 𝑡，則在一切正常的狀況下，算法按照如下流程執行：

1. 任意節點向全網廣播交易數據，並附上發送者的簽名；

2. 全部共識節點均獨立監聽全網的交易數據，並記錄在內存；

3. 議長在通過時間 𝑡 後，發送 〈𝑃𝑟𝑒𝑝𝑎𝑟𝑒𝑅𝑒𝑞𝑢𝑒𝑠𝑡,ℎ,𝑣,𝑝,𝑏𝑙𝑜𝑐𝑘,〈𝑏𝑙𝑜𝑐𝑘〉_𝜎𝑝〉；

4. 議員 𝑖 在收到提案後，發送 〈𝑃𝑟𝑒𝑝𝑎𝑟𝑒𝑅𝑒𝑠𝑝𝑜𝑛𝑠𝑒,ℎ,𝑣,𝑖,〈𝑏𝑙𝑜𝑐𝑘〉_𝜎𝑖〉；

5. 任意節點在收到至少 𝑛 − 𝑓 個 〈𝑏𝑙𝑜𝑐𝑘〉_𝜎𝑖 後，共識達成併發布完整的區塊；

6. 任意節點在收到完整區塊後，將包含的交易從內存中刪除，並開始下一輪共識；

該算法要求參與共識的節點中，至少有 𝑛 − 𝑓 個節點具備相同的初始狀態：即對於全部的節點 𝑖，具備相同的區塊高度 ℎ 和視圖編號 𝑣。而這個要求很容易達成：經過區塊同步來達到ℎ的一致性，經過視圖更換來達到 𝑣 的一致性。區塊同步不在本文討論範疇，再也不贅述。視圖更換的規則見下文。

節點在監聽全網交易以及在收到提案後，須要對交易進行合法性驗證。若是發現非法交易，則不能將其寫入內存池；若是非法交易包含在提案中，則放棄本次共識並當即開始視圖更換。

交易的驗證流程以下：

1. 交易的數據格式是否符合系統規則，若是不符合則斷定爲非法；

2. 交易在區塊鏈中是否已經存在，若是存在則斷定爲非法；

3. 交易的全部合約腳本是否都正確執行，若是沒有則斷定爲非法；

4. 交易中有沒有多重支付行爲，若是有則斷定爲非法；

5. 若是以上斷定都不符合，則爲合法交易；

視圖更換

當節點 𝑖 在通過 2^𝑣+1 ⋅ 𝑡 的時間間隔後仍未達成共識，或接收到包含非法交易的提案後，開始進入視圖更換流程：

1. 令 𝑘 = 1，𝑣_𝑘 = 𝑣 + 𝑘；

2. 節點 𝑖 發出視圖更換請求 〈𝐶ℎ𝑎𝑛𝑔𝑒𝑉𝑖𝑒𝑤,ℎ,𝑣,𝑖,𝑣_𝑘〉；

3. 任意節點收到至少 𝑛 − 𝑓 個來自不一樣 𝑖 的相同 𝑣_𝑘 後，視圖更換達成，令 𝑣 = 𝑣_𝑘 並開始共識；

4. 若是在通過 2^𝑣+1 ⋅ 𝑡 的時間間隔後，視圖更換仍未達成，則 𝑘 遞增並回到第 2 步；

隨着 𝑘 的增長，超時的等待時間也會呈指數級增長，能夠避免頻繁的視圖更換操做，並使各節點儘快對 𝑣 達成一致。

而在視圖更換達成以前，原來的視圖 𝑣 依然有效，由此避免了因偶然性的網絡延遲超時而致使沒必要要的視圖更換。

流程圖

容錯能力

咱們的算法對由 𝑛 個共識節點組成的共識系統，提供 𝑓 = ⌊ (𝑛−1) / 3 ⌋ 的容錯能力，這種容錯能力同時包含安全性和可用性，並適用於任何網絡環境。因爲節點的請求數據包含發送者的簽名，惡意的共識節點沒法僞造請求，它只能試圖將系統的狀態回退到過去，從而使系統發生「分叉」。

咱們假設系統所在的網絡環境，剛好將全部共識節點分割成 3 個部分，即：𝑅 = 𝑅1 ∪ 𝑅2 ∪ 𝐹，且 𝑅1 ∩ 𝑅2 = ∅，𝑅1 ∩ 𝐹 = ∅，𝑅2 ∩ 𝐹 = ∅。假設 𝑅1 和 𝑅2 都由誠實的共識節點組成，且已造成網絡孤島，各自只能與本身所在集合內的節點通信；𝐹 所有都是惡意共識節點且已經合謀，能夠統一行動；此外，𝐹 的網絡條件容許它們和任意節點進行通信，包括 𝑅1 和 𝑅2。 若是 𝐹 想要使系統發生「分叉」，只需與 𝑅1 達成共識併發布區塊，並在不通知 𝑅2 的狀況下與之達成第二次共識，「撤銷」與 𝑅1 的共識。

若想知足這個條件，需知足：|𝑅1| + |𝐹| ≥ 𝑛 − 𝑓，且|𝑅2| + |𝐹| ≥ 𝑛 − 𝑓。在最壞的狀況下，|𝐹| = 𝑓，即惡意節點的數量達到系統所能容忍的最大值，則上述關係變爲： |𝑅1| ≥ 𝑛 − 2𝑓，且|𝑅2| ≥ 𝑛 − 2𝑓。兩式相加：|𝑅1| + |𝑅2| ≥ 2𝑛 − 4𝑓，化簡後：𝑛 ≤ 3𝑓。已知 𝑓 = ⌊ (𝑛−1) / 3 ⌋ ，與上式矛盾，故可證實系統在容錯範圍內沒法被分叉。

參考文獻

[1] Nakamoto S. Bitcoin: A peer-to-peer electronic cash system[J]. 2008.

[2] Lamport L, Shostak R, Pease M. The Byzantine generals problem[J]. ACM Transactions on Programming Languages and Systems (TOPLAS), 1982, 4(3): 382-401.

[3] Castro M, Liskov B. Practical Byzantine fault tolerance[C]//OSDI. 1999, 99: 173

[4] Bracha G, Toueg S. Asynchronous consensus and broadcast protocols[J]. Journal of the ACM (JACM), 1985, 32(4): 824-840.

[5] 範捷, 易樂天, 舒繼武. 拜占庭系統技術研究綜述[J]. 軟件學報, 2013, 6: 012.

原文連接：docs.neo.org/zh-cn/basic…