Hyperledger Fabric Transaction Flow——事务处理流程

Transaction Flow

本文概述了在标准资产交换过程中发生的事务机制。这个场景包括两个客户,A和B,他们在购买和销售萝卜(产品)。他们每个人在网络上都有一个peer,通过这个网络,他们发送自己的交易,并与Ledger(账本总账)进行交互。

假设,这个flow有一个channel被设置并运行。应用程序客户端已经注册并注册了该组织的证书颁发机构(CA),并获得了必要的加密材料,用于对网络进行身份验证。

 

chaincode(包含一组表示萝卜市场的初始状态的键值对)被安装在peers上,并在channel上实例化。chaincode包含定义一组事务指令的逻辑,以及一个萝卜商定的价格。该chaincode也已确定了一个背书策略,即peerA和peerB都必须支持任何交易。

1.客户端A发起事务

事务的发生过程——客户A正在发送一个请求来购买萝卜。该请求的目标是peerA和peerB,它们分别代表客户A和客户B。背书策略规定,双方都必须认可任何交易,因此请求将被发送到peerA和peerB。

接下来,将构造事务协议。使用任何一个被HyperLedger Fabric支持的SDK(node、Java、Python)的应用程序创建一个可用的API来生成一个事务协议。协议是请求调用chaincode函数,以便可以读取和/或写入数据(例如,为资产编写新的键值对)。SDK作为一个shim来将事务协议打包成适当的格式(在gRPC上的协议缓冲区),并使用用户的加密凭证来为这个事务协议生成一个惟一的签名。

2.背书peers验证签名并执行事务

背书peers验证内容:(1)事务的协议是完整的,(2)在过去尚未被提交过(再现攻击保护),(3)签名是有效的(使用MSP),(4)提交者(客户端,在这个例子中)是正确授权执行该操作在channel中(也就是说,每个背书peers都确保提交者满足channel的写入策略)。

MSP是peer的一个组件,允许它们验证从客户端到达的事务请求,并签署事务结果(背书)。编写策略是在channel创建时定义的,并确定哪个用户有权向该channel提交事务。

3.检查返回协议

应用程序验证背书peer的签名,并对提案响应进行比较,以确定提案的响应是否相同。如果chaincode只是查询了账本,应用程序将检查查询响应结果,并且通常不会将查询事务提交给orderer。如果客户端应用程序打算将事务提交到orderer来更新账本,则应用程序将确定在提交之前指定的背书策略是否已经完成(例如,peerA和peerB都支持)。体系结构是这样的,即使应用程序选择不检查请求响应或转发未签署的事务,背书策略仍将由peers执行,并支持在提交阶段验证。

4.客户端将背书合并到交易中

应用程序将transaction proposal(事务协议)和包含该“transaction message(事务消息)”的peer请求响应“广播”给orderer服务,该事务将包含peer请求返回的读写集、背书peers的签名以及channel ID。orderer执行其操作无需检查该事务的全部内容,它只是从网络上的所有channels中接收事务,对相同channel中的事务按时间排序,并为每一个channel中的一个或一列事务创建区块。

5.提交并验证事务

由事务集创建的区块将会被分发到channel上所有的peers中,在该区块中的事务集将被验证以确保满足背书策略,并确保在事务执行生成读取集之后,对读集变量的账本没有任何更改。区块中的事务集因此会被标记为有效或无效。

7.账本更新

每一个channel都会将生成的区块追加到所属的chain(链)上,对于每个有效事务,都会将事务中的写集提交到当前状态数据库中。因前述而发出一个事件,通知客户端应用程序,事务(调用)已被追加到该chain(链)中,并通知该事务是否被验证或无效。

posted @ 2018-01-30 10:05 Aberic 阅读(...) 评论(...) 编辑 收藏