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（链）中，并通知该事务是否被验证或无效。