Hyperledger Fabric -- gossip 協議

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的選舉模式：

1. core.yaml 配置文件

peer:
    # Gossip related configuration
    gossip:
        useLeaderElection: false
        orgLeader: true

1. 環境變量：

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

1. 同組織的 peer 初次加入的時候， 在Anchor peer未設置的時候如何發現其餘節點？

2. leader的選舉過程？若是同組織內的有static election peer 和 dynamic election peer 會怎麼樣？

3. world state 和 block 數據同步的詳細流程？