Hyperledger Fabric Gossip协议：区块消息接收位置及相关技术咨询

需求背景 #

已完成特殊区块创建逻辑，需定位Gossip协议中区块消息接收源码，实现自定义逻辑：当节点通过Gossip收到含Endorser Transaction的区块时，生成带特殊标签、节点签名且无背书策略的新区块。目前追踪到comm_impl.go的Accept函数、gossip_impl.go的start函数初始化接收协议并调用handleMessages协程，但该协程仅处理stateInfoMsg、LeadershipMsg、PullMsg；channel.go的HandleMessage中有isDataMsg判断，但调试时从未触发，仅stateInfoMsg和stateInfoPullRequestMsg生效。

1. stateInfoMsg的作用是什么？与PullMsg、DataMsg有何区别？ #

• stateInfoMsg：节点向集群内其他节点广播自身账本状态元数据的消息，核心包含已同步的区块高度、链ID等信息，用于让集群节点感知彼此的状态差异，为后续数据拉取提供依据。
• PullMsg：节点发现自身账本状态落后时，主动发送的区块拉取请求消息，用于指定拉取某段范围的区块数据。
• DataMsg：携带实际区块（或批量交易）数据的消息，是节点间同步账本实体数据的核心载体。

三者核心区别：stateInfoMsg传递状态元数据，PullMsg传递拉取指令，DataMsg传递实际业务数据。

2. DataMsg是什么？为何其判断从未为真？ #

• DataMsg：Gossip协议中专门用于传输区块（或批量交易）实体数据的消息类型，是节点间同步账本核心数据的载体。
• 判断未触发的原因：
  • 架构中仅1个排序节点时，Peer节点默认优先从排序节点的deliver服务拉取区块，而非通过Gossip的DataMsg同步，只有当节点无法连接排序节点时，才会触发Gossip的DataMsg同步逻辑。
  • 调试时节点已完成账本同步，无区块拉取需求，因此不会接收DataMsg。可尝试让某个节点初始无区块，启动后观察是否触发该判断。
  • Gossip配置可能未开启数据同步参数，比如peer.gossip.useLeaderElection或peer.gossip.orgLeader配置不当，导致节点未进入Gossip数据同步流程。

3. 节点从锚节点接收区块后，如何/在何处存储区块？ #

节点通过Gossip（或deliver服务）收到区块后，存储流程核心源码位置及逻辑：

• 区块首先会被传递到core/ledger/ledger.go的CommitLegacy方法，由该方法负责将区块提交到账本。
• 底层存储分为两部分：
  • 区块原始数据存储在文件系统的peer/ledgersData/chains目录下，对应core/ledger/blkstorage包的实现。
  • 区块中的交易数据、状态数据会更新到世界状态数据库（如LevelDB、CouchDB），对应core/ledger/state包的实现。
• 若通过Gossip接收区块，数据会先经过gossip/channel/channel.go的处理逻辑，验证后传递给账本模块执行提交存储操作。

内容的提问来源于stack exchange，提问作者JustARandomProgrammer