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