深度学习
数据传播机制(Datadissemination)的底层是由基于Gossip的节点通信支撑的。在这种模式下,不会构建每个节点之间的分离路径(disjointpath)信息,而是每个节点每次都随机性地选择k个节点来扩散消息。节点在某个时间点随机性地选择节点交换信息,信息流就在整个系统中流动起来了。这种交互方式比固定结构的方式更健壮,而且在遇到节点变动或者拜占庭问题的时候更容易维护。而且,固定结构的模式保留了每个节点之间的分离路径信息,消息复杂度会更大。注意,一个节点在随机选择其他节点时,它可以参考当前的成员视图、前一段时间的历史存活节点、启动集合,以及所有节点的列表等信息。每个节点有更高的出度(OutgoingDegree),不同节点独立选择不同的传播路径,这能够保证
创建通道是为了限制信息传播的范围,是和某一个账本关联的。每个交易都是和唯一的通道关联的。这会明确地定义哪些实体(组织及其成员)会关注这个交易。客户端SDK通过发送一个CONFIGURATION的交易背书(Endorsement)请求来创建一个通道,然后通过排序服务广播给其他节点。创建通道的请求包含组成通道的组织(Organization)列表,即哪些组织可以加入到这个通道中。一旦创建好了通道,客户端SDK就可以通知组织内的节点加入到新创建的通道中。节点的Gossip模块就会给这通道内的组织广播一个消息:它属于这个通道了。Gossip要在多通道环境下还能正常工作,成员管理需要对通道内的成员节点进行维护,也就是说通道内的所有节点都需要知道其他节点的存在。代表一个组织和排序服务进行连接的节点会
每个通过Gossip协议转发给其他节点的消息都会声明节点的一些信息,其包括以下内容:·必须包含节点的PKI-ID;·必须由节点进行签名;·能够通过节点的证书进行验证。节点间点对点传播的消息没有签名,不会通过Gossip转发。假设在生产环境下,节点的TLS默认是开启的,并且有安全方面的考虑(防止流量劫持、重放攻击等)。唯一一个不用节点签名而且不通过点对点方式传播的消息是账本数据区块,它是由排序服务进行签名的。加入会员微信dedao555Peer节点接收到排序服务广播的数据区块以后,可以验证附加在区块里的签名信息,这个签名信息可以用来作为k/n的多签名(n个节点中至少有k个签名验证通过)验证策略。比如,SOLO和Kafka的排序服务只要求节点验证单个数字签名这样就可以验证
和Gossip相关的配置参数如下所示:#启动连接节点,可以是多个bootstrap:127.0.0.1:7051#自动选择主节点还是指定主节点useLeaderElection:false#只在useLeaderElection设置为false的时候生效orgLeader:true#本地节点的ID:ip:portendpoint:#区块缓冲区大小maxBlockCountToStore:100#消息推送间隔(毫秒)maxPropagationBurstLatency:10ms#消息推送缓冲区大小maxPropagationBurstSize:10#消息推送次数propagateIterations:1#消息推送节点数propagatePeerNum:3#消
第5章 分布式账本存储分布式账本技术(DLT,DistributedledgerTechnology)还有一个名称叫共享账本(SharedLedger),通过在不同节点之间达成共识,记录相同的账本数据,这是区块链技术的基础。本章讨论在HyperledgerFabric1.0中分布式账本技术的实现。5.1 概述超级账本采用背书/共识(Endorsement/Consensus)模型,模拟执行和区块验证是在不同角色的节点中分开执行的。模拟执行是并发的,这可以提高扩展性和吞吐量:·在背书节点(EndorsingPeer)处模拟执行链码(Chaincode);·在所有的Peer节点上验证交易并提交。加入会员微信dedao555每个Peer节点会维护多个账本,如图5
5.2.1 交易模拟和读写集在背书节点(Endorser)模拟执行交易的过程中,会生成读写集(Read-WriteSet)。读集(ReadSet)包含了唯一键的列表,还有在模拟执行过程中交易读取的已提交键值。写集(WriteSet)也包含了一个唯一键的列表,还有在模拟执行过程中交易写的键值。交易过程中有删除键,它会记录删除标记。如果在一个交易中对同一个键进行了多次更新,则会以最后一个为准。交易只会读取已提交的数据,即使在交易中更新了某个键的值。就是说,不支持读取本次交易更新后的结果。读集会包含键的版本,写集只会包含键的最新值。版本号是使每个键不重复的唯一标识,实现的方法有很多,比如可以采用单调递增的数值来表示。在目前的实现中,采用的是区块链的高度来表示,一个交易中所有键
超级账本支持多账本(详细内容可以参考第7章的相关内容),每个账本的数据是分开存储的。账本编号(LedgerID)的数据存储在LevelDB数据库中,只是记录了有哪些账本,创建新的账本会检查是否有相同的账本编号存在,这保证了全局唯一性。账本编号库并不存储与区块相关的数据,这和后面的区块索引不一样。
账本数据(Ledger)是以二进制文件的形式存储的,每个账本数据存储在不同的目录下。后面的内容都是在已经区分了账本的情况下再对数据进行查询的。基于文件系统的区块存储实现了如下功能接口。1)账本存储管理。·提交区块到账本(AddBlock)·获取区块链信息(GetBlockchainInfo)·获取区块数据(RetrieveBlocks)·关闭区块存储(Shutdown)2)索引管理:跟踪区块和交易保存在哪个文件。·根据哈希值获取区块(RetrieveBlockByHash)·根据区块编号获取区块(RetrieveBlockByNumber)·根据交易编号获取交易(RetrieveTxByID)·根据区块编号和交易编号获取交易(RetrieveTxByBlockNumTranNum)·根据交易