2、Hyperledger Fabric 交易流程

Transaction Flow

本文件概述了在标准资产交换期间发生的交易机制。该方案包括两个clientA和B，他们购买和销售萝卜。他们分别在网络上有一个peer，通过peer发送他们的交易并与账本交互。

假设
此流程假定通道已设置并运行。应用程序用户registe并向组织的证书颁发机构（CA）enroll，并收回了必要的加密材料，用于向网络进行身份验证。

Chaincode（包含表示萝卜市场初始状态的一组键值对）被安装在peer上并在channel上实例化。Chaincode包含了定义一组交易指令和商定的萝卜价格的逻辑。Endorsement策略也被定为chaincode，指出peerA和对等体peerB必须支持任何交易。

1. Client A 初始化一个交易

发生了什么？ - 客户端A发送购买萝卜的请求。请求目标peerA和peerB谁分别代表clientA和clientB。Endorsement策略规定两个peer必须签署任何交易，因此请求转到peerA和peerB。

接下来，构建交易proposal。利用支持SDK（node，java，python）的应用程序使用可用的API之一来生成交易建议。该proposal是调用chaincode函数的请求，以便可以将数据读取和/或写入账本（即为资产写入新的键值对）。SDK用作中间件（shim），将交易proposal打包为适当的架构的格式（通过gRPC的协议缓冲区），并采用用户的加密凭证为该交易建议生成唯一的签名。

2. Endorsing peers验证签名并执行交易

Endorser验证1）交易proposal正确的组织，2）交易在之前并没有被提交(重访攻击保护)，3）签名的合法性(使用MSP)，4）提交者（示例中的客户端A）被正确地授权在该channel上执行建议的操作（即，每个endorser确保提交者满足channel的Writer策略）。Endorser将交易proposal作为输入invoked的chaincode的函数的参数，并针对当前状态数据库执行它们以产生包括响应值，读集和写集的交易结果。此时不会更新账本。这些值的集合，以及支持peer的签名和YES / NO认可语句作为“建议响应”传递回SDK，该SDK解析用于应用消费的有效载荷。

{MSP是在peer上运行的本地进程，它允许它们验证从客户端到达的交易请求并签署交易结果（endorsement）。ACL（访问控制列表）在信道创建时定义，并确定允许哪些对等端和最终用户执行某些操作。}

3. Proposal回应被检查

应用程序验证endorser签名并且比较proposal的响应（链接到包含有效载荷的表示的词汇表术语）以确定proposal响应是否相同以及是否已经满足指定的endorsement策略（即，是否peerA和peerB两者都endorse）。该架构使得即使应用程序选择不检查响应或以其它方式转发未endorsed的交易，该策略仍然将由peer实施并且在提交验证阶段被维护。

4. Client将endorsement装配到交易中

应用程序将“交易消息”中的交易proposal和响应“广播”到排序服务。交易将包含读/写集合，被承认的peer签名和channel ID。Ordering服务不会读取交易详细信息，它只是从网络中的所有渠道接收交易，根据channel安时间顺序对其进行排序，并为每个渠道创建交易块。

5. 交易被验证并提交

交易块被“传递”到信道上的所有peer。块内的交易被验证以确保endorsement策略被满足并且确保账本的read集变量状态没有改变，因为read集是由交易执行生成的。块中的交易标记为有效或无效。

6. 账本更新

每个peer将块附加到channel的链，并且对于每个有效交易，write集被提交到当前状态数据库。发出事件以通知客户端应用程序交易（调用）已被不可变地附加到链，以及通知交易是否被验证或无效。