Hyperledger Fabric 消息协议

原创
02/25 14:24
阅读数 480

Hyperledger Fabric 消息协议

Fabric中大量采用了gRPC消息在不同组件之间进行通信交互,主要包括如下几种情况:客户端访问Peer节点,客户端和Peer节点访问排序节点,链码容器与Peer节点交互,以及多个Peer节点之间的Gossip交互。

消息结构

除了Peer节点之间的Gossip通信外,大多都采用了信封(Envelope)结构来对消息进行封装.

普通信封结构并不复杂,包括一个载荷(Payload)域存放数据,以及对载荷域中内容进行签名的签名(Signature)域。载荷域中又包括头部(Header)域记录类型、版本、签名者信息等元数据,以及数据(Data)域,记录消息内容。

头部域是一个通用的结构。包括两种头部:通道头(ChannelHeader)和签名头(Signature-Header)。通道头中记录了如下与通道和交易相关的很多信息。

●Type:int32类型,代表了结构体(如Envelope)的类型。结构体消息根据类型不同,其Payload可以解码为不同的结构。类型可以为MESSAGE、CONFIG、CONFIG_UPDATE、ENDORSER_TRANSACTION、ORDERER_TRANSACTION、DELIVER_SEEK_INFO、CHAINCODE_PACKAGE、PEER_ADMIN_OPERATION等。

●Version:int32类型,版本号记录了消息协议的版本,一般为0。

●Timestamp:*google_protobuf.Timestamp类型,消息创建的时间。

●ChannelID:string类型,消息所关联的通道ID。

●TxID:string类型,交易的ID,由交易发起者创建。

●Epoch:uint64类型,所属的世代,目前指定为所属区块的高度。

●Extension:[]byte类型,扩展域。

●TlsCertHash:[]byte类型。如果启用了双向TLS认证,则此处为客户端TLS证书的Hash值。

签名头中主要记录签名者的身份信息。


客户端访问Peer节点

客户端通过SDK和Endorser Peer进行交互,执行链码相关操作(安装、实例化、升级链码以及调用),加入、列出应用通道和监听事件操作等。

除监听事件外,大部分消息都采用了SignedProposal结构(定义在fabric-protos-go项目的peer/chaincode.pb.go文件),消息中ChannelHeader.Type为ENDORSER_TRANSACTION或CONFIG,发往的gRPC服务地址为/protos.Endorser/ProcessProposal。监听事件则通过DeliverClient接口类型来实现,包括Deliver、DeliverFiltered、DeliverWithPrivateData三种方法。

SignedProposal消息结构中包括Proposal和对其的签名。Proposal消息结构中同样包括Header域、Payload域,以及扩展域。其中,Payload域和扩展域如何解码都取决于Channel-Header中的Type指定的类型。


客户端、Peer节点访问Orderer

客户端通过SDK和Orderer进行交互,执行链码实例化、调用和升级,应用通道创建和更新,以及区块结构获取等操作。Peer节点可以直接向Orderer请求获取区块结构。两者采用了同样的获取接口。

请求消息都采用了Envelope结构,并且都发往/orderer.AtomicBroadcast/Broadcast gRPC服务地址。从Orderer获取信息时,则发往/orderer.AtomicBroadcast/Deliver gRPC服务地址。


链码和Peer节点交互

对于原生链码,在链码容器启动后,会向Peer节点进行注册,gRPC地址为/protos.ChaincodeSupport/Register。对于外部链码,在其启动后,Peer节点会主动发起连接请求,gRPC地址为/protos.Chaincode/Connect。

链码和Peer之间的交互消息为ChaincodeMessage结构其中,Payload域中可以包括各种Chaincode操作消息,如GetHistoryForKey、GetQueryResult、PutStateInfo、GetStateByRange等。

注册完成后,双方建立起双工通道,通过更多消息类型实现多种交互.


Peer节点之间Gossip交互

Peer之间可以通过Gossip协议来完成邻居探测、Leader选举、区块分发、私密数据同步等过程,主要原理为通过GossipClient客户端的GossipStream双向流进行通信,发送Signed-GossipMessage消息结构,gRPC服务地址主要为/gossip.Gossip/GossipStream。

此外,Peer可通过单独的Ping服务对远端节点在线状态进行探测,gRPC服务地址为/gossip.Gossip/Ping。

Gossip交互过程

总结Gossip交互过程如图14-16所示。利用不同的消息体,完成Peer之间的信息同步。


Gossip消息结构

Gossip采用签名信封结构(SignedGossipMessage)用来封装Gossip消息(GossipMessage)和对应的信封结构(Envelope)。


Gossip消息标签

GossipMessage为核心的数据结构。其可能的标签值(GossipMessage_Tag)如下所示,这些标签默认带有GossipMessage前缀。

●UNDEFINED:标签未定义,当标签为空时返回该值。

●EMPTY:空标签,用于建立连接、心跳、请求和响应成员消息。

●ORG_ONLY:仅限组织内消息,如私密数据。

●CHAN_ONLY:仅限通道内消息。

●CHAN_AND_ORG:限通道内同一组织内,如获取区块数据。

●CHAN_OR_ORG:限通道内或限组织内,如状态信息。


Gossip消息内容结构

GossipMessage通过消息内容类型来应用到不同场景。合法的消息内容结构(isGossipMessage_Content)下面详细介绍,这些结构默认带有GossipMessage前缀。

(1)成员消息适用于邻居发现场景,定期维护存活的邻居信息,不局限在通道内,主要由gossip/discovery模块实现。

(2)拉取消息

适用于从远程节点拉取身份或区块数据,主要数据结构为:gossip/gossip/pull/pullstore.go#Mediator和gossip/gossip/algo/pull.go#PullEngine。包括如下两种消息类型:

●PullMsgType_IDENTITY_MSG,获取对方的身份信息,消息标签为EMPTY,不局限在通道内。

●PullMsgType_BLOCK_MSG,获取区块数据。消息标签为CHAN_AND_ORG,局限在通道内的同一组织内。

(3)数据消息

适用于从远程节点同步区块或私密数据。

(4)状态消息

适用于与远程节点同步账本状态。

(5)其他消息

其他消息包括连接消息、选举Leader消息和空消息。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部