Hyperledger gossip
本文記述了Hyperledger Fabric 中 一種網絡數據同步協議--gossip，它的主要作用是致力於賬本數據的安全傳輸，保證不同節點之間狀態的同步和完整。
在fabric的網絡中gossip的message是持續存在的，一個peer節點會不斷、實時的接收到來自同一channel其他peers的賬本數據。每一個gossip message都攜帶發送方的簽名信息，這可以使得接受方輕易的辨別對方的身份和校驗消息的完整性和合法性。當一個peer由於延遲、網絡故障等原因而錯過block數據的情況發生時，可以通過從其他擁有該block的peer處去同步，從而保證了賬本的完整性和一致性。
gossip 協議的三個主要功能：
-
peer發現和channel membership管理： 通過持續的去辨別同channel內其他peer的身份是否合法 和 校驗peer是否宕機，來維持和管理channel內其他peers的信息
-
賬本數據的傳播： 同channel內任何一個peer在發現block數據缺失時，可以從其他peer拷貝正確的block數據
-
傳輸加速： 通過點對點的傳輸方式去更新賬本，可以使得新上線的peer快速同步數據
在gossip協議中 一個peer同時從多個peer接收數據，然后會從同channel中其他的peers選擇出來一定數量N的peer，去將數據發送到這些被選中的peer中，N是一個可配置的常量。peer 也可以去主動拉去數據而不是被動的等待，整個過程不斷的重復，直到ledger狀態和channel的membership達到同步的狀態。當一個channel的新塊產生后每一個組織的leader會去從orderer節點去拉取該塊，然后通過gossip協議去廣播。
Leader eletcion
在一個channel中每一個Application organization的peers都需要leader節點，leader節點的作用就是與orderer servers保持通訊，不斷的去拉取新生成的塊信息，然后廣播給組織內的其他peer。
Static leader election
靜態選舉方案，需要peer的管理員去定義一個或者幾個peer為leader，當被配置為leader后則會與orderer servers通訊，但如果太多的peer被設置為leader則會導致orderer servers的帶寬壓力過大，所以在配置的過程中需要在穩定性和帶寬性能上權衡一下。
可以通過配置文件的方式和環境變量的方式去配置peer的選舉模式：
- core.yaml 配置文件
peer:
# Gossip related configuration
gossip:
useLeaderElection: false
orgLeader: true
- 環境變量：
export CORE_PEER_GOSSIP_USELEADERELECTION=false
export CORE_PEER_GOSSIP_ORGLEADER=true
以上兩種配置方式都可以將peer設置為static的leader節點, 如果CORE_PEER_GOSSIP_USELEADERELECTION 和CORE_PEER_GOSSIP_ORGLEADER 同時被配置為false，則該節點會放棄成為leader。但不能同時設置為true，會導致配置不明確。
Dynamic leader election
在動態選舉的過程中，同channel內每一個組織會各自選擇出一個peer成為leader與orderer servers通訊。 leader 節點要通過心跳消息來向其他節點證明自己依然活躍，當leader 節點的心跳消息超時后 peer節點會自動的發起下一輪的leader選舉，選出一個新的leader。當因為網絡環境問題導致網絡分片時，會同時存在多個leader，當網絡恢復的時候會保留一個leader其他的leader放棄自己的地位。 這種設計可以保證網絡的彈性，同時也減輕了orderer servers的壓力。
以下配置控制leader的心跳頻率：
peer:
# Gossip related configuration
gossip:
election:
leaderAliveThreshold: 10s
同上面的靜態選舉配置一樣，也需要通過配置文件或者環境變量來開啟，這里就不重復描述了。
以上兩種方案的優點和弊端都很明顯： static方案可以省去leader選舉的過程，提高ledger同步的速度，減少網絡帶寬的壓力，但是如果leader發生宕機的話整個組織都無法從orderer servers 獲取block。dynamic 可以避免上面崩潰問題，但是leader選舉過程延緩了同步速度和增加網絡帶寬壓力。
Anchor Peer
Anchor Peer是通過更新channel的config block來設置，同一個channel內每一個組織都有自己的Anchor Peer，它的主要用途是在跨組織通訊上。在gossip跨組織通訊過程中，A組織的節點Nx 至少要知道 B 組織的一個peer地址（可以通過該節點獲取 B組織內其他peer的地址），才能進行跨組織的通訊。
請不要將Anchor Peer 與 leader 的概念混淆，Anchor Peer 不一定是leader， leader也不一定是Anchor Peer。
Gossip Message
一個在線的peer需要持續的去廣播"alive"消息來證明自己存活。這個alive message 中包含證明自己身份的PKI Id 和對應私鑰的簽名，在秘鑰不被泄漏的情況下該消息無法被假冒（目前來講），同channel的其他peer會收集有效的alive message 來維持channel membership。 如果一個peer的alive message沒有被其他peer接收到則會判定為dead，從而被其他peer從channel membership 中移除。
雖然任何peer都可以屬於多個channel，但由於channel之間是隔離的，因此peer不應該傳遞和分享不相關的channel的消息（即沒有加入的channel）。 基於peer中channel記錄的消息路由策略 則保證分發的block信息 不會被傳遞給不在該channel 內的peer。
除了自動的分發消息之外，也會在每一個channel中的peer之間進行world state的協調。peer會不斷的從同channel的其他peer處去拉取block來修補自身存在差異的world state。因為gossip 消息傳播是不依賴於節點之間固定的鏈接，所以及時在發生某個節點宕機的情況仍然能保證ledger的完整性和持久性。
peer之間的 使用Tls協議 進行peer-to-peer鏈接， 鏈接過程中會通過peer的Tls 證書去做協議層的認證，但並不能作為peer身份的認證。每一個peer都擁有由組織CA 頒發的身份證書，這個身份證書才是真正標明peer身份的。 每一個Block數據都會被 orderer service 簽名后分發給對應channel的 leader peers。
身份認證是由peer msp 實現的，當 peer 首次接入channel的時候， tls會話會與 msp identity綁定，可以基於此來驗證peer是否有加入通道的資格。
Question
-
同組織的 peer 初次加入的時候， 在Anchor peer未設置的時候如何發現其他節點？
-
leader的選舉過程？如果同組織內的有static election peer 和 dynamic election peer 會怎么樣？
-
world state 和 block 數據同步的詳細流程？