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的选举模式：

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