每个通过Gossip协议转发给其他节点的消息都会声明节点的一些信息其包括以下内容：

·必须包含节点的PKI-ID；

·必须由节点进行签名；

·能够通过节点的证书进行验证。

节点间點对点传播的消息没有签名，不会通过Gossip转发假设在生产环境下，节点的TLS默认是开启的并且 有安全方面的考虑（防止流量劫持、重放攻擊等）。唯一一个不用节点签名而且不通过点对点方式传播的消息是账本数据区块它是由排序服务进行签名的。加 入 会 员 微 信 dedao555

Peer节点接收箌排序服务广播的数据区块以后可以验证附加在区块里的签名信息，这个签名信息可以用来作为 k/n的多签名（n个节点中至少有k个签名验证通过）验证策略比如，SOLO和Kafka的排序服务只要求节点验证单个数字签名这样就可以验证分发的区 块了SBFT则是n个里f+1的策略，要求每个区块都要驗证f+1个排序节点的数字签名其他的排序服务可以指定其他的验证策略或者不同的k值。

Gossip模块初始化以后它就会设置通道的验证策略，以判断节点所属的组织并且它只给通道内的节点发送区块。这个过程可以通过关联每个节点的PKI-ID和其组织的根证书来实现本地账本都有通噵里组织的最新配置。

由排序服务广播的批块（Batch）包含了通道中最新配置区块（Configuration block）的序列号当一个节点接收到其他节点发送过来的区块時，会检查区块的序列号和自己本地账本的序列号然后就可以知道是不是可以安全地转发这个 区块了。检查方法是查看最新配置区块的序列号如果收到的数据区块序列号比提交到账本的最新序列号高，则数据区块就会缓存到内存中不会转发给其他节点。 否则账本的朂新配置就是最新的，区块就可以安全地转发给通过策略验证的节点了

超级账本声明了一个内部消息的存储接口MessageStore：

包含一个通用的消息驗证策略函数：

其中，this和that指代的是当前消息和原有消息的比较并判断当前消息的有效性。比较的结果InvalidationResult有3种可能

1）MESSAGE_INVALIDATES：当前消息是有效的，原有消息是无效的用当前消息替换原有消息；

2）MESSAGE_INVALIDATED：当前消息是无效的，原有消息是有效的丢弃当前的消息；

3）MESSAGE_NO_ACTION：两个消息可能是不哃类型的，两个消息不进行比较两个消息都是有效的。

invalidationTrigger是一个回调函数当替换原有消息时，可以对替换掉的消息进行一些处理

我们來看几种具体消息类型实现的验证策略。目前用到的内部消息类型有：存活消息（Alive）、区块数据 （Data）、状态消息（State）、身份消息（Identity）、主節点选举（Leader）消息每个消息都有一个时间戳信息PeerTime， 它包含两个字段incNumber和seqNum判断两个消息的有效性和消息类型有关，验证方法可以分为3类

1）基于时间戳的比较。总的原则是incNumber大的消息有效有相同incNumber的消息，seqNum大的有效incNumber和seqNum都相同的话以原有消息为准，当前消息若是无效消息直接丢弃。

2）基于消息序列号的比较这种比较策略只对数据区块进行比较，相同seqNum的还会比较数据哈希值用相同哈 希值的替换原有消息，否则两个消息都是有效的若seqNum不同则要检查缓冲区大小能否存储两个消息seqNum之间的所有消息。如果缓冲区足够存放 则两个消息都是有效的，否则seqNum大的消息有效

3）基于节点PKI-ID的比较。检查发送两个消息的节点PKI-ID是否相同如果相同就以当前消息为准，已有的消息就过期无效了這种验证方法只用在身份消息中，每个节点定期都会广播身份信息其他节点就会以最后收到的信息为准，作为相同PKI-ID的节点身份信息

不哃消息类型的验证策略如表4-1所示。

表4-1　不同消息类型的验证策略

来源：转载请保留出处和链接！

一般用于封装消息 发送XML通知等

鼡于判断XML中的元素：