本篇內(nèi)容介紹了“BBFT與FBFT/HotStuff的區(qū)別有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

前言

近日比原鏈(BYTOM)技術團隊發(fā)布了Bystack區(qū)塊鏈BaaS平臺，其中包括側(cè)鏈的共識算法BBFT(Bystack Byzantine Fault Tolerance)。筆者將在這篇文章中闡述比原鏈BBFT嘗試解決的問題以及分析BBFT與其他各家共識協(xié)議的主要差異。BBFT是一個PBFT的變形，它的原理與PBFT一脈相承。若想深刻理解BBFT的巧思，則必須進入PBFT的脈絡推敲。早在區(qū)塊鏈藉由比特幣的大紅大紫之前，PBFT就作為共識協(xié)議存在于世界上了。由Castro和Liskov于1999年發(fā)明，它是一個具有20年歷史的經(jīng)典設計，它的發(fā)明是為了解決分布式系統(tǒng)中的一個經(jīng)典問題：拜占庭將軍問題。直到今日，PBFT仍蘊含許多值得反復推敲的巧思，不斷啟發(fā)后世發(fā)明出更好的協(xié)定。

PBFT基本的運作流程

PBFT是一個具有二輪投票的三階段協(xié)議，每個視域(View)都會有一個特定的節(jié)點作為領導節(jié)點(Primary/Leader)，負責通知所有節(jié)點進入投票流程。各節(jié)點則會經(jīng)歷Pre-prepare/Prepare/Commit這三個階段，并依據(jù)接收的訊息決定是否投票/進入下一階段，每個節(jié)點投完票后將訊息發(fā)給所有其他的節(jié)點。若個節(jié)點在兩階段投票之后取得多數(shù)共識，則各節(jié)點可以更新本機的狀態(tài)，結(jié)束這一回合。 視域變換(View-change)僅當多數(shù)節(jié)點發(fā)起時執(zhí)行，當目前的領導節(jié)點并未正常執(zhí)行任務時，這可以替換當前的領導節(jié)點，保證協(xié)議正常運作。

PBFT的特性

PBFT與中本聰共識(區(qū)塊鏈)有相當不同的特性：PBFT是一個許可制的、基于領導節(jié)點的、基于通訊的、安全性重于活躍性的共識協(xié)定。

• 許可制的(Permissioned)：PBFT并非完全開放的，這是由于PBFT需要讓節(jié)點能夠驗證彼此的訊息以及精準掌握節(jié)點的數(shù)量，區(qū)塊鏈則是屬于對任何人都開放的非許可制(Permissionless)。

• 基于領導節(jié)點的(Leader-based)：也就是先決定領導節(jié)點(Leader)，再由領導節(jié)點送出提議，這樣做最直接的好處就是不需要浪費自己的運算資源去爭取當領導節(jié)點的機會，然而缺點就是只有在視域變換時才輪替領導節(jié)點，成為領導節(jié)點的機會并不公平，缺乏加入網(wǎng)絡的誘因；區(qū)塊鏈則是在多個提案中選擇工作證明難度最高的區(qū)塊作為共識，雖然這樣會造成運算資源的浪費，但是成為出塊者的機率大致是公平的，其與算力成正比。

• 基于通訊的(Communication-based)：PBFT的安全性奠基于3階段投票，雖然不必如工作證明般消耗大量計算資源，但數(shù)量龐大的通訊也造成可擴展性的瓶頸——就算是號稱最實用的PBFT，也無法擴展到1000個以上個節(jié)點。不僅如此，PBFT使用消息驗證代碼(MAC)，每投一輪票就需要每一個節(jié)點驗證一次訊息，大量的簽名/驗證也是另一個潛在的瓶頸。

• 安全性重于活躍性的(Safety over Liveness)：PBFT不論在何種網(wǎng)絡假設下(同步/異步)都能確保安全性，幾乎不可能出現(xiàn)分岔，因此具有實時敲定(Instant Finality)的特性；相對地，區(qū)塊鏈則是活躍性重于安全性，其安全性有賴于同步的網(wǎng)絡，而具有復數(shù)個共識(及分岔)的情況也相當常見，需要經(jīng)過一定數(shù)量的區(qū)塊「確認」才能保證其不再分岔的機率足夠大。

PBFT的問題

首先，PBFT中的每個節(jié)點都需于每一輪投票中做n-n的通訊，假設n為1000，則每一次的共識都需要至少100,000次的通訊，盡管PBFT已經(jīng)是BFT家族當中最實用的協(xié)議，這么巨量的通訊需求仍是擴展的瓶頸。

如何提升效率?

聚合簽名

為了提升效率，一個直覺的思路是：避免n-n的通訊。我們可以指定網(wǎng)絡中的某節(jié)點作為協(xié)調(diào)者來發(fā)送/接收每個節(jié)點的投票，這樣每個節(jié)點都只需要向協(xié)調(diào)者發(fā)送訊息即可，從而避免了n-n的通訊。然而，在這樣的情境下，協(xié)調(diào)者有作惡的可能，因為協(xié)調(diào)者可以在未確實接收到指定數(shù)量的訊息前便執(zhí)行下一輪投票或者進行狀態(tài)更新。因此，我們可以使用門坎簽章(Threshold Signature)來保證協(xié)調(diào)者的正當行為，門坎簽章的可以保證：需集合超過門坎數(shù)量(t-of-n)的簽章才有效。也就是說，我們可以指定：唯有當協(xié)調(diào)者集合 2f+1 個門坎簽章后，協(xié)調(diào)者才能帶著合法的簽名繼續(xù)推進共識。Harmony FBFT便是一個使用聚合簽名以提升效率的BFT家族協(xié)議。

圖1：FBFT Signature Aggregation

管線設計

每個內(nèi)容都必須經(jīng)過二輪投票/三個階段才能達成共識，如果有m個內(nèi)容就需要執(zhí)行2m次投票。管線設計(Pipelining)可以減少投票的次數(shù)，它的基本思路如下：讓每個節(jié)點在投第 i 輪的prepare階段時，同時也是對其前一個內(nèi)容 i-1 的commit階段投票。這樣做便可以節(jié)省對同一個內(nèi)容重復投票的冗余，大幅提升效率。這樣的思路首見于2018年發(fā)表的HotStuff協(xié)議。

圖2：HotStuff Pipelining

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

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

圖3：BBFT: Minimal Spanning Tree

圖4：BBFT Process

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

在為PBFT帶入新技術以提升效率的同時，也必須確保協(xié)議本身的安全性與活躍性。接下來我們來看看，上述的協(xié)議是如何確保這兩者。

視域變換(View-change)

FBFT沿用了PBFT的視域變換，即在正常情況下并不更換領導節(jié)點，僅有當超過2f+1個節(jié)點發(fā)起視域變換才會更迭領導節(jié)點。視域變換雖然本身是一個能夠替換作惡領導節(jié)點的機制，但它同時要求協(xié)議必須具有3個階段，才能保證協(xié)議的安全性(即不分岔)。

領導節(jié)點輪替(Rotating Leader)

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

混合式(Hybrid)

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

總結(jié)

以上是生活随笔為你收集整理的BBFT与FBFT/HotStuff的区别有哪些的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。