比原鏈BBFT如何讓共識更快——兼論BBFT與FBFT/HotStuff的比較

時間 2019-11-09

標籤 bbft 如何共識更快 fbft hotstuff 比較简体版

原文原文鏈接

前言

近日比原鏈(BYTOM)技術團隊發佈了Bystack區塊鏈BaaS平臺，其中包括側鏈的共識算法BBFT(Bystack Byzantine Fault Tolerance)。筆者將在這篇文章中闡述比原鏈BBFT嘗試解決的問題以及分析BBFT與其餘各家共識協議的主要差別。BBFT是一個PBFT的變形，它的原理與PBFT一脈相承。若想深入理解BBFT的巧思，則必須進入PBFT的脈絡推敲。早在區塊鏈藉由比特幣的大紅大紫以前，PBFT就做爲共識協議存在於世界上了。由Castro和Liskov於1999年發明，它是一個具備20年曆史的經典設計，它的發明是爲了解決分佈式系統中的一個經典問題：拜占庭將軍問題。直到今日，PBFT仍蘊含許多值得反覆推敲的巧思，不斷啓發後世發明出更好的協定。git

PBFT基本的運做流程

PBFT是一個具備二輪投票的三階段協議，每一個視域(View)都會有一個特定的節點做爲領導節點(Primary/Leader)，負責通知全部節點進入投票流程。各節點則會經歷Pre-prepare/Prepare/Commit這三個階段，並依據接收的訊息決定是否投票/進入下一階段，每一個節點投完票後將訊息發給全部其餘的節點。若個節點在兩階段投票以後取得多數共識，則各節點能夠更新本機的狀態，結束這一回合。視域變換(View-change)僅當多數節點發起時執行，當目前的領導節點並未正常執行任務時，這能夠替換當前的領導節點，保證協議正常運做。github

PBFT的特性

PBFT與中本聰共識(區塊鏈)有至關不一樣的特性：PBFT是一個許可制的、基於領導節點的、基於通信的、安全性重於活躍性的共識協定。算法

許可制的(Permissioned)：PBFT並不是徹底開放的，這是因爲PBFT須要讓節點可以驗證彼此的訊息以及精準掌握節點的數量，區塊鏈則是屬於對任何人都開放的非許可制(Permissionless)。
基於領導節點的(Leader-based)：也就是先決定領導節點(Leader)，再由領導節點送出提議，這樣作最直接的好處就是不須要浪費本身的運算資源去爭取當領導節點的機會，然而缺點就是隻有在視域變換時才輪替領導節點，成爲領導節點的機會並不公平，缺少加入網絡的誘因；區塊鏈則是在多個提案中選擇工做證實難度最高的區塊做爲共識，雖然這樣會形成運算資源的浪費，可是成爲出塊者的機率大體是公平的，其與算力成正比。
基於通信的(Communication-based)：PBFT的安全性奠定於3階段投票，雖然沒必要如工做證實般消耗大量計算資源，但數量龐大的通信也形成可擴展性的瓶頸——就算是號稱最實用的PBFT，也沒法擴展到1000個以上個節點。不只如此，PBFT使用消息驗證代碼(MAC)，每投一輪票就須要每個節點驗證一次訊息，大量的簽名/驗證也是另外一個潛在的瓶頸。
安全性重於活躍性的(Safety over Liveness)：PBFT不論在何種網絡假設下(同步/異步)都能確保安全性，幾乎不可能出現分岔，所以具備實時敲定(Instant Finality)的特性；相對地，區塊鏈則是活躍性重於安全性，其安全性有賴於同步的網絡，而具備複數個共識(及分岔)的狀況也至關常見，須要通過必定數量的區塊「確認」才能保證其再也不分岔的機率足夠大。

PBFT的問題

首先，PBFT中的每一個節點都需於每一輪投票中作n-n的通信，假設n爲1000，則每一次的共識都須要至少100,000次的通信，儘管PBFT已是BFT家族當中最實用的協議，這麼巨量的通信需求還是擴展的瓶頸。安全

如何提高效率?

聚合簽名網絡

爲了提高效率，一個直覺的思路是：避免n-n的通信。咱們能夠指定網絡中的某節點做爲協調者來發送/接收每一個節點的投票，這樣每一個節點都只須要向協調者發送訊息便可，從而避免了n-n的通信。然而，在這樣的情境下，協調者有做惡的可能，由於協調者能夠在未確實接收到指定數量的訊息前便執行下一輪投票或者進行狀態更新。所以，咱們可使用門坎簽章(Threshold Signature)來保證協調者的正當行爲，門坎簽章的能夠保證：需集合超過門坎數量(t-of-n)的簽章纔有效。也就是說，咱們能夠指定：惟有當協調者集合 2f+1 個門坎簽章後，協調者才能帶着合法的簽名繼續推動共識。Harmony FBFT即是一個使用聚合簽名以提高效率的BFT家族協議。less

圖1：FBFT Signature Aggregation異步

管線設計分佈式

每一個內容都必須通過二輪投票/三個階段才能達成共識，若是有m個內容就須要執行2m次投票。管線設計(Pipelining)能夠減小投票的次數，它的基本思路以下：讓每一個節點在投第 i 輪的prepare階段時，同時也是對其前一個內容 i-1 的commit階段投票。這樣作即可以節省對同一個內容重複投票的冗餘，大幅提高效率。這樣的思路首見於2018年發表的HotStuff協議。區塊鏈

圖2：HotStuff Pipeliningui

只讓部分節點參與共識：最小生成樹

另一種提升效率的方法，就是避免使全部的節點參與共識，這也正是比原鏈BBFT採起的做法。在BBFT中，節點分爲三種：Consensus Node/Gateway Node/Leader Node，這些節點造成樹的結構，樹爲網絡中節點的最小生成樹(Minimal Spanning Tree)，可能由分佈式算法得出，或是由外部服務提供。樹葉的節點即爲Consensus Node；樹根爲Leader Node；其餘部分爲Gateway Node。每種節點都有分別的任務：Consensus Node負責進行投票；Gateway Node則不需參與投票，但必須負責聚合由Consensus Node送來的簽章；Leader Node負責與其餘Leader Node交換訊息。BBFT的運做流程以下圖所示，BBFT的共識過程，即是訊息由樹根向樹葉傳播再回到樹根的過程。

圖3：BBFT: Minimal Spanning Tree

圖4：BBFT Process

如何確保正確性(Safety and Liveness)?

在爲PBFT帶入新技術以提高效率的同時，也必須確保協議自己的安全性與活躍性。接下來咱們來看看，上述的協議是如何確保這二者。

視域變換(View-change)

FBFT沿用了PBFT的視域變換，即在正常狀況下並不更換領導節點，僅有當超過2f+1個節點發起視域變換纔會更迭領導節點。視域變換雖然自己是一個可以替換做惡領導節點的機制，但它同時要求協議必須具備3個階段，才能保證協議的安全性(即不分岔)。

領導節點輪替(Rotating Leader)

HotStuff另外一方面則引入了領導節點輪替的機制，在每一個回合都更換領導節點，如此來回避視域變換高額的通信成本。領導節點輪替也常見於許多BFT家族的協議，算是目前保障安全性機制的主流。

混合式(Hybrid)

比原鏈BBFT則取各家所長，同時應用了視域變換與領導節點輪替，等因而上了雙重保險。不過值得注意的是，目前的BBFT技術白皮書僅有一輪投票的模型，並未提出兩輪投票/三階段共識的模型。另外，領導節點輪替的順序也將基於各節點的權益(Stake)，若節點出現違反協議的行爲則該節點會遭受懲罰。

BBFT的挑戰

綜合以上的分析與比較，BBFT目前有幾個顯著的挑戰。首先，是最小生成樹的產生方式，如何同時兼顧去中心化與效率？其次是BBFT僅採起單輪投票做爲共識，在引入視域變換的狀況之下，可能會發生分岔，這樣的網絡也會遭受日蝕攻擊的威脅。最後，引入門坎簽章的前提下，勢必須要引入分佈式私鑰生產協議(Distributed Key Generation)以共同生成私鑰，這部分於技術白皮書中還沒有說起，倒是可能形成瓶頸的潛在因子。