布比安全高效的共識演算法是如何實現的? | 商用區塊鏈BubiChain詳解(二)

買賣虛擬貨幣
區塊鏈技術逐漸從小眾的極客圈子走向規模化商用。從整體來看,區塊鏈技術的規模化商用還處在相對初期的階段,企業對區塊鏈技術效能、易用程度的較高需求,與區塊鏈技術本身的可拓展性瓶頸及較低的執行效率構成了當前限制行業發展的主要矛盾。基於自身大量的商業實踐和對區塊鏈商用的探索與創新,布比打造了完全自主智慧財產權、高效能可擴充套件、產品化成熟的商用級區塊鏈底層平臺BubiChain。
商用級區塊鏈底層平臺BubiChain取得底層技術關鍵突破:應用開發友好的智慧合約、安全高效的共識演算法、可靠的隱私保護、並行快速的多鏈,以及可擴充套件的跨鏈技術等創新;實現了產品化重要突破:應用可快速構建、視覺化運維、技術合規及資金賬戶體系等,形成完整的產品服務能力。本文為商用區塊鏈BubiChain詳解系列文章的第二篇——安全高效的共識演算法,以下為正文內容。安全高效的共識演算法

布比區塊鏈共識演算法具備可插拔屬性,支援高效的Bubi-BFT(改進創新的拜占庭容錯演算法)和支撐大規模使用者的Validating Pool+BFT等多種共識演算法。基於拜占庭容錯演算法的共識演算法Bubi-BFT,是一種不會產生鏈分叉且強一致性的演算法,使用者交易可在秒級時間確認。基於Validating Pool+BFT演算法,普通使用者也可參與投票,並選舉產生記賬節點,記賬節點再透過BFT演算法輪流產生區塊。

1. 系統模型

布比區塊鏈系統是一種分散式系統,共識演算法執行的環境類似於分散式系統的執行環境,要保證共識演算法的安全性和可靠性,不可避免的要解決“拜占庭將軍”問題。Bubi-BFT是一種拜占庭容錯演算法,在拜占庭容錯系統模型下實現,擁有N個節點的拜占庭容錯系統模型可以定義為:

所有誠實的參與者使用相同的輸入資訊,產生一致的結果。
如果輸入的資訊正確,那麼所有誠實的參與者必須接受這個資訊,並計算相應的結果。
在拜占庭容錯系統的實際執行過程中,一般假設整個系統中發生故障的伺服器不超過f臺,並且每個請求還需滿足兩個指標:  

· 安全性(Safety):任何已經完成的請求不會被更改;
· 活性(Liveness):可以接受並執行誠實的使用者請求,不會被任何因素影響而導致請求不能執行。

系統假設條件包括:

· 節點的行為是任意的;
· 節點錯誤是不相關的,節點可以安裝不同作業系統,部署不同的軟體版本;
· 節點之間透過非同步網路連線,訊息可能丟失、亂序到達、延時到達;
· 節點之間傳遞的訊息,第三方可以知曉,但不能更改、偽造訊息的內容或從摘要中計算原始資訊。

2. 狀態機副本

在布比區塊鏈分散式系統中,實現可容錯服務的方法通常是實現一個狀態機副本(State Machine Replication)協議,透過複製單機狀態下的服務到多個副本節點,並協調多個副本為使用者提供統一請求響應,主要包含:

· 一致性協議(Agreement)
· 檢查點協議(Checkpoint)
· 檢視變更協議(View-change)

Bubi-BFT實現了一個狀態機副本協議,正常情況下執行一致性協議,在Leader節點故障或者Leader正常輪換的時候執行檢視變更協議。Bubi-BFT中並無Checkpoint機制,因為每輪共識後節點的狀態是穩定狀態,也沒有資料庫或儲存系統中快速恢復的需求,沒有必要再加入專門針對於穩定狀的Checkpoint流程。

3. 一致性協議

布比區塊鏈一致性協議的目標是使來自普通使用者的請求在每個伺服器上都按照一個確定的順序執行。一致性協議通常至少包含三個階段:提案階段(Propose)、確認階段(Confirm)、提交階段(Commit)。區別於其他分散式系統中的一致性協議,拜占庭容錯演算法中加入了二次確認的Commit階段,確保每個節點操作一致,不會出現只有部分節點提交造成整體不一致的情況。

實現一致性的方法是節點之間透過協議傳播自己獲得的資訊,並根據自己收集的資訊判斷是否傳送確認或者提交資訊。系統狀態將在三個階段遷移,節點只需判斷收到的訊息是否足夠就可以自動進入下一個階段,三個階段完成代表著共識成功。

區塊鏈系統中的共識一般涉及到四種角色:

· 區塊鏈的使用者即普通使用者
· 共識過程中打包區塊的Leader節點
· 參與共識過程的Replica節點
· 共識過程中出現故障或作惡的Fault節點。

普通使用者提交交易後,這些節點透過三個階段即Propose、Confirm、Commit會話對交易集合達成一致,如果在共識過程中,Replica節點發現Leader不作為或作惡,則發起檢視變更流程選舉下一個Leader,當有大多數節點投票選舉了下一個Leader,則檢視變更成功。假設區塊鏈系統中節點總數為N,那麼Bubi-BFT能容忍的Fault節點個數為f=(N-1)/3,大多數節點的個數為N-f=2f+1。

4. 檢視變更協議

在布比區塊鏈中,當Leader節點故障的情況下,區塊可能並沒有在規定的時間內生成,此時需要更換Leader節點以繼續共識,更換Leader節點的協議即檢視變更協議。檢視變更協議與一致性協議執行流程類似,新的Leader按照預定的規則接管提案權,如果存在已經確認好而未提交的提案,將該提案繼續執行提交流程(Commit);否則構造新的提案,在新的檢視下執行一致性協議。

在Bubi-BFT中,為避免某個節點長期佔有出塊權利,除Leader節點故障情況下會執行檢視變更協議,正常情況下也會進行檢視變更以平均分配打包權利。

Leader故障時的VIEW-CHANGE流程屬於故障處理流程,共識將暫時停止,為提高可用性,在正常VIEW-CHANGE流程中加入多個超時重發機制,以提高網路層面的訊息傳達率。

正常情況下的檢視變更不涉及故障,無需執行檢視變更的投票和確認流程,只需在區塊打包完成時自動增加檢視號,進入v+1,Leader角色將會自動輪轉到新的共識節點。

5. Quorum機制

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;