Bystack的高TPS共識演算法

比原鏈Bytom發表於2019-05-27

Bystack的高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,廣播至全網

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

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

  6. 區塊C得到超過2/3的節點確認,進入最終確認狀態

  7. 4號節點成功收到區塊A, B, C並都處於最終狀態,在此鏈的基礎上繼續連續出

  8. 4號節點出高度為104, 時間戳為155714893區塊D,廣播至全網


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

理想狀態

  1. 3號節點出高度為101, 時間戳為155714890區塊A,廣播至全網

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

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

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

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

  6. 4號節點成功收到區塊A, B, C但只有A,
    B處於最終確認狀態,在此鏈的基礎上繼續連續出塊

  7. 4號節點出高度為104, 時間戳為155714893區塊D,廣播至全網

  8. 區塊C得到超過2/3的節點確認,進入最終確認狀態


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

出塊共識節點異常狀態

  1. 時間戳為155714890, 無新塊產生

  2. 時間戳為155714891, 無新塊產生

  3. 時間戳為155714892, 無新塊產生

  4. 4號節點未收到任何區塊,輪到挖礦後出高度為101,
    時間戳為155714893區塊A廣播至全網

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


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

網路延遲異常1

  1. 3號節點出高度為101, 時間戳為155714890區塊A,廣播至全網

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

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

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

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

  6. 區塊C得到超過2/3的節點確認,進入最終確認狀態

  7. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到

  8. 4號節點出高度為103, 時間戳為155714893區塊D,廣播至全網

  9. 由於2/3的共識節點已最終確認區塊C, D無法獲得最終確認

  10. 4號節點收到區塊C與C的最終確認資訊, 回滾區塊D, 切換鏈至區塊C

  11. 4號節點出高度為104, 時間戳為155714894區塊E,廣播至全網

  12. 區塊E得到超過2/3的節點確認,進入最終確認狀態


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

網路延遲異常2

  1. 3號節點出高度為101, 時間戳為155714890區塊A,廣播至全網

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

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

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

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

  6. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到

  7. 4號節點出高度為103, 時間戳為155714893區塊D,廣播至全網

  8. 區塊D得到超過2/3的節點確認,進入最終確認狀態

  9. 3號節點收到區塊D與D的最終確認資訊, 回滾區塊C, 切換鏈至區塊D

  10. 4號節點出高度為104, 時間戳為155714894區塊E,廣播至全網

  11. 區塊E得到超過2/3的節點確認,進入最終確認狀態


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

網路延遲異常3 

  1. 3號節點出高度為101, 時間戳為155714890區塊A,廣播至全網

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

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

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

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

  6. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到

  7. 4號節點出高度為103, 時間戳為155714893區塊D,廣播至全網

  8. 區塊D得到超過2/3的節點確認,進入最終確認狀態

  9. 3號節點收到區塊D與D的最終確認資訊, 回滾區塊C, 切換鏈至區塊D

  10. 4號節點出高度為104, 時間戳為155714894區塊E,廣播至全網

  11. 區塊E得到超過2/3的節點確認,進入最終確認狀態


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

網路延遲異常4 

  1. 3號節點出高度為101, 時間戳為155714890區塊A,廣播至全網

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

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

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

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

  6. 4號節點成功收到區塊A, B但C區塊由於延遲問題暫未收到

  7. 4號節點出高度為103, 時間戳為155714893區塊D,廣播至全網

  8. 區塊C, D各獲得50%的共識節點投票,網路進入分叉狀態

  9. 4號節點出高度為104, 時間戳為155714894區塊E,廣播至全網

  10. 區塊E得到超過2/3的節點確認,進入最終確認狀態

  11. 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/BBFT

相關文章