BBFT共識算法深度解析丨Bystack是如何實現單條側鏈 20000+TPS的

共識算法是分佈式系統保證節點數據狀態一致性的方法，在區塊鏈的共識算法分POW(工作量證明)和POS(權益證明)兩大類。第一類POW模式是在公鏈項目中運用的最廣泛應用的共識算法，比特幣長達10年的運行已充分證明POW的安全性與穩定性。POW的特性是將去中心化與安全性發揮到了極致,但卻犧牲了性能。 如比特幣的峯值TPS爲3.87， 平均每筆交易被打包入塊需要10分鐘;比原鏈的峯值TPS爲36.32，平均每筆交易被打包入塊需要2.5分鐘。第二類的POS模式是由通過算法來選擇出塊共識節點，多用於聯盟鏈和一些追求高TPS的新公鏈項目中。POS的特性是通過支持更小的出塊間隔來達到最優的性能，但卻犧牲了部分的安全性與去中心化。

Bystack是一個基於主側鏈架構的區塊鏈BaaS平臺，將區塊鏈分爲Layer1和Layer2兩層。

Layer1既比原鏈的主鏈，由POW算法保證最高級別的資產安全與去中心化。Layer1的TPS問題則通過跨鏈技術將資產轉移到Layer2上來解決.

側鏈（既Layer2）使用創新的BBFT共識算法使單條側鏈的TPS達到20000以上，多條側鏈配合可使TPS線性增長。

在未達到節點帶寬與性能瓶頸的前提下，TPS = 區塊交易數 *每秒確認的區塊數。由於區塊可以容納的最大交易數可以通過簡單的修改代碼參數實現，所以提高每秒確認的區塊數就成了提高TPS的關鍵方式。如比原鏈的每個區塊最大可容納5500筆左右的交易，在主鏈上因爲平均每150秒出一個塊的POW特性所以TPS是36.32.但上在側鏈如將每秒進入最終確認的區塊數提高到5個則可輕易的將TPS達到25000以上。

DPOS的問題

傳統的DPOS共識算法如EOS已經完全可以做到支持每秒2個區塊的出塊速度，但卻有一個等待最終確認的問題。
因爲一個傳統的DPOS區塊獲得最終確認的依據是所有超級節點都在此塊之後出過至少一個子塊。這意味着假設有21個超級節點，每個節點每輪出6個塊，平均每個出塊時間爲0.5秒。那麼一個區塊獲得最終確認的時間需要60秒。

BFT的問題

基於BFT的POS因爲BFT的特性所有每個塊在產出之後可以得到快速的最終確認，但是卻難以獲得較高的TPS.
原因是BFT每個區塊分爲三個狀態，產生，預最終狀態與最終確認狀態。
狀態的改變是依靠收集到2/3節點的簽名，而簽名產生的效率依賴網絡的延遲。假設部分超級節點在美國，部分在中國那麼通信的延遲大約爲200毫秒。
那一個區塊從產生到最終確認至少需要600毫秒的限制。所以在BFT的共識算法中網絡延遲成爲了高TPS的瓶頸。

DPOS BBFT共識算法

Bystack的共識算法是基於DPOS和BBFT算法特性的全新混合共識算法,
通過將出塊與BBFT簽名異步進行的模式使得算法同時具有高TPS與快速最終確認的特性。在BBFT共識算法由全網用戶投票選出n個共識節點進行出塊。共識節輪流成爲出塊節點，當成爲出塊節點的共識節點將會以s秒一個塊的速度連續出m個區塊。當區塊產生之後將直接廣播至全網，
但出塊節點不會等待獲取2/3的其他共識節點簽名而是繼續在當前塊的基礎上出下一個塊。此時當前區塊已是合法區塊但是未獲得最終確認，類似於比特幣未獲得6個塊確認存在回滾的可能性。當其他共識節點收到區塊並且驗證通過之後將會對區塊進行簽名並廣播到全網，當一個區塊獲得超過2/3的簽名時就進入了最終確認狀態。

TPS

實現高TPS的核心點是每個共識節點連續出m個區塊。因爲當每個節點只出一個塊的話那麼下一個共識節點出塊需要等待上一個共識節點出的塊，這裏就需要考慮一個網絡延遲帶來的問題。如果把出塊間隔設置小於網絡延遲的，那會有大概率共識節點在出塊時未收到上一個塊造成分叉的狀態。但當m設爲一個稍大的數則可以將tps提升到帶寬與節點性能的極限。
假設當m=20,
當下一個共識節點出塊時因爲網絡延遲未收到最後1個塊但卻收到了之前的19個塊，節點會接在上一輪第19個塊之後出塊。區塊鏈會進入瞬間的分叉狀態但會根據最長鏈原則在2個塊之後全網狀態統一。雖然損失了1個區塊的TPS,
但任保證了出塊間隔小於網絡延遲情況下的高出塊率。

異步BFT

在BBFT的設計中出塊與與共識節點的BFT簽名是並行進行來抵消因網絡延遲收集BFT簽名對出塊效率的影響。但不同於經典BFT算法中有產生，預最終狀態與最終確認三個狀態，
BBFT根據區塊鏈的特性改造使算法只有一個最終確認狀態。
但添加了兩個額外的限制條件：第一個是當一個共識節點對相同高度的兩個不同區塊進行簽名既發生欺詐；第二個是當一個共識節點對相同時間的兩個不同區塊進行簽名既發生欺詐。通過這種方式的改造減少了共識節點之間的通信次數，從而降低了區塊獲得最終確認所花費的時間。同時BBFT還有區塊獲得直接確認與間接確認兩種。第一種直接確認既區塊獲得了超過2/3的共識節點簽名。第二種間接確認是一個區塊未獲得2/3的共識節點簽名，但其子塊獲得了超過2/3共識節點的簽名，BBFT則會認爲此區塊間接的獲得了最終確認的狀態。

容災容錯

1. 支持只剩單共識節點存活的情況下支撐整個網絡的運行到下一輪共識節點替換，但出塊速度會下降爲正常情況的1/n.
   用戶可在此期間更改投票替換超級節點，在下一輪共識節點替換時網絡既恢復正常狀態。
2. 支持1/3的共識節點作惡的情況下網絡正常運行，當超過1/3的共識節點作惡區塊將長時間不能進入最終確認功能直至網絡運行到下一輪共識節點被替換。當超過1/2的共識節點作惡，惡意節點將控制網絡。

BBFT共識出塊情景分析

以下案例假設 n = 5, m = 3, s = 1，區塊高度 = 100，時間戳爲= 1557148900, 

輪到3號共識節點準備出第一個塊

完美狀態 

1. 3號節點出高度爲101， 時間戳爲155714890區塊A，廣播至全網
2. 區塊A得到超過2/3的節點確認，進入最終確認狀態

3.  3號節點出高度爲102， 時間戳爲155714891區塊B，廣播至全網

1. 區塊B得到超過2/3的節點確認，進入最終確認狀態

5.  3號節點出高度爲103， 時間戳爲155714892區塊C，廣播至全網

1. 區塊C得到超過2/3的節點確認，進入最終確認狀態
2. 4號節點成功收到區塊A, B, C並都處於最終狀態，在此鏈的基礎上繼續連續出
3. 4號節點出高度爲104， 時間戳爲155714893區塊D，廣播至全網

---

達到毫秒級最終確認，無回滾發生, 只有在網絡延遲低與共識節點穩定的時候產生

理想狀態

1. 3號節點出高度爲101， 時間戳爲155714890區塊A，廣播至全網
2. 3號節點出高度爲102， 時間戳爲155714891區塊B，廣播至全網
3. 區塊A得到超過2/3的節點確認，進入最終確認狀態

4.  3號節點出高度爲103， 時間戳爲155714892區塊C，廣播至全網

1. 區塊B得到超過2/3的節點確認，進入最終確認狀態
2. 4號節點成功收到區塊A, B, C但只有A,

B處於最終確認狀態，在此鏈的基礎上繼續連續出塊

1. 4號節點出高度爲104， 時間戳爲155714893區塊D，廣播至全網
2. 區塊C得到超過2/3的節點確認，進入最終確認狀態

---

達到秒級最終確認，無回滾發生，但因收集共識節點對區塊的確認簽名，導致最終確認的延遲。
但由於所有區塊已成功傳遞到下一個出塊共識節點，所以不影響出塊

出塊共識節點異常狀態

1. 時間戳爲155714890， 無新塊產生
2. 時間戳爲155714891， 無新塊產生
3. 時間戳爲155714892， 無新塊產生
4. 4號節點未收到任何區塊，輪到挖礦後出高度爲101，

時間戳爲155714893區塊A廣播至全網

1. 區塊A得到超過2/3的節點確認，進入最終確認狀態

---

達到秒級最終確認，無回滾發生，因共識節點down機導致全網3秒內無節點出塊。造成的影響是減慢了全網的出塊速度，當單節點長期down機需要等待下一次投票時重新選出新一輪的共識節點可修復

網絡延遲異常1

1. 3號節點出高度爲101， 時間戳爲155714890區塊A，廣播至全網
2. 區塊A得到超過2/3的節點確認，進入最終確認狀態

3.  3號節點出高度爲102， 時間戳爲155714891區塊B，廣播至全網

1. 區塊B得到超過2/3的節點確認，進入最終確認狀態

5.  3號節點出高度爲103， 時間戳爲155714892區塊C，廣播至全網

1. 區塊C得到超過2/3的節點確認，進入最終確認狀態
2. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到
3. 4號節點出高度爲103， 時間戳爲155714893區塊D，廣播至全網
4. 由於2/3的共識節點已最終確認區塊C, D無法獲得最終確認
5. 4號節點收到區塊C與C的最終確認信息， 回滾區塊D, 切換鏈至區塊C
6. 4號節點出高度爲104， 時間戳爲155714894區塊E，廣播至全網
7. 區塊E得到超過2/3的節點確認，進入最終確認狀態

---

達到秒級最終確認，有回滾在所有沒收到區塊C的節點中發生，造成的影響是減慢了1個塊的出塊速度

網絡延遲異常2

1. 3號節點出高度爲101， 時間戳爲155714890區塊A，廣播至全網
2. 區塊A得到超過2/3的節點確認，進入最終確認狀態

3.  3號節點出高度爲102， 時間戳爲155714891區塊B，廣播至全網

1. 區塊B得到超過2/3的節點確認，進入最終確認狀態

5.  3號節點出高度爲103， 時間戳爲155714892區塊C，廣播至全網

1. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到
2. 4號節點出高度爲103， 時間戳爲155714893區塊D，廣播至全網
3. 區塊D得到超過2/3的節點確認，進入最終確認狀態
4. 3號節點收到區塊D與D的最終確認信息， 回滾區塊C, 切換鏈至區塊D
5. 4號節點出高度爲104， 時間戳爲155714894區塊E，廣播至全網
6. 區塊E得到超過2/3的節點確認，進入最終確認狀態

---

達到秒級最終確認，有回滾在所有認同區塊C的節點中發生，造成的影響是減慢了1個塊的出塊速度

網絡延遲異常3 

1. 3號節點出高度爲101， 時間戳爲155714890區塊A，廣播至全網
2. 區塊A得到超過2/3的節點確認，進入最終確認狀態

3.  3號節點出高度爲102， 時間戳爲155714891區塊B，廣播至全網

1. 區塊B得到超過2/3的節點確認，進入最終確認狀態

5.  3號節點出高度爲103， 時間戳爲155714892區塊C，廣播至全網

1. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到
2. 4號節點出高度爲103， 時間戳爲155714893區塊D，廣播至全網
3. 區塊D得到超過2/3的節點確認，進入最終確認狀態
4. 3號節點收到區塊D與D的最終確認信息， 回滾區塊C, 切換鏈至區塊D
5. 4號節點出高度爲104， 時間戳爲155714894區塊E，廣播至全網
6. 區塊E得到超過2/3的節點確認，進入最終確認狀態

---

達到秒級最終確認，有回滾在所有認同區塊C的節點中發生，造成的影響是減慢了1個塊的出塊速度

網絡延遲異常4 

1. 3號節點出高度爲101， 時間戳爲155714890區塊A，廣播至全網
2. 區塊A得到超過2/3的節點確認，進入最終確認狀態

3.  3號節點出高度爲102， 時間戳爲155714891區塊B，廣播至全網

1. 區塊B得到超過2/3的節點確認，進入最終確認狀態

5.  3號節點出高度爲103， 時間戳爲155714892區塊C，廣播至全網

1. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到
2. 4號節點出高度爲103， 時間戳爲155714893區塊D，廣播至全網
3. 區塊C, D各獲得50%的共識節點投票，網絡進入分叉狀態
4. 4號節點出高度爲104， 時間戳爲155714894區塊E，廣播至全網
5. 區塊E得到超過2/3的節點確認，進入最終確認狀態
6. 4號節點出高度爲105， 時間戳爲155714895區塊E，廣播至全網

---

達到秒級最終確認(極端情況分鐘級發生概率和比特幣回滾6區塊差不多)，有回滾在所有認同區塊C的節點中發生，造成的影響是減慢了1個塊的出塊速度.
此異常情況的極限狀態是兩條鏈各站約50%的算力並且發生持續競爭，直到稍佔共識優勢的鏈先進入了了最終確認狀態。

參數對網絡的影響

1.
共識節點的個數其實代表了區塊鏈網絡的容錯率，n越大則單點故障對網絡造成的影響越小。但n的數量增大會導致BFT對區塊簽名數量要求的增加，會消耗更多的資源與延緩區塊進入最終確認狀態所需要的時間

2.
每個節點連續出塊的個數是爲了在考慮到網絡延遲的情況下仍可以保證高速出塊的方法。
當連續出塊個數足夠時出塊時間理論上可達毫秒級。核心點就是當下一個出塊共識節點有網絡延遲未收到最後的3個區塊，但之前的m-3個區已收到，可在m-3基礎上繼續出塊。但m過大會導致單共識節點故障時長時間不出塊

3.
出塊間隔時間明面上是高tps的保證，理論上當出塊間隔爲200毫秒時比Bytom的tps可達25000。但s設置的過小可能導致區塊最終確認時間的延長。

論文鏈接：https://github.com/bystackcom...