[Hyperledger] Fabric系统中 peer模块的 gossip服务详解

概述     最近一直在看fabric系统中的核心模块之一——peer模块。在看peer的配置文件core.yaml的信息时，对其中的gossip配置选项很感兴趣。看了一上午，还是不能明白这个选项到底什么意思呢？表面意思很容易理解：“gossip”——“闲话”。但是在配置选项中为什么要起这么个名字呢？      后来查阅了一些资料，才知道开发者用意何为？ gossip——可最终达到一致的算法:    

     最近一直在看fabric系统中的核心模块之一——peer模块。在看peer的配置文件core.yaml的信息时，对其中的gossip配置选项很感兴趣。看了一上午，还是不能明白这个选项到底什么意思呢？表面意思很容易理解：“gossip”——“闲话”。但是在配置选项中为什么要起这么个名字呢？

     后来查阅了一些资料，才知道开发者用意何为？

gossip——可最终达到一致的算法:

 

     gossip本意是绯闻，流言蜚语，闲谈聊天的意思。而在这里，gossip代表了一种可最终达到一致的算法。其灵感来源于办公室八卦：当一个八卦在办公室出现时，在一定阶段内通过散播（dissemination），所有人最终都会知道这个八卦。这样就比较容易理解了，比如peer经过背书签名，将一个有效的交易最终提交。这份交易的写集合是A减100，B加100，因为网络中所有的结点都存有一份账本，因此该交易提交后，在有限的时间内，每个分布在网络中的结点中的账本都会应用这个交易，将自己的账本中的A减去100，B加上100。或者，有新结点加入网络中后，经过一定的时间，该新结点也会存储和其他结点一样的账本数据。

     这里需要注意是，最终一致的另外的含义就是，不保证同时达到一致，也就是在某一指定的时刻，每个结点的账本（也就是状态）不保证一致。同时，gossip不要求节点知道所有其他节点，因此具有去中心化的特性，节点之间完全对等，不需要任何的中心节点，这点也是区块链的显著特征。

gossip中有三种基本的 *** 作：

 

push - A节点将数据(key,value,version)及对应的版本号推送给B节点，B节点更新A中比自己新的数据。 pull - A仅将数据key,version推送给B，B将本地比A新的数据（Key,version）推送给A，A更新本地。 push/pull - 与pull类似，只是多了一步，A再将本地比B新的数据推送给B，B更新本地。 gossip数据传播协议：

     Fabric通过划分各个执行交易的（背书和提交）peer和ordering结点之间的工作负载来优化区域链网络的执行，安全和可测量性。网络 *** 作的解耦要求一个安全的，可信赖的，可测量的数据传播协议，以保证数据的完整性和机密性。为了达到这些要求，Fabric实现了一个gossip数据传播协议。

 

gossip协议：

peer结点“撬动”gossip以可测量的方式去广播（broadcast）账本和频道数据。gossip消息传送是是持续的，而且在频道中的每个peer不间断的从其它的peer那里接收当前的和一贯的（也就是格式等前后一致）账本数据（ledger data）。每个传播的消息都被签名过，因此“拜占庭的参与者”发送虚假的消息会很容易被识别，把消息发到消息不想到达的目标的分发行为会被阻止。peer会被延迟，网络参与者或者其他造成block丢失的原因所影响，但这些丢失block的peer最终将通过联系持有这些丢失block的peer异步更新到当前账本状态。

 

以gossip为基础的数据传播协议在Fabric网络上执行三个基础的功能：

 

通过持续性的识别有效成员peer和检测那些已经下线的peer，管理peer的发现（discovery）和频道成员关系。 在频道上所有的peer之间传播账本数据。任何持有与频道其他peer结点不同步的数据的peer识别丢失的block并通过拷贝正确的数据来同步自身。 通过允许账本数据以peer点对peer点（peer-to-peer）状态传输更新的方式，提高新加入网络的peer结点的同步速度。

     以gossip为基础的广播 *** 作是通过peer从频道中其他peer中接收消息，然后把这些消息传送到频道上一定数量随机选择的peer结点，这个数量是可配置常量。peer结点也能运用一个pull机制，而不是等待一个消息的投递。这个循环重复着，伴随着频道成员关系的结果，账本和状态信息持续保持最新且同步。对于新block的传播，在频道中的领导peer（the leader peer）从ordering服务pull数据并初始化gossip到各个peer的传播。

gossip消息传送：

 

     在线的peer结点通过持续的广播“alive”信息来（向leader或其他结点）指示其自身的有效性，每条消息中都包含PKI_ID（the public key infrastructure ID）和发送者的签名。每个peer结点也通过收集这些“alive”消息，来维护自身的频道成员关系（channel membership）。如果没有任何一个peer接收到某一特定的peer的“alive”消息，则这个“dead”peer最终会从频道成员关系中被清除。因为“alive”消息都是加密签名了的，所以恶意的peer会因缺少由root CA认证的签名匙（signing key）而不可能冒充其他正确的peer。

 

     除了自动传输接收的消息（即散播dissemination），一个状态调节进程（state reconciliation process）会通过每个频道上的众多peer结点来与世界状态（world state）同步。每个peer持续性的从频道上的其他peer那里pull来block数据，目的在于，如果（通过与自己的block数据对比）存在差异则修复自身的状态。因为固定的连接（fixed connectivity）不被要求去维护以gossip为基础的数据散播，因此这个进程会可靠的提供私密的和完整的数据到共享的账本，同时包括了对错误结点的容错度。（这里的固定的连接应该这么理解：在网络中没有发生变化的结点集合，比如A，B，C，D四个结点一直没有发生变化，因而四个结点之间的关系也不会发生变化，因此这四个结点之间就不需要去进行gossip散播消息数据。比如一个新加入的E点是与D点发生关系，则只需要D去向E散播消息，而A，B，C，D四者之间仍是不需要互相进行gossip散播的。）

 

     因为多个频道之间是被相互隔离的，所有在一个频道上的peer点不能向其他频道发送消息或分享信息。虽然任一peer都可以属于多个频道，但是依照应用的消息线路选择策略（message routing policIEs），分配的消息传送禁止把block数据散播到其他频道的peer结点，这里的消息线路选择策略是以peer的频道订阅为基础的。（关于频道订阅，参考出版-订阅消息系统，即一个peer能够接收一个频道中的消息，必须先订阅这个频道的消息。）

 

注意：

     点对点（point-to-point）消息的安全性由peer的TLS层来处理，不需要签名。peer结点凭借它们自身的证书获得认证，这些证书由一个CA分配。虽然TLS证书也被使用，但是在gossip层是该peer点的证书被验证授权（而不是TLS的证书）。账本的block由ordering服务签名，然后投递到频道中的leader peer。
认证是由peer的MSP对象管理的。当一个peer第一次连接到频道上，TLS会话（session）同成员身份绑定。这主要是使用在网络和频道中的成员关系去认证每个与新的peer发生的连接。

 

---------------------

REFERENCE：

1.https://blog.csdn.net/IDsuf698987/article/details/77898724 

2.翻译自官方文档

总结

以上是内存溢出为你收集整理的[Hyperledger] Fabric系统中 peer模块的 gossip服务详解全部内容，希望文章能够帮你解决[Hyperledger] Fabric系统中 peer模块的 gossip服务详解所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。