Bystack的高TPS共識算法

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

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

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處於最終確認狀態,在此鏈的基礎上繼續連續出塊

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

  4. 區塊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,廣播至全網

  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%的算力而且發生持續競爭,直到稍佔共識優點的鏈先進入了了最終確認狀態。

參數對網絡的影響

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

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

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

論文連接:https://github.com/bystackcom/BBFT

相關文章
相關標籤/搜索