1. 程式人生 > >區塊鏈共識演算法:實用拜占庭容錯機制PBFT

區塊鏈共識演算法:實用拜占庭容錯機制PBFT

詳情參見個人部落格:

  共識機制是區塊鏈的核心組成部分,以POW、POS以及DPOS等為代表的共識機制執行需要以代幣為基礎,即需要發行各自的貨幣體系來構成各自網路執行的激勵機制,而在於節點已經有一定的互信基礎且不需要靠代幣來支撐整個網路的區塊鏈,傳統的共識演算法如PBFT、PAXOS、RAFT則派上了用場,PAXOS則是第一個被證明的共識演算法。本文限於篇幅,PAXOS和RAFT留待後續。

  實用拜占庭容錯機制PBFT

  PBFT演算法由MiguelCastro和Barbara Liskov 1999年提出,初衷是為解決分散式系統中達成一致性的問題,與區塊鏈共識機制的目標重合,其主要特點是網路具有高度容錯性,在一個有3f+ 1個節點的網路中,失效節點數為f,網路依然能夠正常執行,容錯率接近33%。目前,中國ChinaLedger聯盟和HyperLedger聯盟就在研究探討PBFT的實際應用。

  演算法首先需要引入檢視(View)和驗證節點(replica)的概念,replica包含主節點和備份節點。主節點(primary)依據某個公式選取,選取好之後,其他replica節點就成為備份(backups)節點。主節點有效時是表示處於同一幅檢視當中,當主節點失效時,備份節點檢測到之後需要通過timeout機制啟動檢視更換(view change)過程,選舉新的主節點。整個演算法流程如下:首先,由某個客戶端向主節點發起服務請求,主節點將請求分發給所有備份節點,備份節點處理完後再全部回饋給客戶端,客戶端只要收到f+ 1個節點回饋的相同結果即為演算法的最終結果。

  具體實現流程分為三階段協議(three-phaseprotocol),即預準備(pre-prepare)、準備(prepare)和確認(commit)。

  預準備(pre-prepare)階段:主節點收到請求後,給請求編一個序號n,然後向所有備份節點發送資訊,資訊格式為<<PRE-PREPARE,v,n,d>,m>,v是檢視編號,m是客戶端傳送的請求資訊,d是m的摘要。如果該資訊滿足該備份節點設立的條件(如檢查檢視編號,序號n是否處於一個合理區間, m是否之前收到過等),則該節點進入準備階段。備份節點設立某些條件的原因是主節點有可能是失效節點,它可能會給不同的請求編上相同的序號,或者不去分配序號,或者讓相鄰的序號不連續:

  準備(prepare)階段:進入準備階段的節點向所有replica節點發送準備訊息<PREPARE,v,n,d,i>,i是節點編號。經過這兩個階段,每個節點都收到了兩條資訊,每個replica節點驗證預準備和準備訊息的一致性,即驗證檢視編號v、訊息序號n和摘要d是否一致,如果一致,進入下一個階段。

  確認(commit)階段:進入這一階段,某個replica節點向其他replica節點發送資訊,資訊格式<COMMIT,v,n,D(m),i>。節點收到其他replica節點確認資訊後進行驗證,仍是驗證檢視編號v、訊息序號n和摘要d是否一致,一致則驗證通過。當replica節點收到2f + 1個(包含自身) 驗證通過的確認資訊後,向客戶端反饋執行結果,並將結果寫入區塊中,即寫入區塊前,至少有2f+ 1個(包含自身)節點達成了共識。

  存在一個確認(commit)階段的緣由在於,單個replica節點收到2f + 1個(包括自己) PREPARE資訊並不能保證自己發出的PREPARE資訊已被其他replica節點接收到,即其他節點不一定已經準備好Prepared,需要一個確認(commit)階段來對此進行驗證。

  如果連續執行了K條請求,在第K條請求執行完時,向全網發起廣播,告訴其他replica節點它已經將這K條執行完畢,要是都反饋說這K條我們也執行完畢了,那就可以刪除這K條的資訊了,接下來再執行K條,完成後再發起一次廣播,即每隔K條發起一次全網共識,這個概念叫checkpoint,每隔K條去徵求一下大家的意見,要是獲得了大多數的認同,就形成了一個stable checkpoint(記錄在第K條的編號),這一機制被稱為“GarbageCollection”。

  PBFT是一種靜態共識, 在得知有限共識節點的情況可以適用。對於私有鏈和聯盟鏈,如果節點數不大(不大於100),可採用PBFT形成共識,公有鏈擁有大量且不斷動態變化的節點網路,用PBFT效率太低。

  使用PBFT演算法還需要注意的一點是,其不能很好的存貯其交易資訊,一些失效的副本可能會導致資訊外洩,應有相應應對機制。

我的BTC地址:1K8ni4mnQn7VjFZKjHJHLPWZ55owG9J1jd