HyperLedger Fabric 1.2 关键技术(6.4)

  • 时间:
  • 浏览:1

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

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

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

P:Peer 节点

      3)创建创世区块

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

Peer

2) 节点(Peer)在收到来自链码容器的 ChaincodeMessage_REGISTER 消息后,会注册到本地的另二个 多handle形态学 ,返回 ChaincodeMessage_REGISTERED 消息给链码容器。我你前会 更新情况报告为 established ,然总要自动发出 ChaincodeMessage_READY 消息给链码(chaincode),我你前会 更新情况报告为ready。

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

模块

5) 链码容器收到 ChaincodeMessage_INIT 消息我你前会 ,调用用户代码 Init()最好的办法进行初始化,成功我你前会 ,返回 ChaincodeMessage_COMPLETED 消息。到此,链码容器还不能被调用了。

ChaincodeMessage_GET_QUERY_RESULT

登记用户挂接了背书我你前会 还不能提交交易。交易请求富含背书签名和MVCC+post-image,我你前会 使用排序服务API。交易有并全部都是类型:部署和执行。这是交易有关原始GRPC消息的包装类,它提供了便利的创建最好的办法。

 情况报告数据库(State Database):

Chain

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

S:Chaincode 链码

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

功能

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

N:Blockchain Network区块链网络

2

等级

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

Client

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

3. 排序(Orderer)操作步骤

 

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

O:Orderer 排序

L:Ledger 账本

通道是另二个 多节点(Peer)或多个节点之间信息通信的私有空间,在通道内的交易的数据与通道外隔绝,保证通道内数据的安全。在网络上的交易全部都是在某个通道(Channel)上执行,参互交易的每个成员都需用进行身份验证和授权,不能在通道(Channel)上进行防止。

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

P:Peer 节点

每个通道全部都是属于被委托人的锚节点,通过锚节点还不能与其它通道进行信息交互,但并全部都是通道内的账本我不要 通过另二个 多通道传到我你前会 通道上,通道对账本是分离的。

N:Blockchain Network区块链网络

3

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

     8) 集群启动顺序

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

2

A:Application 客户端

       2)设置区块最大容量

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

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

ChaincodeMessage_QUERY_STATE_NEXT

6) 链码(chaincode)被调用的我你前会 ,节点(Peer)发出 ChaincodeMessage_TRANSACTION 消息给链码。

6)节点(Peer)把交易区块更新到账本中,最终完成防止;

B:Blockchain 区块链

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

6.3.1 帐本(Ledger)

6.3.4 节点(Peer)

登记的用户还不能向节点列表提出交易提案来背书交易。一旦接收到背书响应,应用多线程 还不能决定否是可能性获取背书签名,否是需用执行提交交易到共识服务。这是关于提案原始的GRPC消息的包装类,它提供了便利的创建最好的办法。

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

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

模块

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

1

3

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

 

CouchDB:适用于支持雄厚的查询和数据类型的场景,应用系统作为JSON文档存储时,CouchDB是另二个 多有点硬大概 的选泽,支持对chaincode数据进行雄厚的查询。

应用多线程 与节点交互图:

8)节点(Peer)在收到这些 消息我你前会 ,会进行相应的防止,并回复 ChaincodeMessage_RESPONSE 消息。最后,链码(chaincode)会回复调用完成的消息 ChaincodeMessage_COMPLETE至节点(Peer)。

ChaincodeMessage_GET_STATE

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

交互流程:

图:Kafka防止流程示意图

Proposal

       Fabric帐本(Ledger)是一系列有序和防篡改的情况报告转换的记录,形态学 由另二个 多区块链构成,并将不可变的、有序的记录存插进区块中;同去富含另二个 多情况报告数据库来记录当前的情况报告,账本的当前情况报告信息是链交易日志中记录过的所有键的最新值,可能性当前情况报告表示的是通道已知的所有键的最新值,由此也被称为世界情况报告。区块链形态学 保存在本地的文件系统中;世界情况报告由数据库来维护,以键值对(k-v)的最好的办法保存在数据库,默认数据库为LevelDB,数据库版本可替换为KV类型的数据库,如CouchDB等。

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

 历史情况报告数据库(History index)

这些节点,不同的是它代表排序服务的终端,可能性是另二个 多单独的节点(开发时本地安装)可能性另二个 多网络排序者的代理节点。基于区块链网络的fabric会另二个 多多由多个排序者节点组成的单独的排序服务。应用还不能选泽信任特定的排序者,可能性一每项排序者,可能性设置代理去给排序者节点广播交易。

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

B1:Block 区块

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

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

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

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

M3:Block metadata区块元数据

图:帐本形态学 图

上图中区块图示说明:

7) 链码在收到 ChaincodeMessage_TRANSACTION 消息我你前会 ,会调用 Invoke()最好的办法,根据Invoke最好的办法中用户的逻辑,还不能发送如下的消息给节点(Peer):

ChaincodeMessage_QUERY_STATE_CLOSE

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

6.3.5 排序(Orderer)

       Hyperledger Fabric提供了许多SDK来支持各种编程语言,目前正式发布了Node.js和Java并全部都是版本的SDK。将来总要发布Python、Go、REST版本的SDK,还在测阶段。

等级

1.Kafka防止概述

6.3.6 接口(SDK)

 zookeeper还不能为3,5或7。它需用是另二个 多奇数来防止分裂(split-brain)情景,同去选泽大于1是为了防止单点故障,超过7个ZooKeeper节点是多余的。

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

User

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

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

     先启动ZooKeeper 集群,我你前会 启动 Kafka 集群,最后启动排序(Orderer)节点。

          设置log.retention.ms为-1,关闭基于时间的日志保留最好的办法。

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

Kafka防止流程示意图:

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

3

1) 链码(chaincode)调用 shim.Start()最好的办法后,给节点(Peer)发送 ChaincodeMessage_REGISTER 消息尝试进行注册。客户端链码等候接收来自节点(Peer)的消息。此时链码(chaincode)和节点(Peer)的情况报告为初始的created。

MemberService

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

D1:Block data 区块数据

代表在网络上交易的用户。用户实例还不能基于登记证书被初始化。证书还不能从成员服务可能性内部人员CA获取。理论上,这些 用户不能代表网络上的节点成员。然而,这与应用多线程 无关(这更像是网络管理方面的问题图片报告 ),什么都有在这些 设计中没法开放。

H3:Block header 区块头

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

2

C:Channel 通道

功能

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

Transaction

1) Package: Hyperledger Fabric Client

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

Orderer

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

 

 区块链(Blockchain):

图:链码与节点消息交互

上图中通道图示说明:

说明:

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

区块链保存到文件系统时,会在LevelDB 中存储区块交易对应的文件块及其偏移,也我你前会 将 LevelDB 作为账本数据库的索引。文件形式的区块存储最好的办法可能性没法快速定位的索引,没法查询区块交易信息会非常的慢。

ChaincodeMessage_GET_HISTORY_FOR_KEY

4)应用多线程 发送交易信息给排序(Orderer);

图:通道形态学 图

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

3)链码进行查询和更新,我你前会 返回提案信息给应用多线程 ;

接口模块如下:

       Kafka:是由Apache软件基金会开发的另二个 多开源流防止平台,并全部都是高吞吐量的分布式发布订阅消息系统,它还不能防止消费者规模的网站中的所有动作流数据,还不能配置多个排序节点集群最好的办法,以便使用在生成环境。Hyperledger Fabric利用kafka的高吞吐、低延时的形态学 ,对交易信息进行排序防止,实现在集群内部人员支持节点故障容错。

另二个 多链代表许多节点有点硬形成的另二个 多网络,启动另二个 多共识的通道,在通道中交易还不能被独立的防止。另二个 多网络可能性另二个 多多或多个链。链上的节点维护另二个 多单独的账本富含交易在链上挂接,包括成员关系的任何配置。所有的交易全部都是在链上发送,另二个 多应用可能性操作多个链。

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

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

6.3.2 智能合约(Smart contract)

S:Chaincode 链码

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

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

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

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

ProposalResponse

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

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

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

      4) 配置Kafka集群

2)   Package: Member Service

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

3

通道形态学 图:

ChaincodeMessage_INVOKE_CHAINCODE

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

ChaincodeMessage_GET_STATE_BY_RANGE

A:Application 应用多线程

6.3.3 通道(Channel)

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

       历史情况报告数据库用于查询某个 key 的历史修改记录,历史数据库真是存储 key 具体的值,而只记录在某个区块的某个交易里,某 key 变动了一次,后续需用查询的我你前会 ,根据变动历史去查询实际变动的值,真是减少了数据的存储,当然也增加了查询逻辑的复杂化度。

帐本形态学 图如下:

图:客户端与节点交互

L:Ledger 账本

上图中通道图示说明:

情况报告数据库是存储所有在交易中再次出现的键值对的最新值,调用链码执行交易还不能改变情况报告数据,为了高效的执行链码调用,所有数据的最新值都被存插进情况报告数据库中;情况报告数据库被设计为组件,还不能通过配置替换数据库,目前有LevelDB和CouchDB并全部都是数据库, LevelDB是默认的内置的数据库。

CryptoSuite