Transaction Flow/交易流程
This document outlines the transactional mechanics that take place during a standard asset exchange. The scenario includes two clients, A and B, who are buying and selling radishes. They each have a peer on the network through which they send their transactions and interact with the ledger.
本文档概述了标准资产交换过程中发生的交易机制。 该方案包括两个客户，A和B，他们正在买卖萝卜。 他们每个人在网络上都有一个peer，通过他们发送交易并与总账进行交互。
Assumptions/假设
This flow assumes that a channel is set up and running. The application user has registered and enrolled with the organization’s certificate authority (CA) and received back necessary cryptographic material, which is used to authenticate to the network.
此流程假定已建立并运行一个管道。 应用程序用户已注册并注册了组织的证书颁发机构（CA），并收到了必要的加密材料，该材料用于向网络进行身份验证。
The chaincode (containing a set of key value pairs representing the initial state of the radish market) is installed on the peers and instantiated on the channel. The chaincode contains logic defining a set of transaction instructions and the agreed upon price for a radish. An endorsement policy has also been set for this chaincode, stating that both peerA and peerB must endorse any transaction.
链码（包含表示萝卜市场初始状态的一组键值对）安装在peers上并在管道上实例化。 链码包含定义一组交易指令的逻辑和萝卜的商定价格。 还为此链码设置了一个认可政策，声明peerA和peerB都必须认可任何交易。
1.Client A initiates a transaction/客户A启动交易
What’s happening? - Client A is sending a request to purchase radishes. The request targets peerA and peerB, who are respectively representative of Client A and Client B. The endorsement policy states that both peers must endorse any transaction, therefore the request goes to peerA and peerB.
发生了什么？ - 客户A正在发送购买萝卜的请求。 该请求的目标是peerA和peerB，它们分别代表客户端A和客户端B.背书(endorsement)策略规定两个peers端必须支持任何交易，因此请求将转发给peerA和peerB。
Next, the transaction proposal is constructed. An application leveraging a supported SDK (Node, Java, Python) utilizes one of the available API’s which generates a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read and/or written to the ledger (i.e. write new key value pairs for the assets). The SDK serves as a shim to package the transaction proposal into the properly architected format (protocol buffer over gRPC) and takes the user’s cryptographic credentials to produce a unique signature for this transaction proposal.
接下来，构建交易提议。 利用受支持的SDK（Node，Java，Python）的应用程序利用一个可用的API来生成交易提议。 该提议是调用链码功能的请求，以便可以将数据读取和/或写入总账（即为资产写入新的键值对）。 SDK用作填充程序，将交易提议打包为正确的架构格式（gRPC上的协议缓冲区），并使用用户的加密凭据为此交易提议生成唯一签名。
2.Endorsing peers verify signature & execute the transaction /背书(endorsing) peers 验证签名 & 执行交易
The endorsing peers verify (1) that the transaction proposal is well formed, (2) it has not been submitted already in the past (replay-attack protection), (3) the signature is valid (using MSP), and (4) that the submitter (Client A, in the example) is properly authorized to perform the proposed operation on that channel (namely, each endorsing peer ensures that the submitter satisfies the channel’s Writers policy). The endorsing peers take the transaction proposal inputs as arguments to the invoked chaincode’s function. The chaincode is then executed against the current state database to produce transaction results including a response value, read set, and write set. No updates are made to the ledger at this point. The set of these values, along with the endorsing peer’s signature is passed back as a “proposal response” to the SDK which parses the payload for the application to consume.
背书(endorsing) peers验证（1）交易提议格式正确，（2）过去未提交过（重放攻击保护），（3）签名有效（使用MSP），以及（4） 提交者（在示例中为客户端A）被正确授权在该管道上执行提议的操作（即，每个背书(endorsing) peer确保提交者满足管道的写入策略）。 背书(endorsing) peer将交易提议输入作为调用的链码函数的参数。 然后针对当前状态数据库执行链码以产生包括响应值，读取集和写集的交易结果。 此时没有对总账进行更新。 这些值的集合以及背书(endorsing) peer的签名将作为“提议响应”传递回SDK，该SDK解析应用程序要使用的有效负载。
Note/注意
The MSP is a peer component that allows peers to verify transaction requests arriving from clients and to sign transaction results (endorsements). The writing policy is defined at channel creation time and determines which users are entitled to submit a transaction to that channel.
MSP是一个peer组件，允许peer验证从客户端到达的交易请求并签署交易结果（认可）。 写入策略在管道创建时定义，并确定哪些用户有权向该管道提交交易。
3.Proposal responses are inspected /检查提议响应
The application verifies the endorsing peer signatures and compares the proposal responses to determine if the proposal responses are the same. If the chaincode only queried the ledger, the application would inspect the query response and would typically not submit the transaction to Ordering Service. If the client application intends to submit the transaction to Ordering Service to update the ledger, the application determines if the specified endorsement policy has been fulfilled before submitting (i.e. did peerA and peerB both endorse). The architecture is such that even if an application chooses not to inspect responses or otherwise forwards an unendorsed transaction, the endorsement policy will still be enforced by peers and upheld at the commit validation phase.
应用程序验证背书(endorsing) peer签名并比较提议响应以确定提议响应是否相同。 如果链码仅查询总账，则应用程序将检查查询响应，并且通常不会将交易提交给Ordering 服务。 如果客户端应用程序打算将交易提交给Ordering 服务以更新总账，则应用程序在提交之前确定是否已满足指定的背书(endorsement)策略（即，peerA和peerB都认可）。 该体系结构使得即使应用程序选择不检查响应或以其他方式转发未经许可的交易，该背书(endorsement)策略仍将由peers强制执行并在提交验证阶段维持。
4.Client assembles endorsements into a transaction /客户将认可集中到交易中
The application “broadcasts” the transaction proposal and response within a “transaction message” to the Ordering Service. The transaction will contain the read/write sets, the endorsing peers signatures and the Channel ID. The Ordering Service does not need to inspect the entire content of a transaction in order to perform its operation, it simply receives transactions from all channels in the network, orders them chronologically by channel, and creates blocks of transactions per channel.
该应用程序将交易提议和交易消息中的响应“广播”到Ordering 服务。 该交易将包含读/写集，背书(endorsing) peers签名和管道ID。 Ordering服务不需要检查交易的整个内容以执行其操作，它只是从网络中的所有管道中接收交易，按时间顺序按管道对它们进行排序，并创建每个管道的交易块。
5.Transaction is validated and committed /交易已经过验证和提交
The blocks of transactions are “delivered” to all peers on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid.
交易块被“交付”到管道上的所有peers。 验证块内的交易以确保满足背书(endorsement)策略并确保自交易执行产生读集以来，读集变量的总账状态没有变化。 块中的事务被标记为有效或无效。
6.Ledger updated /总账更新
Each peer appends the block to the channel’s chain, and for each valid transaction the write sets are committed to current state database. An event is emitted, to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as notification of whether the transaction was validated or invalidated.
每个peer将块附加到管道的链，并且对于每个有效的交易，写集被提交到当前状态数据库。 发出一个事件，通知客户端应用程序交易（调用）已被不可变地附加到链中，以及通知该交易是否已经过验证或无效。