Gossip Protocol
Gossip protocol 也叫 Epidemic Protocol （流行病协议）。Gossip protocol在1987年8月由施乐-帕洛阿尔托研究中心发表ACM上的论文
《Epidemic Algorithms for Replicated Database Maintenance》中被提出。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。
Gossip Protocol和DHT（Distributed Hash Table）一样是P2P网络中的通信协议。
Gossip和P2P的区别
- 每个节点都存全量的数据，本地检索
- 每个节点从Peer拉取数据，达到和Peer数据一致
- 节点收到或产生新数据的时候，会转发给Peer，最终经过Multi-hop之后到达全网
Gossip 的完整过程
为了表述清楚，我们先做一些前提设定
- Gossip 是周期性的散播消息，把周期限定为 1 秒
- 被感染节点随机选择 k 个邻接节点（fan-out）散播消息，这里把 fan-out 设置为 3，每次最多往 3 个节点散播。
- 每次散播消息都选择尚未发送过的节点进行散播
- 收到消息的节点不再往发送节点散播，比如 A -> B，那么 B 进行散播的时候，不再发给 A。
注意：Gossip 过程是异步的，发消息的节点不会关注对方是否收到，即不等待响应；不管对方有没有收到，它都会每隔 1 秒向周围节点发消息。异步是它的优点，而消息冗余则是它的缺点。
优点
- 享有P2P网络抗单点故障的优点
- 相比DHT更不容易受到网络阻隔（partition）
缺点
- Multi-hop造成消息的延迟。这也是区块链挖矿、浏览器经常需要解决的问题
- 重复接收相同消息，造成了消息的冗余，也增加了收到消息的节点的处理压力
改进方向1：消息延迟
1. 增加Peer数量
需要解决的问题：Peer数量不够，节点则容易失去同步
解决：
- 在网络中设置一些固定的节点，与大量的Peer进行连接
- 其他节点Peer数量不够的时候，从这些固定节点获取Peer列表
2. 应对网络峰值
需要解决的问题：节点收到新数据后立刻转发给所有Peer，Peer多的情况下会造成瞬间的网络拥堵
解决：分批有序进行广播
a. Diffusion：广播时候对各个Peer加随机的延时
b. Fan-out：每秒随机选几个Peer发出消息
3.应对数据不一致
需要解决的问题：网络中两个节点同时发出消息，网络中会对这两个消息顺序暂时无法达成一致
解决：Avalanche，多轮询问随机Peer并与其中多数Peer的数据保持一致
- 以网络带宽为代价，换取更快达成一致
- 网络层面而非共识层面的解决方案，矿工仍倾向于不遵守该机制而选择对其有利的数据
改进方向2：消息隐私性
需要解决的问题：当一个节点连上足够多的Peer后，就能知晓消息的生产者是哪个Peer
解决：
（1）改变消息的起点，例如Dandelion Protocol
- 消息在前几Hop只发给一个Peer，之后开始Gossip
- 消息发起者的地址不再暴露，增强隐私性
（2）改变消息的终点，例如Nym，异构网络，加入mix节点，即带加密功能的消息池
总结
- Gossip Protocol具有抗单点故障、抗网络阻隔的优点，适用于区块链场景
- Gossip Protocol中Multi-hop带来的延迟需要进一步改进，尤其在挖矿场景下