Gossip数据传播协议 _gossip

千磨万击还坚劲，任尔东西南北风。这篇文章主要讲述Gossip数据传播协议相关的知识，希望能为你提供帮助。
Gossip数据传播协议：

Fabric通过将工作负载划分到事务执行(背书和提交)对等节点和事务排序节点，优化了区块链网络性能、安全性和可伸缩性。这种网络操作的解耦需要一个安全、可靠和可伸缩的数据传播协议，以确保数据的完整性和一致性。因此Fabric实现了gossip数据传播协议。
对等节点利用gossip以可伸缩的方式广播账本和通道数据。gossip消息是连续的，通道上的每个对等节点都不断地从多个对等节点接收当前的一致的账本数据。每条gossip消息都是签名过的，因此发送虚假消息的拜占庭式参与者可以很容易被地识别，并防止将消息分发给不必要的的目标。受延迟、网络分区或其他导致块丢失的原因影响的对等节点，最终将通过与拥有这些丢失块的对等节点联系，同步到当前账本状态。
基于gossip的数据传播协议在Fabric网络上执行以下三个主要功能:

①通过不断识别可用的成员对等节点，管理节点发现和通道成员资格，并最终检测出脱机/离线的对等节点；
②在通道上跨(所有)节点分发账本数据。任何具有与通道其余部分不同步数据的对等节点都可以识别缺失的块，并通过复制正确的数据来同步自身；
③通过使用点对点状态传输来更新账本数据，使新连接的节点加快同步速度。

基于gossip的广播由对等节点操作——这些对等点接收来自通道上其他对等点的消息，然后将这些消息转发到通道上随机选择的多个对等节点，其中这个数字是一个可配置的常量。对等节点还可以使用pull(拉取)机制，而不是等待消息的传递。这种循环不断重复，其结果是通道成员、账本和状态信息不断保持最新和同步。为了传播新块，通道上的leader节点从排序服务拉取数据，并向其组织中的对等节点发起gossip传播。
* 领导leader选举：
该机制用于为每个组织选举一个？?对等节点，该对等节点将保持与排序服务的连接，并在其组织内的对等节点之间开始分发新到达的块。领导选举为系统提供了有效利用排序服务带宽的能力。
领导人选举有两种模式：
①静态：系统管理员手动的将一个节点配置为一个组织中的leader；
②动态：对等节点执行leader选举程序，选择组织中的一个对等节点成为leader。

* 静态领导人选举：静态选举允许手动的将组织中的一个或多个节点定义为leader。但是请注意，太多节点连接到排序服务的话会造成低效率地使用带宽。要启用静态领导选举模式，请在core.yaml中配置以下参数:

或者，这些参数也可以使用环境变量来配置和覆盖:

以下配置将使peer处于待命模式，即peer不会试图成为领导者:

将CORE_PEER_GOSSIP_USELEADERELECTION和CORE_PEER_GOSSIP_ORGLEADER设置为true是不明确的，将导致错误。在静态配置中，组织管理员负责在发生故障或崩溃时提供leader节点的高可用性。

* 动态领导人选举：动态领导选举允许组织中的对等节点选择一个leader节点，该对等点将连接到排序服务并拉取新的区块。这个leader是为一个组织中的节点独立选出来的。一个动态选出的leader会向其他节点发送心跳信息，作为其活跃的证据。如果一个或多个节点在规定的时间内没有收到心跳的更新，他们将选举一个新的leader。在网络分区的最坏情况下，组织将有多个活跃的leader来确保弹性和可用性，以允许组织的对等节点继续取得发展。网络分区修复后，其中一个领导者将放弃其领导地位。在没有网络分区的稳定状态下，将只有一个活动的leader连接到排序服务。
以下配置控制领导者发送心跳消息的频率:

为了启用动态领导选举，需要在core.yaml中配置以下参数:

或者，这些参数可以通过环境变量配置和覆盖:

* 锚节点：锚节点被gossip协议用来确保不同组织的节点能够感知到彼此。当提交了包含对锚节点更新的配置区块时，对等节点将与锚节点接触，并向它们学习锚节点所知道的所有对等节点。一旦每个组织中(至少)有一个对等节点与锚节点联系，锚节点就会了解通道中的每个对等节点。由于gossip通信是持续的，而且peers总是要求被告知他们不知道的peer的存在，所以可以为一个通道建立一个共同的成员视图。
例如，假设通道中有三个组织—A、B、C—和一个为组织C定义的锚节点peer0.orgc。当peer1.orgA联系peer0.orgC时，peer1.orgA将告诉peer0.orgC关于peer0.orgA的信息。之后，当peer1.orgB联系peer0.orgC时，peer0.orgC会告诉peer1.orgB关于peer0.orgA的信息。此时起，A和B组织将开始直接交换成员信息，而不再需要peer0.orgC的任何协助。
由于跨组织通信依赖于gossip才能正常工作，因此必须在通道配置中定义至少一个锚节点。为了高可用性和冗余，强烈建议每个组织提供自己的锚节点集。(锚节点不需要与领导节点相同！)

外部和内部端点：
为了使gossip能够有效地工作，对等节点需要能够获得自己组织中的对等节点以及其他组织中的对等节点的端点信息。当一个节点被引导/启动？时，它会使用它的core.yaml中的peer.gossip.bootstrap来广播自己，并交换成员信息，在自己的组织中构建所有可用对等节点的视图。
节点core.yaml中的peer.gossip.bootstrap属性用于引导组织内的gossip。如果你正在使用gossip，你通常会配置组织中的所有对等节点来指向一组初始引导节点(你可以指定一个以空格分隔的对等节点列表)。内部端点通常由对等节点本身自动计算，或者直接通过core.yaml中的core.peer.address显式传递。如果需要覆盖这个值，可以将CORE_PEER_GOSSIP_ENDPOINT作为环境变量导出。
建立跨组织通信同样需要引导信息。最初的跨组织引导信息是通过上面描述的“锚节点”设置提供的。如果你想让组织里的其他节点被其他组织所知，你就得设置节点的core.yaml中的peer.gossip.externalendpoint。如果不设置此值，则不会将该节点的端点信息广播给其他组织中的对等节点。要设置这些属性，请发出以下命令:

gossip消息:
在线的对等节点通过不断广播“alive/活着”消息来表明它们的可用性，每个消息都包含公钥基础设施(PKI) ID和消息发送方的签名。对等节点通过收集这些消息来维持通道成员关系；如果没有节点接收到来自某个特定节点的活动消息，则最终将从通道成员中清除此“死掉的”对等节点。由于活动消息是经过加密签名的，恶意节点永远不能模拟其他对等节点，因为它们缺少根证书颁发机构(CA)授权的签名密钥。
除了自动转发接收到的消息外，状态协调过程还同步每个通道上对等节点的世界状态。每个节点不断地从通道上的其他对等节点拉取区块，以便在发现差异时修复自己的状态。由于不需要固定连接来维护基于gossip的数据分发，因此该过程可靠地为共享账本提供了数据一致性和完整性，包括对节点崩溃的容忍性。
由于通道之间是隔离的，一个通道上的对等节点不能在其他通道上发送消息或共享信息。尽管对等节点都可以属于多个通道，但是通过应用基于对等节点通道订阅的消息路由策略，分区消息传递可以防止区块传播到不在通道中的对等节点。

点对点消息的安全性由对等节点的TLS层处理，不需要签名。对等节点通过由CA分配的证书进行身份验证。虽然也使用TLS certs，但是在gossip层中身份验证使用的是对等节点证书。账本区块由排序服务签名，然后在通道上交付给领导节点。
身份验证由对等节点的成员服务提供者管理。当对等节点第一次连接到通道时，TLS会话与成员身份绑定，这本质上是根据网络和通道中的成员身份对连接的每个对等节点进行身份验证。
///纵有疾风起，人生不言弃///
?
【Gossip数据传播协议】