深度学习
每个通过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:
type MessageStore interface {
// 添加消息msg到内存中,返回是否添加成功
Add(msg interface{}) bool
// 返回存储的消息数量
Size() int
// 返回存储的所有消息
Get() []interface{}
}
具体的实现如下所示:
type messageStoreImpl struct {
pol common.MessageReplacingPolicy
lock *sync.RWMutex
messages []*msg
invTrigger invalidationTrigger
}
包含一个通用的消息验证策略函数:
type MessageReplacingPolicy func(this interface{}, that interface{})
InvalidationResult
其中,this和that指代的是当前消息和原有消息的比较,并判断当前消息的有效性。比较的结果InvalidationResult有3种可能。
1)MESSAGE_INVALIDATES:当前消息是有效的,原有消息是无效的,用当前消息替换原有消息;
2)MESSAGE_INVALIDATED:当前消息是无效的,原有消息是有效的,丢弃当前的消息;
3)MESSAGE_NO_ACTION:两个消息可能是不同类型的,两个消息不进行比较,两个消息都是有效的。
MessageReplacingPolicy可以根据实际存储的消息定义不同的比较策略。
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 不同消息类型的验证策略
来源:我是码农,转载请保留出处和链接!
本文链接:http://www.54manong.com/?id=1073
微信号:qq444848023 QQ号:444848023
加入【我是码农】QQ群:864689844(加群验证:我是码农)
全站首页 | 数据结构 | 区块链| 大数据 | 机器学习 | 物联网和云计算 | 面试笔试
var cnzz_protocol = (("https:" == document.location.protocol) ? "https://" : "http://");document.write(unescape("%3Cspan id='cnzz_stat_icon_1276413723'%3E%3C/span%3E%3Cscript src='" + cnzz_protocol + "s23.cnzz.com/z_stat.php%3Fid%3D1276413723%26show%3Dpic1' type='text/javascript'%3E%3C/script%3E"));本站资源大部分来自互联网,版权归原作者所有!
评论专区