NEXT社區小課堂 | 第三課：NEO dBFT共識機制分析與完善

NEXT社區 | 小課堂

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

 

NEXT社區小課堂 | 第三課

NEO dBFT共識機制分析與完善

 

在NEO採用dBFT機制實現共識節點之間的「拜占庭容錯」，並在NEO白皮書中描述惡意共識節點小於1/3的時候，該共識機制可以保證系統的安全性和可用性。

通過研究發現，目前NEO的dBFT機制僅能保證誠實的共識節點間達成共識。但共識節點之間不存在分叉，並不意味着全網不會存在分叉。

NEO目前對dBFT共識機制的實現還不知足的拜占庭容錯性質。

 

1、NEO dBFT共識機制簡介

NEO區塊鏈是一個分佈式的智能合約平臺。

NEO實現了一種委託的拜占庭容錯共識算法，它借鑑了一些 PoS 的特色（NEO持有人須要對共識節點進行投票） 利用最小的資源來保障網絡免受拜占庭故障的影響，同時也彌補了 PoS 的一些問題。

dBFT對由n個共識節點組成的共識系統，提供容錯能力，這種容錯能力同時包含安全性和可用性，並適用於任何網絡環境。

NEO dBFT共識機制可詳見NEO官方共識機制白皮書：

- http://docs.neo.org/zh-cn/basic/consensus/whitepaper.html (中文版)

- http://docs.neo.org/en-us/basic/consensus/whitepaper.html (英文版)

 

2、拜占庭將軍問題和區塊鏈

拜占庭位於現在的土耳其的伊斯坦布爾，是東羅馬帝國的首都。因爲當時拜占庭羅馬帝國國土遼闊，爲了防護目的，所以每一個軍隊都分隔很遠，將軍與將軍之間只能靠信差傳消息。

在戰爭的時候，拜占庭軍隊內全部將軍和副官必需達成一致的共識，決定是否有贏的機會纔去攻打敵人的陣營。可是，在軍隊內有可能存有叛徒和敵軍的間諜，左右將軍們的決定又擾亂總體軍隊的秩序。在進行共識時，結果並不表明大多數人的意見。

這時候，在已知有成員謀反的狀況下，其他忠誠的將軍在不受叛徒的影響下如何達成一致的協議，拜占庭問題就此造成。

PBFT算法，是解決拜占庭將軍問題的一個經典算法。

區塊鏈是一種去中心化的分佈式帳本系統，它能夠用於登記和發行數字化資產、產權憑證、積分等，並以點對點的方式進行轉帳、支付和交易。

區塊鏈技術最先是由中本聰在一個密碼學的郵件列表中提出的，也就是比特幣。此後，基於區塊鏈技術的各類應用紛紛出現，好比基於區塊鏈的電子現金系統、基於區塊鏈的股權交易系統、基於區塊鏈的智能合約系統等。

區塊鏈系統與傳統的中心化帳本系統相比，具備徹底公開、不可篡改、防止多重支付等優勢，而且不依賴於任何的可信第三方。然而，和任何分佈式系統同樣，區塊鏈系統會面臨網絡延遲、傳輸錯誤、軟件錯誤、安全漏洞、黑客入侵等問題。

此外，去中心化的特色決定了此係統的任何一個參與者都不能被信任，可能會出現惡意節點，以及因各方利益不一致致使的數據分歧等問題。爲了防範這些潛在的錯誤，區塊鏈系統須要一個高效的共識機制來確保每個節點都有一個惟一公認的全局帳本。

傳統的針對某些特定問題的容錯方法，並不能徹底解決分佈式系統以及區塊鏈系統的容錯問題，人們須要一種可以容忍任何種類錯誤的容錯方案。

 

3、NEO區塊鏈共識機制細節

採用了拜占庭容錯委託（dBFT）做爲共識機制。

 

全網中的NEO節點分爲兩類節點：

一、共識記點，負責和其餘共識記點之間進行共識通信，產生新的區塊；

二、普通節點，不參與共識，但可以驗證和接受新的區塊。

共識節點由全網用戶經過投票產生。

 

NEO節點提出dBFT的背後思想是：

PBFT算法可以很好的解決分佈式節點的共識問題，可是PBFT共識參與節點數量越大性能就會越低。採用投票選取出相對較小數量的共識節點內部進行PBFT共識生成新區塊，而後將該新區塊發佈到全網中達成全網共識。

 

NEO共識節點之間，產生新區塊的正常共識流程以下：

一、開啓共識的節點分爲兩大類，非記帳人和記帳人節點，非記帳人的不參與共識，記帳人蔘與共識流程

二、選擇議長，Neo議長產生機制是根據當前塊高度和記帳人數量作MOD運算獲得，議長實際上按順序當選

三、節點初始化，議長爲primary節點，議員爲backup節點

四、知足出塊條件後議長髮送PrepareRequest

五、議員收到請求後，驗證經過簽名發送PrepareResponse

六、記帳節點接收到PrepareResponse後，節點保存對方的簽名信息，檢查若是超過三分之二則發送 block

七、節點接收到block，PersistCompleted事件觸發後總體從新初始化，爲了防止惡意的共識節點或議長，保證系統的安全性和可靠性，NEO提出changeview機制進一步加強dBFT的安全性

 

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

一、令

二、節點  發出視圖更換請求

三、任意節點收到至少  個來自不一樣  的相同  後，視圖更換達成，令  並開始共識

四、若是在通過  的時間間隔後，視圖更換仍未達成，則遞增並回到第 2 步

NEO共識節點整體流程如圖：

 

 

4、dBFT共識機制問題分析

dBFT的核心思想，是想經過選舉出的共識節點經過pBFT協議達成共識，從而產生全網的共識。這看上去是一個很好的思路，但因爲dBFT和pBFT中，共識節點爲非共識節點提供服務的模型不同。

在pBFT中，非共識節點（客戶端節點）須要收到至少f+1個共識節點的相同的執行結果，從而得到服務結果。而dBFT中，非共識節點須要得到一個由至少2f+1個共識節點共同簽名的block。

dBFT的拜占庭容錯，不能想固然的從pBFT中得出。證實一個共識協議的安全性，須要嚴謹的證實。在分析網絡協議安全性的一個重要的前提是，網絡是一個複雜的環境，咱們不能保證先發去的包必定先到達。這是網絡協議之因此複雜的緣由。

下面咱們給出兩個反例，證實dBFT沒法提供 的拜占庭容錯。

 

攻擊案例1：

假設7個節點A1 A2 A3 A4 A5 A6 A7。其中議長A1和A2是惡意節點(小於1/3節點數)，同時A1擔任本輪議長。A1生成block1發送PrepareRequest(block1)給A2 A3 A4，同時生成block2發送PrepareRequest(block2)給A5 A6 A7。

當你們都收到PrepareRequest消息後，A2 A3 A4會返回PrepareRespone(block1)消息，A5 A6 A7會返回PrepareRespone(block2)消息。

此時，Block1和Block2的簽名已經在網絡上公開4個。網絡還未達成共識，還需進一步協商，最終生成的共識區塊未定。

但此時惡意節點A2實際上能夠產生block2的簽名（他本身手上能有5個block2的簽名），故A2有能力在網絡中產生一個分叉。

dBFT在該攻擊案例下，沒法實現拜占庭容錯(2個惡意節點)。

 

攻擊案例2：

假設7個節點A1 A2 A3 A4 A5 A6 A7。其中A2爲惡意節點(只有一個惡意節點)。

假設A1當選本輪議長，因爲大量交易處理或其餘網絡緣由，A1產生了延遲。並在臨界timeout的事件發送一個block1出去。

其中 A5 A6 A7 剛恰好在限定時間內收到並徹底整個block1驗證，回覆了簽名。 A2 A3 A4尚未收到這個block1。

此時，按照dBFT協議，timeout時間到，全部人將要求change view。 恰好，change view的包，比Block1提早到達了A2 A3 A4處。你們達成了change view的共識。而後進行下一個view階段。

若是在此階段，A2 A3 A4收到了block1，可是view和議長已經改變了，他們並不會接受block1。那麼你們會進入下一輪，產生block2。 Block2生產過程一切正常，A3 A4 A5 A6 A7幾個誠實的節點達成了共識。 可是此時，A2擁有Block1的5個簽名。它可以構造Block1.。由此，A2能夠在網絡中產生了一個分叉。

dBFT在該攻擊案例下，沒法實現拜占庭容錯(1個惡意節點)。

 

NEO當前的對dBTF的實現有所不足的本質緣由在於：

NEO的dBTF實現試圖用共識節點之間的共識代替全網共識；然而這個假設並不嚴格成立。dBFT僅能保證誠實的共識節點之間產生共識，而誠實的共識節點之間的共識與全網節點之間的共識並無嚴格的綁定關係。

在上面的例子1中，惡意的出塊節A1 A2點沒法影響共識節點之間產生共識Block2，但它能產生區塊Block1從而形成網絡中普通節點的分叉。按NEO目前設計，一旦分叉產生，分叉節點就沒法回到NEO網絡了。

 

5、問題的影響

在發現問題的當天，NEO創始人Erik Zhang回覆說他們已經發現了這個問題，而且在社區內作過相關聲明。

以前NEO在github項目上發起了一個Pull Request處理該問題，獲得了社區成員的積極響應，爲該問題建言獻策，目前問題已經初步解決，正在測試穩定性。經過對該PR具體討論和實現的研究，咱們發現實際上該PR主要是針對NEO當前dBTF中對PBFT的實現不夠完善進行的修復。

 

社區目前的理解是：

因爲NEO中dBFT缺少PBFT的commit階段，因此可能由於共識節點之間的網絡延遲或者宕機問題，形成共識節點之間沒法達成共識。但即便增長commit過程，也沒法防止惡意共識節點構造分叉塊。

NEO團隊針對此問題，已經在該PR下提出了新的改進方案，目前NEO社區正在完善以前的PR從而完全解決該問題。在此次問題的解決過程當中咱們發現NEO團隊對於安全問題處理專業高效，社區響應熱情及時。

360安全團隊會繼續與NEO一塊兒測試、分析並完善相關問題，推進NEO與區塊鏈技術向前發展。

 

下一節咱們將會詳細分析NEO dBFT2.0！

 

本文來源：NEOFANS

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

 

 聯繫咱們 

微博：https://weibo.com/u/6724929880

官網： https://neonext.club/

QQ羣：612334080

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

twitter：https://twitter.com/NE0NEXT

掃碼關注NEO NEXT官方公衆號

獲取更多一手社區資訊

▼