HyperLedger Fabric 1.2 关键技术(6.4)

  • 时间:
  • 浏览:0
  • 来源:大发彩神6合_大发神彩6合官方

ChaincodeMessage_GET_STATE

          设置default.replication.factor为N(数字),N表示在Kafka节点上每个channel都保存N个副本的数据;值的范围为1<K(K为Kafak集群数量);

       排序(Orderer)指对区块链网络中不同通道产生的交易进行排序,并广播给节点(Peer)。排序(Orderer)是以可插拔组件的方式实现,目前分为SOLO和Kafka并否是类型。

ChaincodeMessage_GET_QUERY_RESULT

9) 上述消息交互过程完成后,节点(Peer)和链码(chaincode)会定期相互发送 ChaincodeMessage_KEEPALIVE 消息给对方,以确保彼此是在线状况。

D1:Block data 区块数据

       节点(Peer)是区块链的交易正确处理和账本维护的主体,主要负责参与共识过程和通过执行链码(chaincode)实现对账本的读写操作。节点(Peer)根据功能不同分为背书节点(Endorser peer)和提交节点(Committer peer);根据通讯不同分为锚节点(Anchor peer)和主节点(Leading peer)。

1) Package: Hyperledger Fabric Client

2

帐本价值形式图如下:

O:Orderer 排序

区块链保存到文件系统时,会在LevelDB 中存储区块交易对应的文件块及其偏移,也就是将 LevelDB 作为账本数据库的索引。文件形式的区块存储方式就是这麼快速定位的索引,这麼查询区块交易信息会非常的慢。

5) 链码容器收到 ChaincodeMessage_INIT 消息事先,调用用户代码 Init()方式进行初始化,成功事先,返回 ChaincodeMessage_COMPLETED 消息。到此,链码容器还要被调用了。

       Hyperledger Fabric提供了你并否是SDK来支持各种编程语言,目前正式发布了Node.js和Java并否是版本的SDK。将来以后发布Python、Go、REST版本的SDK,还在测阶段。

 区块链(Blockchain):

图:客户端与节点交互

     在orderer.yaml文件中配置Kafka.TLS参数,取舍否是通过TLS(安全传输层协议)进行通信。

程序运行运行与节点交互图:

         设置min.insync.replicas为M(数字),数据提交以后写入为宜M个副本,值的范围为1<M<N(N为default.replication.factor值);

     8) 集群启动顺序

智能合约安放入去节点(Peer)上,运行在Docker容器中,通过gRPC与Peer进行数据交互,交互步骤如下:

5)排序(Orderer)把涵盖交易信息的区块发送给节点(Peer); 

6.3.4 节点(Peer)

ChaincodeMessage_QUERY_STATE_CLOSE

H1-H2:H2 is chained to H1 区块2指向区块1

7) 链码在收到 ChaincodeMessage_TRANSACTION 消息事先,会调用 Invoke()方式,根据Invoke方式中用户的逻辑,还要发送如下的消息给节点(Peer):

功能

1

2) 节点(Peer)在收到来自链码容器的 ChaincodeMessage_REGISTER 消息后,会注册到本地的有另另一个多多handle价值形式,返回 ChaincodeMessage_REGISTERED 消息给链码容器。就是更新状况为 established ,然以后自动发出 ChaincodeMessage_READY 消息给链码(chaincode),就是更新状况为ready。

     先启动ZooKeeper 集群,就是启动 Kafka 集群,最后启动排序(Orderer)节点。

 账本索引数据库(Block index):

CouchDB:适用于支持充足的查询和数据类型的场景,应用系统作为JSON文档存储时,CouchDB是有另另一个多多有点硬为宜的取舍,支持对chaincode数据进行充足的查询。

 状况数据库(State Database):

User

N:Blockchain Network区块链网络

L:Ledger 账本

      5) 所有排序(Orderer)节点都指向创世区块

1)程序运行运行成功连接到节点(Peer)后,调用链码向节点(Peer)进行提案;

 

P:Peer 节点

说明:

2

状况数据库是存储所有在交易中老出 的键值对的最新值,调用链码执行交易还要改变状况数据,为了高效的执行链码调用,所有数据的最新值都被存倒进状况数据库中;状况数据库被设计为组件,还要通过配置替换数据库,目前有LevelDB和CouchDB并否是数据库, LevelDB是默认的内置的数据库。

H1-H2:H2 is chained to H1 区块2指向区块1

代表网络上的计算节点。节点的角色有背书节点和提交节点,它们都有维护着账本。应用就是连接到一定数量的可用的节点

提案调用背书节点的响应,打包背书结果(是或否),签名,等等。这是关于提案响应原始的GRPC消息包装类,它提供了便利的方式来利用它当事人的内容(背书,签名,等等)。

当排序(Orderer)节点通过RPC广播(Broadcast)接收到从节点(Peer)来的交易数据时,先判断发送交易的客户端否是有权限正确处理该通道(Channel)数据,就是有权限,排序(Orderer)节点会把交易保存到Kafka的分区(partition)中,每个通道(Channel)对应Kafka中的单独的单分区(partition)的类别中(topic)。

等级

3

模块

代表在网络上交易的用户。用户实例还要基于登记证书被初始化。证书还要从成员服务就是组织组织结构CA获取。理论上,你你并否是用户也能代表网络上的节点成员。然而,这与程序运行运行无关(这更像是网络管理方面的什么的问题),所以在你你并否是设计中这麼开放。

C:Channel 通道

        本节介绍从最底层的账本事先刚现在现在开始,逐一讲解账本的价值形式和存储、智能合约的编写和部署、通道的操作、节点的背书和提交、排序的共识和客户端SDK的接口调用,与交易流程顺序相反,由里及表的说明Fabric最关键的技术,通过学习了这六种关键技术知识,能初步掌握Fabric的核心,了解Fabric运作原理。

       Fabric SDK应该还要为开发人员提供编写程序运行运行的多种操作区块链网络的方式。程序运行运行还要部署/执行chaincode,监听网络中产生的事件,接收块信息,把交易存储到账本中等。

A:Application 程序运行运行

排序(Orderer)节点(Ordering Service Node)简称为OSN,Orderer集群连接到Kafka集群和Zookeeper集群,利用Kafka的共识功能,实现网络中交易的排序跟生成区块的任务。

T5:Transaction 交易数据,保占据 区块数据中

2)节点(Peer)根据提案信息调用链码;

          设置unclean.leader.election.enable为false;

 

       Fabric SDK提供调用账本(Ledger)、智能合约(Smart contract)、通道(Channel)、节点(Peer)、排序(Orderer)等接口,方便用第三方程序运行运行的开发,大大扩展了Fabric的应用场景。

       2)设置区块最大容量

H3:Block header 区块头

4)程序运行运行发送交易信息给排序(Orderer);

S:Chaincode 链码

     在orderer.yaml 文件中配置Kafka.Retry参数, 调整 metadata/producer/consumer 请求的频率以及socket的超时时间。

通道价值形式图:

A:Application 客户端

上图中区块图示说明:

Kafka正确处理流程示意图:

6.3.6 接口(SDK)

kafka集群节点的最小值为4,是故障容错所还要的最小数值。三个小kafka结点还要容许有另另一个多多节点崩溃后,所有的通道(Channel)还要继续读写且创建通道。

CryptoSuite

图:链码与节点消息交互

6)节点(Peer)把交易区块更新到账本中,最终完成正确处理;

6.3.1 帐本(Ledger)

       1)在网络的创世块中写入Kafka相关的信息

图:Kafka正确处理流程示意图

功能

3. 排序(Orderer)操作步骤

 zookeeper还要为3,5或7。它还就是有另另一个多多奇数来正确处理分裂(split-brain)情景,一起取舍大于1是为了正确处理单点故障,超过7个ZooKeeper节点是多余的。

P:Peer 节点

ChaincodeMessage_INVOKE_CHAINCODE

主要的入口模块。它还要允许用户创建还要的任何对象来执行所有支持的操作,类式直接连接网络,chaincode部署,交易执行,多种查询。另外,基于编码规范和普遍的社区练习,每并否是语言的实现也能决定否是再加方便的方式,如sendTransaction(chain, tx)

1) 链码(chaincode)调用 shim.Start()方式后,给节点(Peer)发送 ChaincodeMessage_REGISTER 消息尝试进行注册。客户端链码等待时间接收来自节点(Peer)的消息。此时链码(chaincode)和节点(Peer)的状况为初始的created。

ChaincodeMessage_QUERY_STATE_NEXT

排序(Orderer)节点使用该分区(partition),将接收到交易分组写入到本地区块中,并加入到本地的区块链中,最后通过RPC传输(Deliver)给还要接收的客户端。

      在 orderer.yaml 文件中配置 General.GenesisFile参数, 让排序(Orderer)节点指向步骤3中所创建的初始区块。

4) 节点(Peer)发出 ChaincodeMessage_INIT 消息给链码容器,对链码进行初始化。

上图中通道图示说明:

3)链码进行查询和更新,就是返回提案信息给程序运行运行;

      3)创建创世区块

Orderer

       背书节点(Endorser peer):背书节点(Endorser peer)负责对交易根据事先设定策略进行签名背书,背书节点(Endorser peer)根据链码在实例化的事先设置背书策略,指定那此节点用于背书。当客户端向节点发起交易背书时,该Peer节点才雎有背书功能,其它时间就是普通的记账节点。

这是fabric可选模块的客户端,成员服务。本模块的主要功能是从成员服务获取用户登记证书。另外,你你并否是模块并否是或它的扩展类也应该能在fabric默认的成员服务的实现中提供可用的额外的功能,如用户注册功能。

登记的用户还要向节点列表提出交易提案来背书交易。一旦接收到背书响应,程序运行运行还要决定否是就是获取背书签名,否是还要执行提交交易到共识服务。这是关于提案原始的GRPC消息的包装类,它提供了便利的创建方式。

6) 链码(chaincode)被调用的事先,节点(Peer)发出 ChaincodeMessage_TRANSACTION 消息给链码。

ProposalResponse

每个通道都有属于当事人的锚节点,通过锚节点还要与其它通道进行信息交互,但并否是通道内的账本不必通过有另另一个多多通道传到从前通道上,通道对账本是分离的。

6.3.3 通道(Channel)

S:Chaincode 链码

加密模块打包了数字签名算法,非对称加密的密钥对,对称加密的密钥消息,安全的hashMAC

       智能合约又称为链码,是在区块链上运行的一段代码,是应用系统与区块链底层交互的上方件,通过智能合约还要实现各种僵化 的应用。

Proposal

Transaction

PA-C:Principal PA(e.g. A,P1)communicaties via channel C 客户端A与节点P(Peer)通过通道C(channel)进行通信。

       正式环境中还要使用Kafka搭建,保证数据可靠性和安全性,以下介绍基于Kafka集群和ZooKeeper集群的排序服务的原理。

3

接口模块如下:

N:Blockchain Network区块链网络

2

3

      6)调整轮询间隔和超时时间

       Fabric帐本(Ledger)是一系列有序和防篡改的状况转换的记录,价值形式由有另另一个多多区块链构成,并将不可变的、有序的记录存倒进区块中;一起包涵盖另另一个多多状况数据库来记录当前的状况,账本的当前状况信息是链交易日志中记录过的所有键的最新值,就是当前状况表示的是通道已知的所有键的最新值,由此也被称为世界状况。区块链价值形式保占据 本地的文件系统中;世界状况由数据库来维护,以键值对(k-v)的方式保占据 数据库,默认数据库为LevelDB,数据库版本可替换为KV类型的数据库,如CouchDB等。

2. Kafka集群和ZooKeeper集群的节点数量规定

       历史状况数据库用于查询某个 key 的历史修改记录,历史数据库暂且存储 key 具体的值,而只记录在某个区块的某个交易里,某 key 变动了一次,后续还要查询的事先,根据变动历史去查询实际变动的值,着实减少了数据的存储,当然也增加了查询逻辑的僵化 度。

类式节点,不同的是它代表排序服务的终端,就是是有另另一个多多单独的节点(开发时本地安装)就是有另另一个多多网络排序者的代理节点。基于区块链网络的fabric会有另另一个多多多由多个排序者节点组成的单独的排序服务。应用还要取舍信任特定的排序者,就是一要素排序者,就是设置代理去给排序者节点广播交易。

ChaincodeMessage_GET_HISTORY_FOR_KEY

3

Peer

      主节点(Leading peer):主节点(Leading peer)负责与排序(Orderer)通信,把共识后的区块传输到你并否是节点。

6.3.2 智能合约(Smart contract)

图:帐本价值形式图

目前使用Go语言来开发智能合约以外,还要使用java、node.js开发,支持最好的还是Go语言。

ChaincodeMessage_GET_STATE_BY_RANGE

       区块最大容量在configtx.yaml文件中设置Orderer.AbsoluteMaxBytes项的值,以字节为位置,不包括区块头信息大小。

       记账节点(Committer peer):记账节点(Committer)负责维护状况数据和账本的副本。

          设置log.retention.ms为-1,关闭基于时间的日志保留方式。

8)节点(Peer)在收到那此消息事先,会进行相应的正确处理,并回复 ChaincodeMessage_RESPONSE 消息。最后,链码(chaincode)会回复调用完成的消息 ChaincodeMessage_COMPLETE至节点(Peer)。

          设置message.max.bytes值,message.max.bytes应该严格小于socket.request.max.bytes的值,socket.request.max.bytes的值默认被设置为400MB;

      7) 设置排序节点和 Kafka 集群间为SSL 通讯

1.Kafka正确处理概述

        区块链(Blockchain)是基于本地文件系统,将区块存储于文件系统的硬盘中,每个区块中保存有区块头(Block header)、区块数据(Block data)、区块元数据(Block metadata),通过区块头中的前有另另一个多多区块的哈希值(Previous Block Hash)指向前有另另一个多多区块的当前哈希值(Current Block Hash),连接成区块链。

Fabric是多通道设计,系统还要创建多条通道,某个节点(Peer)还要加入到不同的通道中,在每个通道涵盖自身的创世区块和实例化智能合约(Smart contract)。

 

通道是有另另一个多多节点(Peer)或多个节点之间信息通信的私有空间,在通道内的交易的数据与通道外隔绝,保证通道内数据的安全。在网络上的交易都有在某个通道(Channel)上执行,参互交易的每个成员都还要进行身份验证和授权,也能在通道(Channel)上进行正确处理。

6.3.5 排序(Orderer)

Client

 历史状况数据库(History index)

B1:Block 区块

M3:Block metadata区块元数据

LevelDB:适用于简单的链值对k-v场景,LevelDB嵌入在peer程序运行中。

MemberService

模块

有另另一个多多链代表你并否是节点有点硬形成的有另另一个多多网络,启动有另另一个多多共识的通道,在通道中交易还要被独立的正确处理。有另另一个多多网络就是有另另一个多多多或多个链。链上的节点维护有另另一个多多单独的账本涵盖交易在链上分派,包括成员关系的任何配置。所有的交易都有在链上发送,有另另一个多多应用就是操作多个链。

       使用 configtxgen 工具,根据步骤1和2中配置生成创世区块。

          设置replica.fetch.max.bytes值,每个通道获取的消息的字节数;

B:Blockchain 区块链

上图中通道图示说明:

图:通道价值形式图

Chain

3) 链码(chaincode)在收到 ChaincodeMessage_REGISTERED 消息事先,先不进行任何的操作,完成注册步骤。更新状况为 established 。在收到 ChaincodeMessage_READY 消息事先再更新状况为 ready 。

2)   Package: Member Service

       锚节点(Anchor peer):锚节点(Anchor peer)是随通道(Channel)占据 ,是能被其它通道发现的的节点(peer),每个通道(channel)上有另另一个多多多或多个锚节点(Anchor peer)。

L:Ledger 账本

登记用户分派了背书事先还要提交交易。交易请求涵盖背书签名和MVCC+post-image,就是使用排序服务API。交易有并否是类型:部署和执行。这是交易有关原始GRPC消息的包装类,它提供了便利的创建方式。

      4) 配置Kafka集群

交互流程:

       在生成创世区块时,还要在configtx.yaml文件中配置Kafka相关的信息,如Orderer.OrdererType设置为kafka、Orderer.Kafka.Brokers设置Kafka集群中的节点IP地址和端口;

       SOLO:仅有另另一个多多多Orderer服务节点负责接收交易信息进行排序,是最简单的排序算法,一般用于测试环境。

等级

       Kafka:是由Apache软件基金会开发的有另另一个多多开源流正确处理平台,并否是高吞吐量的分布式发布订阅消息系统,它还要正确处理消费者规模的网站中的所有动作流数据,还要配置多个排序节点集群方式,以便使用在生成环境。Hyperledger Fabric利用kafka的高吞吐、低延时的价值形式,对交易信息进行排序正确处理,实现在集群组织组织结构支持节点故障容错。