最近在看fabric系統中peer子產品。在看peer的配置檔案core.yaml的資訊時，對其中的gossip配置選項很感興趣。表面意思很容易了解：“gossip”——“閑話”。但是在配置選項中為什麼要起這麼個名字呢？
最近一直在看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.翻譯自官方文檔