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 数据同步的详细流程？