fabric 简易翻译：交易流程

交易流程

本文件概述了在标准资产交换过程中发生的交易机制。 该情景包括两个买卖萝卜的客户A和B。 他们每个人都有网络上的对等节点，通过它们发送他们的交易并与分布式账本进行交互。

前提

此流程假设一个通道已经设置好并运行。 应用程序用户已经在组织的认证中心（CA）注册并登记，并收到了用于向网络进行身份验证所必须的加密资料。

链码（包含表示萝卜市场初始状态的一组键值对）安装在对等体上并在通道上实例化。 链码包含定义一组交易指令和萝卜的商定价格的逻辑。 链码设置了一个背书策略，指定 peerA 和 peerB 都必须为任何交易背书。

1. 客户A初始化一笔交易

发生了什么？ - 客户A正在发送购买萝卜的请求。 该请求针对分别代表客户端A和客户端B的 peerA 和 peerB 。背书策略规定，对等节点必须为任何交易背书，因此该请求转发给 peerA 和 peerB .

接下来，构建交易提案。 利用受支持的SDK（Node，Java，Python）的应用程序利用可用的API之一生成交易提案。 该提案是一个调用链码功能的请求，以便数据可以被读取或写入账本（例如:为资产写入新的键值对）。 SDK作为中间层将交易提案打包成正确架构的格式（通过gRPC的协议缓冲区），并使用该用户的加密证书生成此交易提案的唯一签名。

2. 背书节点确认签名 并执行交易

背书节点需要验证（1）交易提案的构成是否正确，（2）以前是否提交过（回放攻击保护），（3）签名是否有效（使用MSP），（4） 提交者（示例中的客户端A）是否被正确地授权在通道上执行建议的操作（换句话说，每个背书节点要确保提交者满足通道的作者策略）。 背书节点将交易提案输入作为调用链码函数的参数。 然后针对当前状态数据库执行链码以产生包括响应值，读取集合和写入集合的交易结果。 此时不对账本进行任何更新。 这些值的集合以及背书节点的签名和一个YES 或者NO的背书状态作为一个“提案响应”被传回为了应用程序歇解析负载而消耗的SDK。

{MSP是一个对等节点的组件，允许他们验证从客户端发送来的事务请求和签署事务结果（背书）。 _写入策略在通道创建时定义，并确定哪个用户有权向该通道提交交易。} _

3. 检查提案响应

应用程序验证背书节点的签名，并比较提案响应（链接到将包含有效载荷表示的glossary），以确定提案响应是否相同，以及是否已经满足了指定的背书策略（即peerA和peerB 都背书）。 架构是这样的，即使应用程序选择不检查响应或以其他方式转发未背书的交易，该策略仍将由对等节点在提交验证阶段强制执行。

4. 客户端把背书信息加入到交易中

应用程序将包含交易提案和响应的一个“交易消息”“广播”到排序服务。 交易包含读/写集，背书节点的签名和通道ID。 排序服务在执行其操作时不需要检查一个交易的整个内容，它只是从网络中的所有通道接收交易，根据通道按时间顺序排列，并每个通道创建包含交易的区块。

5. 交易生效并提交

包含交易的区块被“分发”到通道上的所有对等节点。当确保背书策略得到满足，并确保自从交易执行生成了读取集以来，读取集变量对应的账本状态没有发生任何变化时， 意味着区块内的交易经过了验证。 区块中的交易可以被标记为有效或无效。

6. 更新账本

每个对等节点将区块添加到通道的区块链中，并且对于每个有效交易，写集合会被提交到当前状态数据库。 对等节点会发出一个事件，通知客户端应用程序，该交易（调用）已经永久地追加到区块链中，以及通知该交易是有效或者无效。

备注：请参阅泳道流程图可以更好的理解服务器端的流程和protobuffers。