蝸牛講-Fabric入門之基於Gossip的數據傳播概述

Fabric經過組件化來分離各個實體，如節點和orderers，orderer提供了ordering服務，節點維持了帳本和世界狀態(world state)，同時鏈碼的執行是獨立於ordering服務，這種設計的主要目的是爲了顯著提升可擴展性。可是這種設計就須要一種通訊方式來保證各個節點間的消息傳播是可信，可擴展的而且是支持拜贊庭容錯。用任何中心化通訊方式都不能解決可信分佈式問題，因此在區塊鏈中使用基於點對點的數據傳播基礎架構，這種架構更適合於區塊鏈的動態化和分佈式特性。

 

數據傳播基礎架構約定了在區塊鏈網絡中數據只能在它相關的管道里進行傳輸，不在這個管道的成員節點接收不到這個管道的數據，這種約定或是限制讓Fabric能夠支持多管道的傳輸方式，同時能保證整個系統即便在少許節點的狀況下也能夠運行良好。可是ordering服務和節點分離機制一樣也帶來了在拜贊庭環境下更爲複雜的數據傳播和驗證問題。因此引入了Gossip，在Fabric中gossip的主要目的是：

•     使得在一個管道內的全部節點都有相同的帳本，同時避免全部的節點都鏈接到ordering服務上，緩解ordering服務的壓力

•     當有新的節點加入，同步帳本的操做能夠獨立於ordering服務

 

在Fabric裏，全部通過共識以後的有序交易序列須要通知給全部的節點，讓這些節點更新節點狀態和帳本信息。這種狀況下，就要去ordering服務和節點之間有鏈接，而且能夠傳播已排序的交易信息。固然不是全部的節點都會鏈接到ordering服務上，鏈接到ordering服務的節點是選舉出來的，被選舉出來的節點經過標準的Deliver協議和ordering服務鏈接。這些節點負責分發接收到的交易數據到其餘各個節點上。每一個聯盟或是組織都會選擇一個Leader節點，由Leader節點鏈接ordering服務，並傳播接收到的交易信息。

 

上述的數據傳播方案要在狀態轉換，同步機制上起到關鍵做用。首先，對於因爲某些狀況下沒有收到完整的交易的節點，基於gossip的狀態同步機制要能保證這些節點在條件容許的狀況下能夠同步節點缺失的交易數據。其次，爲了支持當系統運行一段時間後有新的節點加入狀況，系統要提供一個基於反熵的狀態同步，經過它能夠在節點之間傳輸大數據量。

 

多管道的支持

 

管道的建立是用來定義信息分享的範圍，並與帳本相關連。每一個交易都關聯到某個管道，這個管道明確的定義了哪些節點是能夠接收同步這個交易的。當管道被建立後，客戶端SDK能夠指示屬於組織內的哪些節點加入到新建立的管道內。這些剛加入的節點經過gossip在全組織內廣播。

 

爲了使得gossip在多管道內能夠正常工做，須要管道內的全部節點維護這個管道內的成員關係，通俗的說，就是管道內的每一個節點都須要知道管道內的其餘全部節點。對於新加入的節點，ordering服務須要確保該節點確實屬於這個組織。做爲Leader節點，則有義務和責任把從ordering接受來的消息分發給其餘節點。Gossip組件是在管道中的成員關係建立好後才工做，這樣保證了經過gossip網絡傳播的每一筆交易都在特定的成員關係羣中傳播，而不會傳播到其餘管道去。爲了實現上述功能，當一個節點加入到一個管道後，客戶端SDK會爲這個節點提供該管道的最新配置來識別有哪些節點也加入了這個管道。若是是一個新的管道，配置信息爲創世紀塊。

 

當一個組織從一個管道上移除，客戶端sdk會發送配置交易的背書申請，當背書籤名後，交易將發送給ordering服務。每一個gossip組件都會把消息發給那些沒有被移除的節點。一開始，節點本身是不知道是否被移除的，在一段時間內沒有接收到從其餘節點發來的alive消息，纔會知道原來本身已經被移除了這個組織。

 

---

覆蓋完整的區塊鏈知識體系，從入門到源碼，這裏有真正想要的區塊鏈技術，歡迎你們關注微信號：蝸牛講技術。掃下面的二維碼