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消息，才會知道原來自己已經被移除了這個組織。
覆蓋完整的區塊鏈知識體系，從入門到源碼，這里有真正想要的區塊鏈技術，歡迎大家關注微信號：蝸牛講技術。掃下面的二維碼
