最近一直在看fabric系統中的核心模組之一——peer模組。在看peer的配置檔案core.yaml的資訊時，對其中的gossip配置選項很感興趣。看了一上午，還是不能明白這個選項到底什麼意思呢？表面意思很容易理解：“gossip”——“閒話”。但是在配置選項中為什麼要起這麼個名字呢？

     後來查閱了一些資料，才知道開發者用意何為？哈哈。。。

gossip——可最終達到一致的演算法:

     gossip本意是緋聞，流言蜚語，閒談聊天的意思。而在這裡，gossip代表了一種可最終達到一致的演算法。其靈感來源於辦公室八卦：當一個八卦在辦公室出現時，在一定階段內通過散播（dissemination），所有人最終都會知道這個八卦。

這樣就比較容易理解了，比如peer經過背書籤名，將一個有效的交易最終提交。這份交易的寫集合是A減100，B加100，因為網路中所有的結點都存有一份賬本，因此該交易提交後，在有限的時間內，每個分佈在網路中的結點中的賬本都會應用這個交易，將自己的賬本中的A減去100，B加上100。或者，有新結點加入網路中後，經過一定的時間，該新結點也會儲存和其他結點一樣的賬本資料。

     這裡需要注意是，最終一致的另外的含義就是，不保證同時達到一致，也就是在某一指定的時刻，每個結點的賬本（也就是狀態）不保證一致。同時，gossip不要求節點知道所有其他節點，因此具有去中心化的特性，節點之間完全對等，不需要任何的中心節點，這點也是區塊鏈的顯著特徵。

gossip中有三種基本的操作：

• push - A節點將資料(key,value,version)及對應的版本號推送給B節點，B節點更新A中比自己新的資料。
• pull - A僅將資料key,version推送給B，B將本地比A新的資料（Key,value,version）推送給A，A更新本地。
• push/pull - 與pull類似，只是多了一步，A再將本地比B新的資料推送給B，B更新本地。

gossip資料傳播協議：

     Fabric通過劃分各個執行交易的（背書和提交）peer和ordering結點之間的工作負載來優化區域鏈網路的執行，安全和可測量性。網路操作的解耦要求一個安全的，可信賴的，可測量的資料傳播協議，以保證資料的完整性和機密性。為了達到這些要求，Fabric實現了一個gossip資料傳播協議。

gossip協議：

peer結點“撬動”gossip以可測量的方式去廣播（broadcast）賬本和頻道資料。gossip訊息傳送是是持續的，而且在頻道中的每個peer不間斷的從其它的peer那裡接收當前的和一貫的（也就是格式等前後一致）賬本資料（ledger data）。每個傳播的訊息都被簽名過，因此“拜占庭的參與者”傳送虛假的訊息會很容易被識別，把訊息發到訊息不想到達的目標的分發行為會被阻止。peer會被延遲，網路參與者或者其他造成block丟失的原因所影響，但這些丟失block的peer最終將通過聯絡持有這些丟失block的peer非同步更新到當前賬本狀態。

以gossip為基礎的資料傳播協議在Fabric網路上執行三個基礎的功能：

• 通過持續性的識別有效成員peer和檢測那些已經下線的peer，管理peer的發現（discovery）和頻道成員關係。
• 在頻道上所有的peer之間傳播賬本資料。任何持有與頻道其他peer結點不同步的資料的peer識別丟失的block並通過拷貝正確的資料來同步自身。
• 通過允許賬本資料以peer點對peer點（peer-to-peer）狀態傳輸更新的方式，提高新加入網路的peer結點的同步速度。

     以gossip為基礎的廣播操作是通過peer從頻道中其他peer中接收訊息，然後把這些訊息傳送到頻道上一定數量隨機選擇的peer結點，這個數量是可配置常量。peer結點也能運用一個pull機制，而不是等待一個訊息的投遞。這個迴圈重複著，伴隨著頻道成員關係的結果，賬本和狀態資訊持續保持最新且同步。對於新block的傳播，在頻道中的領導peer（the leader peer）從ordering服務pull資料並初始化gossip到各個peer的傳播。

gossip訊息傳送：

     線上的peer結點通過持續的廣播“alive”資訊來（向leader或其他結點）指示其自身的有效性，每條訊息中都包含PKI_ID（the public key infrastructure ID）和傳送者的簽名。每個peer結點也通過收集這些“alive”訊息，來維護自身的頻道成員關係（channel membership）。如果沒有任何一個peer接收到某一特定的peer的“alive”訊息，則這個“dead”peer最終會從頻道成員關係中被清除。因為“alive”訊息都是加密簽名了的，所以惡意的peer會因缺少由root CA認證的簽名匙（signing key）而不可能冒充其他正確的peer。

     除了自動傳輸接收的訊息（即散播dissemination），一個狀態調節程序（state reconciliation process）會通過每個頻道上的眾多peer結點來與世界狀態（world state）同步。每個peer持續性的從頻道上的其他peer那裡pull來block資料，目的在於，如果（通過與自己的block資料對比）存在差異則修復自身的狀態。因為固定的連線（fixed connectivity）不被要求去維護以gossip為基礎的資料散播，因此這個程序會可靠的提供私密的和完整的資料到共享的賬本，同時包括了對錯誤結點的容錯度。（這裡的固定的連線應該這麼理解：在網路中沒有發生變化的結點集合，比如A，B，C，D四個結點一直沒有發生變化，因而四個結點之間的關係也不會發生變化，因此這四個結點之間就不需要去進行gossip散播訊息資料。比如一個新加入的E點是與D點發生關係，則只需要D去向E散播訊息，而A，B，C，D四者之間仍是不需要互相進行gossip散播的。）

     因為多個頻道之間是被相互隔離的，所有在一個頻道上的peer點不能向其他頻道傳送訊息或分享資訊。雖然任一peer都可以屬於多個頻道，但是依照應用的訊息線路選擇策略（message routing policies），分配的訊息傳送禁止把block資料散播到其他頻道的peer結點，這裡的訊息線路選擇策略是以peer的頻道訂閱為基礎的。（關於頻道訂閱，參考出版-訂閱訊息系統，即一個peer能夠接收一個頻道中的訊息，必須先訂閱這個頻道的訊息。）

注意：

     點對點（point-to-point）訊息的安全性由peer的TLS層來處理，不需要簽名。peer結點憑藉它們自身的證書獲得認證，這些證書由一個CA分配。雖然TLS證書也被使用，但是在gossip層是該peer點的證書被驗證授權（而不是TLS的證書）。賬本的block由ordering服務簽名，然後投遞到頻道中的leader peer。認證是由peer的MSP物件管理的。當一個peer第一次連線到頻道上，TLS會話（session）同成員身份繫結。這主要是使用在網路和頻道中的成員關係去認證每個與新的peer發生的連線。

---------------------

REFERENCE：

1.https://blog.csdn.net/idsuf698987/article/details/77898724 

2.翻譯自官方文件