NEXT社區小課堂 | 第四課：dBFT 2.0詳解 | 委託拜占庭容錯：技術細節、挑戰和前景

NEXT社區 | 小課堂

因爲近期NEXT社區加入不少新的小夥伴，有在校大學生，有對區塊鏈感興趣的傳統企業從業者。爲了更方便、更系統的讓NEXT社區的夥伴們瞭解NEO的技術知識，所以咱們開設了小課堂，每週3節，向你們普及NEO相關的知識要點！

 

NEXT社區小課堂 | 第四課

dBFT 2.0詳解

委託拜占庭容錯：技術細節、挑戰和前景

 

針對部分同步和徹底異步的拜占庭容錯系統 的相關研究文獻有不少; 可是能真正應用於真實的不一樣種類的去中心化應用智能合約（SC）場景的研究卻不多。值得注意的是，與涉及狀態機複製(Schneider 1990)的智能合約交易持久化需求相比，更新存儲狀態的應用程序會帶來不同的挑戰。

此外，要考慮的第二個重要事實與帳本信息更新後的肯定性有關。終端用戶、商家和交易所都但願能明確地知悉他們的交易是否已獲得處理或者是否有可能被回退。與先前文獻中的大部分研究不一樣，NEO區塊鏈在第一層網絡上提出了一種具備一區塊最終確認性的共識機制 。除了在實際案例應用中廣爲人知的優點以外，這個特性也帶來了一些額外的限制、漏洞和挑戰。

本技術材料的目的是強調從經典的實用拜占庭容錯機制(pBFT)到當前NEO區塊鏈核心庫所採用的委託拜占庭容錯機制(dBFT)所作的關鍵性修改。此外，文中還描述了一種新穎的數學模型，該模型可以經過離散模型來驗證特定的共識行爲，而該離散模型可以對實際情景下的共識行爲進行建模。

本文在強調當前NEO共識機制的積極方面的同時，也旨在指出可能存在的缺陷以及將來的研究和發展方向。後者能夠經過將NEO的需求及其新穎的理念與文獻中衆所周知的一些研究相結合來實現。

 

1、實用型BFT背景

Miguel Castro和Barbara Liskov(參見圖1)在其論文 「實用型拜占庭容錯」 （Castro and Liskov 1999）中首次提出了實用型BFT的概念。

 

圖1：圖靈獎得到者Barbara Liskov, 2010. 維基百科CC BY-SA 3.0

 

給n=3f+1定個狀態機的副本,狀態機由主節點和備份節點組成, 所給出的算法能夠確保網絡的活躍性和安全性，假定發生故障或拜占庭的節點數不超過f。

• 安全性能夠保證全部進程將以原子操做的方式進行，即要麼在全部的節點上執行，要麼總體都回退。因爲進程的肯定性（已經在全部節點上執行），這種可能性是存在的，總的來講，這種可能性也一樣存在於NEO網絡和區塊鏈協議。

• 活躍性保證網絡不會中止(除非拜占庭節點數超過f),經過使用一種稱爲「更改視圖」的機制,容許在可能發生拜占庭時將備份節點切換成主節點。經過使用超時機制，並在每一個視圖上成倍地增長延遲時間，PBFT機制能夠防止惡意網絡延遲的攻擊，這種網絡沒法無限期地運做。在當前的公式中，假定當前的視圖編號爲n，則將產生區塊的週期時間t左移n位後所獲得的結果即超時發生的時間。

 

例如：

– 產生區塊的週期爲15秒: 15 << 1爲30s (視圖編號爲1);15 << 2爲60s;15 << 3爲120s;15 << 4爲240s。 – 產生區塊的週期爲1秒: 1 << 1 爲 2s;1 << 2爲4s;1 << 3爲8s;1 << 4爲16s。

基於PBFT機制的網絡假定「可能沒法傳遞消息、延遲消息、複製消息或無序地傳遞消息」。同時使用公鑰加密對副本進行身份驗證，對於NEO 的dBFT算法而言也是如此。因爲算法不依賴同步來保證安全性，所以必須依賴於同步來保證活躍性。

對於拜占庭協議(Bracha和Toueg 1985)而言，節點數爲3f+1這一設定具備最佳的彈性，其中惡意節點數不超過f。

 

PBFT正確性的確保主要分爲三個階段：預準備、準備和確認。

 

• 在預準備階段，主節點會發送一個序列號k以及消息m和簽名摘要d。若是簽名正確，k是有效間隔，而且備份節點i沒有接受過相同k值和相同視圖下的預準備信息，那麼i將進入預準備階段。

• 進入預準備階段後，備份節點將全網範圍內廣播一條準備消息(包括向主節點發送廣播),而且對於同一個視圖而言，當節點收到與本地預備階段相匹配的準備消息條數很多於2f時，則代表該節點已經處於準備階段。所以，對於給定的視圖，非故障的複製節點已經就請求的總體順序達成一致。一旦2f+1個非故障節點準備就緒，網絡就能夠進入確認階段。

• 每一個確認階段的複製節點會廣播一條確認消息,一旦節點i收到2f+ 1條確認信息,則代表該節點已經處於本地已確認（committed-local）階段。最終，即便視圖發生更換，具備本地已確認節點的系統也會完成確認。

 

PBFT機制認爲客戶端直接與主節點進行交互並廣播消息，同時接收來自2f+ 1個節點的獨立響應以便向前推動(執行下一個操做)。NEO區塊鏈也存在相似的狀況，其中信息經過點對點的網絡進行傳播，可是在NEO區塊鏈網絡中，共識節點的位置是未知的(爲了防止直接延遲攻擊和拒絕服務)。在PBFT中，客戶端會在不一樣的時間戳上提交原子且獨立的操做，這些操做是獨立處理和發佈的。

而NEO區塊鏈則不一樣，共識節點必須將交易分組成批，每一個組稱爲一個區塊，而且因爲分組方式的不一樣（即對交易的不一樣組合），可能致使在同一區塊高度上存在數千個有效區塊。所以，爲了保證區塊的最終肯定性(即對於給定的區塊高度，有且只有一個區塊)，咱們不得不考慮「客戶端」(區塊提議者)也發生故障的狀況，而PBFT並無考慮到這一點。

 

2、NEO dBFT關鍵性修改

上一小節咱們強調了PBFT和dBFT的一些區別：

• 終端用戶和種子節點的一區塊最終肯定性;

• 在過程的不一樣階段使用加密簽名，以避免暴露當前區塊的節點確認;

• 可以基於區塊頭的信息共享產生區塊(交易經過獨立的同步機制進行共享和存儲);

• 經過禁止確認階段後的視圖更改，避免重複暴露區塊簽名;

• 再生機制可恢復故障節點，不管是在本地硬件仍是網絡P2P共識層。

 

3、dBFT詳細說明

dBFT共識機制本質上是一個狀態機，其狀態轉換依賴於循環模式 (定義主節點/備份節點)，也依賴於網絡消息。

 

dBFT有如下幾個狀態：

• Initial: 狀態機初始狀態

• Primary: 依賴於區塊高度和視圖數量

• Backup: 若是不是主節點，則爲true，不然爲false

• RequestSent: 若是區塊頭請求已發送，則爲true,不然爲 false (在dBFT 2.0中已被刪除，由於代碼會跟蹤全部準備簽名，併合併爲RequestSentOrReceived)

• RequestReceived: 若是區塊頭請求已接收，則爲true，不然爲false (在dBFT 2.0中已被刪除，由於代碼會跟蹤全部準備簽名，併合併爲RequestSentOrReceived)

• SignatureSent: 若是簽名已發送，則爲true，不然爲false (在dBFT 2.0中已被刪除，由於新增的確認階段會攜帶簽名) • RequestSentOrReceived: 若是收到有效的主節點簽名，則爲true，不然爲false (在dBFT 2.0中引入)。

• ResponseSent: 若是區塊頭確認已發送，則爲 true（在dBFT 2.0中引入：內部狀態，僅用於出塊節點觸發共識OnTransaction事件）

• CommitSent: 若是區塊簽名已發送，則爲true (該狀態僅在dBFT 2.0中引入，並替換了SignatureSent) • BlockSent: 若是區塊已發送，則爲true，不然爲false • ViewChanging: 若是已觸發視圖更改機制，則爲true，不然爲false • IsIecovery: 若是接收到並正在處理一個有效的恢復信息，則爲true (在dBFT 2.0中引入: 內部狀態)

 

初版的dBFT將這些狀態顯式地做爲標誌進行處理 (ConsensusState的枚舉值)。可是，dBFT 2.0能夠隱式地處理這些信息，由於它會對準備簽名和狀態恢復機制進行跟蹤。

 

4、流程圖

圖2顯示了在每一個共識節點上進行復制的狀態機 (本小節中術語副本/節點/共識節點可視爲同義詞)。對於區塊鏈上給定的區塊高度H，狀態機副本的執行流程從Initial狀態開始。設T爲標準的出塊時間(15秒); v是當前的視圖編號(從v= 0開始); exp(j)設置爲2j; i爲共識索引; R爲共識節點總數。

這個狀態機能夠表示爲一個時間自動機(Alur和Dill 1994)，其中C表示時間變量，操做(C條件)? 表示時間轉換 (C:=0即重置時間)。

虛線表示顯式地依賴於超時行爲的狀態轉換，爲了清楚起見使用不一樣格式加以表示。同時假定狀態轉換按照各狀態出現的順序進行。

 

例如：

(C >= 5)? A (C >= 7)? B 時間C超過5s時，區塊狀態會轉換到狀態A，時間C超過7s時，區塊狀態會切換到B。該狀態機可以更爲準確地對dBFT 2.0的實現原理加以描述。

 

圖 2: 給定區塊高度下的dBFT 2.0狀態機

 

在圖2中，共識節點從Initial狀態開始，且視圖編號初始值爲v= 0。給定H和v，每一輪共識會使用如下公式檢測當前節點i是否爲主節點：（H+v）modR=i（不然設置爲複製節點）。

若是當前節點爲主節點，則T秒後進入SendPrepareRequest狀態（選擇交易並建立新的提議塊）並再次轉換到RequestSentOrReceived狀態。若是該節點是複製節點，則須要等待OnPrepareRequest狀態。

時鐘到期後，節點可能會進入ViewChanging狀態，這能夠在主節點出現故障時保證網絡的活躍性。然而，由於該節點已經確認了特定的區塊（所以它不會爲該高度上的任何其餘區塊提供簽名, CommitSet狀態能夠保證不會發生視圖的更改。

因爲會影響網絡的活躍性，所以狀態機提出了一個恢復過程（參見圖3）。EnoughPreparations，EnoughCommits和EnoughViewChanges取決因而否有超過拜占庭級別M的足夠的有效響應（即不超過最大故障節點數f）。

在2.0版本以後，T表示爲節點接收到的最後一個區塊的時間，而不是前一個區塊頭被簽名時的時間戳。

 

5、區塊肯定性

在共識層級別中的區塊肯定性由等式（1）中的條件肯定，其定義了對於給定的區塊高度ℎ，以及任意的出塊週期t，不會存在兩個不一樣的區塊。

總之，區塊肯定性使得對於狀態機複製（SMR）而言客戶沒必要驗證大多數的節點共識。從這個意義上講，種子節點能夠直接追加全部由協議定義的具備真實簽名的區塊（即M=2f+ 1）。

正如當前NEO dBFT算法所描述的，所需的最少簽名數是拜占庭將軍問題（Lamport，Shostak和Pease 1982）中所定義的2f + 1，其f=1/3×N是網絡協議所容許的拜占庭節點的最大個數。

 

6、多區塊簽名曝光

一、dBFT v1.0版本檢測故障

2017年在NEO區塊鏈網絡的實際運行中曾發生過區塊散列阻塞分叉的狀況。特別地，形成這種現象的緣由如下兩個由主節點所選擇的區塊的屬性：

• 不一樣的交易集合;

• 區塊Nonce。

 

特別地，在沒有確認階段時，NEO dBFT 1.0版本簡單地實現了pBFT算法。

可是，在極少數狀況下，給定的節點能夠接收到持久化一個區塊所需的M個簽名，而後忽然斷開與其餘節點的鏈接。這個時候其餘節點能夠檢測到通訊的缺失（以及它們之間的其餘故障）並生成一個新的區塊。

除了會破壞區塊肯定性以外，這個問題可能會終止共識節點以及任何其餘客戶端的運行，這些客戶端會持久化一個沒有獲得大多數共識節點（CN）共識的區塊。此外，在更爲少見的狀況下，當其餘節點具備不一樣的區塊散列時，x個節點能夠接收到一個給定的區塊，其中$ f + 1 <x <M $，從而形成整個網絡的崩潰，最終不得不手動進行維護。

值得注意的是，即便在沒有超時機制的異步共識中，若是沒有對Nonce以及待插入到區塊中的交易進行定義，也可能致使問題的產生。這一真實的事件激發了一些關於共識的新穎看法的產生，其中涵蓋了因爲網絡引發的這種「天然」問題以及在真實的拜占庭節點中額外的安全性考量。

 

二、帶有更換視圖出塊的確認階段

考慮到在確認階段也可能發生上述故障，因此應該對節點加以驗證，從而能夠阻塞節點而不會重複暴露它的簽名。另外一方面，若是惡意節點試圖保存簽名並執行某些特定的操做（如存儲信息而不共享信息），也可能發生其餘類型的攻擊。

 

就這點而言，天然而然會出現如下這種可能性：

• 發送區塊頭的簽名後鎖定視圖更換（NEO dBFT 2.0後實現了該功能）。這意味着那些被該區塊所確認的節點不會對其餘提議的區塊進行簽名。

另外一方面，因爲節點須要遵照相應的協議，再生策略彷佛是必需的。咱們將此定義爲不知疲倦的礦工問題。

 

定義以下：

一、該議長是一名地質工程師，正在尋找一個能夠挖掘氪石的地方;

二、他提議了一個地理位置（待挖掘的地理座標）;

三、團隊（M）的大多數成員對該座標達成了共識（帶有他們的簽名）並簽署了合約贊成開始挖掘;

四、挖掘的時間：他們會不停地挖掘，直到他們找到氪石（在發現氪石前不會去任何其餘地方進行挖掘）。氪石是一種無限可分的晶體，所以，一旦有人挖掘到氪石，他就可共享以便全部人都能擁有一塊氪石從而履行完他們的合約（3）;

五、若是有人死亡了，當有其餘人加入時，他將看到先前簽署的協議，並自動開始挖掘（再生策略）。其餘小部分人也會遇到相同的問題，能夠經過隱藏的信息來告知他們也應該進行挖掘。

 

該策略在最大故障節點數爲f的限制下保證了dBFT算法的強度。此外，生存/再生策略也加強了系統的魯棒性。

 

7、再生

恢復/再生機制用於對給定的丟失部分歷史數據的故障節點進行響應。此外，它還在本地進行了數據備份，從而能夠在發生硬件故障時恢復節點。這種本地級別的安全性（能夠看做是硬件故障安全性）是相當重要的，可減小有意設計的惡意攻擊所帶來的影響。

從這個意義上講，若是節點發生故障後又恢復運行，它會自動將change_view設置爲0，這意味着該節點已經恢復並但願經過其餘節點恢復歷史數據。所以，它可能接收一個有效負載，使其可以驗證大多數節點的共識並返回開始實際操做，幫助它們對當前正在處理的區塊進行簽名。

根據這些要求，dBFT 2.0列舉了一系列不一樣的狀況，其中節點能夠恢復其先前的狀態，兩者都是網絡或自身已知的。

 

所以，目前恢復場景包括：

• 重播ChangeView消息;

• 重播主節點的prepareRequest信息;

• 重播PrepareResponse消息;

• 重播Commit消息。

 

代碼能夠恢復如下狀況：

• 將節點恢復到更高級別的視圖;

• 將節點恢復到已發送準備請求，但還未收集到足夠多的進入確認階段所需的準備信息的視圖;

• 將節點恢復到已發送準備請求，同時已收集到足夠多的準備信息從而能夠進入確認階段的視圖，接下來可轉換到CommitSent狀態;

• 將確認簽名共享到已確認的節點（激活CommitSent標誌）。

 

圖3總結了由恢復機制引導的一些當前狀態，這些狀態目前由接收到視圖更換請求的節點發送。恢復負載由接收到ChangeView請求的節點發送，且節點數不超過f。當前根據負載發送方和本地當前視圖的編號進行選擇。

值得注意的是，OnStart事件會在編號爲0的視圖處觸ChangeView事件，以便與其餘節點進行通訊，告知其初始活動及其可接收任何恢復負載的狀態。這麼作的緣由是，可讓啓動較晚的節點發現網絡已經處於某些高級狀態。

不一樣於reResponse狀態，這裏的內部狀態IsRecovering是爲了簡化Recover消息可能帶來的影響。從這個意義上說，在不失通常性的狀況下，指向它的箭頭能夠直接與它指出的箭頭相連。

圖 3: 帶有恢復機制的dBFT 2.0狀態機

 

8、可能的故障

一、單純的網絡故障

可能場景：

•多達f個節點延遲消息;

•至多有f個節點會因爲硬件故障或者軟件問題而崩潰

 

二、混合型惡意拜占庭故障

首先，拜占庭式攻擊的設計應確保節點永遠沒法證實這是一次攻擊。不然，NEO持有者將從新審視此類行爲，並投票支持其餘節點。此外，加入給定協做網絡的節點擁有身份或權益。若是有人可以檢測到這種惡意行爲，那麼，該節點將「自動」（經過當前的投票系統或可設計的自動機制）從網絡中刪除。

• 至多有f個節點會延遲消息; • 至多有f個節點會發送不正確的信息（因爲能夠揭示惡意行爲，因此這種狀況不太可能發生）; • 至多有f個節點會嘗試爲策略場景保留正確的信息。

 

9、針對BFT區塊鏈協議 故障和攻擊的MILP模型

咱們提出了一個針對BFT區塊鏈協議的故障和攻擊的MILP模型，該模型針對dBFT的具體狀況進行了設計，也適用於其餘那些不太特殊的狀況。

因爲dBFT剛更新到2.0版本，因此當前的模型尚未徹底完成。完成後，它將包括一些使用數學編程語言（AMPL）建模的基準測試結果，可參見： https://github.com/NeoResearch/milp_bft_failures_attacks。

 

一、數學模型

參數：

變量：

 

目標函數：

攻擊者能夠控制f個副本，但其餘M個副本必須遵循dBFT算法。攻擊者能夠爲任意消息選擇任意延遲時間（最大模擬時間爲|T|）。若是它想要關閉整個網絡，就不能再產生任何區塊，而且目標函數值將爲零（可能的最小值）。所以，攻擊者將嘗試以巧妙的方式來操縱延遲時間從而最大化所生成的區塊數。如等式（2）所示，目標函數的值域爲[0，|B|]。

 

限制：

 

二、示例

 

10、致謝

dBFT 2.0背後的關鍵思想和開發主要由張錚文指導，而在Github上的開放式討論中，也有不少來自社區成員的寶貴貢獻，感謝你們花費寶貴的時間對BFT理念進行討論並提出改進建議。咱們也感謝爲解決這些挑戰性問題而不斷嘗試，並最終對算法進行實現的開發人員。

爲此，真誠地感謝那些爲實現算法而作出貢獻的人: jsolman、shargon、longfei、tog、edge等人。

Alur, Rajeev, and David Dill. 1994. 「時間自動機理論」 Theoretical Computer Science 126:183–235. https://www.cis.upenn.edu/~alur/TCS94.pdf.

Bracha, Gabriel, and Sam Toueg. 1985. 「異步共識與廣播協議.」 J. ACM32 (4): 824–40. https://doi.org/10.1145/4221.214134.

Castro, Miguel, and Barbara Liskov. 1999. 「實用拜占庭容錯」 In OSDI, 99:173–86. Duan, Sisi, Michael K. Reiter, and Haibin Zhang. 2018. 「BEAT:異步Bft實戰.」 Proceedings of the 2018 AcmSigsac Conference on Computer and Communications Security,

202841.CCS ’18. New York, NY, USA: ACM. https://doi.org/10.1145/3243734.3243812 Hao, X., L. Yu, L. Zhiqiang, L. Zhen, and G. Dawu. 2018. 「動態實用拜占庭容錯」

In 2018Ieee Conference on Communications and Network Security (Cns), 1–8. https://doi.org/10.1109/CNS.2018.8433150.

Hongfei, Da and Zhang, Erik. 2015. 「NEO: 面向智能經濟的分佈式網絡」 https://github.com/neo-project/docs/blob/master/en-us/whitepaper.md.

Lamport, Leslie, Robert Shostak, and Marshall Pease. 1982. 「拜占庭將軍問題」

ACMTransactions on Programming Languages and Systems (TOPLAS) 4 (3): 382–401.

Miller, Andrew, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. 2016. 「Bft協議的蜜罐」

In Proceedings of the 2016 AcmSigsac Conference on Computer and Communications Security, 31–42.ACM.

Schneider, Fred B. 1990. 「使用狀態機方法實現容錯服務的指導」

ACM Comput.Surv. 22 (4): 299–319. https://doi.org/10.1145/98163.98167.

 

 

本文來源：NEOFANS

原文連接：http://neofans.org/

 

 

聯繫咱們
微博：https://weibo.com/u/6724929880

官網： https://neonext.club/

QQ羣：612334080

電報：https://t.me/neonextop

twitter：https://twitter.com/NE0NEXT

掃碼關注 NEONEXT 官方公衆號

獲取更多一手社區資訊

▼