交易流程

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.

本文档概述了标准资产交换过程中发生的交易机制。

该场景包括买卖萝卜的两个客户(client)A和B。

他们每个人在网络上都有一个对等节点（peer)，通过它们发送交易(transaction)并与账本（ledger)进行交互。

0. 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.

该流程假定已建立并运行通道(channel)。

应用程序（application）用户已经在组织的证书颁发机构（CA）中登记并注册，并收到了后面必要的加密材料，用于对网络进行身份验证。

The chaincode (containing a set of key value pairs representing the initial state of the radish market) is installed on the peers and deployed to 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.

链码（chaincode)（包含代表萝卜市场初始状态的一组键值对(key value pairs）)被安装在对等节点上并部署到通道中。（因为一个节点可能参与了多个通道）

链码包含逻辑，该逻辑定义了一组交易指令和萝卜的议定价格。

还为此链代码设置了一项背书政策（endorsement policy），指出PeerA和PeerB都必须背书任何交易。

1. Client A initiates a transaction

客户A发起交易

What’s happening? Client A is sending a request to purchase radishes. This 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正在发送购买萝卜的请求（request)。此请求针对分别代表客户端A和客户端B的对等节点A和对等节点B。

背书策略规定，两个对等方都必须背书任何交易，因此该请求将发送给对等方A和对等方B。

（根据背书策略决定将请求发给谁）

Next, the transaction proposal is constructed. An application leveraging a supported SDK (Node, Java, Python) utilizes one of the available API’s to generate a transaction proposal. The proposal is a request to invoke a chaincode function with certain input parameters, with the intent of reading and/or updating the ledger.

接下来，构造交易提案（transaction proposal)。

利用受支持的SDK（Node，Java，Python）的应用程序利用一个可用的API来生成一个交易提案。

该提案是一个为了读取和/或更新分类帐而调用（invoke)具有某些输入参数(input parameters)的链码功能的请求。

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充当填充程序，将交易提案打包为正确设计的格式（基于gRPC的协议缓冲区），并使用用户的加密凭据为该交易提案生成唯一的签名（signature）。

2. Endorsing peers verify signature & execute the transaction

背书节点验证签名并执行交易

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 the 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).

背书节点验证

（1）交易提案的格式是否正确；

（2）它过去尚未提交过（重放***保护）；

（3）签名有效（使用MSP）；

（4 ）提交者（在示例中为客户A）被正确地授权在该通道上执行建议的操作（即，每个背书节点都确保提交者满足该通道的“写者”策略）。

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 (i.e. key/value pairs representing an asset to create or update). 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.

背书节点将交易提案的输入作为所调用链码函数的参数。

然后基于当前状态数据库（state database)执行链码以产生包括响应值(response value)，读取集(read set)和写入集(write set)（即代表要创建或更新的资产的键/值对）的交易结果。

此时，不会对分类帐进行任何更新。

这些值的集合以及背书节点的签名作为“提案响应（proposal response）”传递回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. For more information about membership, check out our Membership Service Provider (MSP) documentation.

MSP是对等组件，允许对等节点验证来自客户端的交易请求并签署交易结果（背书）。

写入策略是在通道创建时定义的，并确定哪些用户有权向该通道提交交易。

有关成员资格的更多信息，请查看我们的成员服务提供商（MSP）文档。

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 is only querying the ledger, the application would only inspect the query response and would typically not submit the transaction to the ordering service. If the client application intends to submit the transaction to the 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).

该应用程序验证背书的对等节点签名，并比较提案响应以确定提案响应是否相同。

如果链码仅用于查询分类帐，则应用程序将仅检查查询响应，并且通常不会将交易提交给排序服务（ordering service)。

如果客户端应用程序打算将交易提交给排序服务以更新分类帐，则应用程序将确定提交之前是否已满足指定的背书策略（即peerA和peerB都背书了）。

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.

该体系结构使得即使一个应用程序选择不检查响应或以其他方式转发未认可的交易，背书策略仍将由对等节点强制执行，并在提交验证阶段（commit validation phase）予以保留。

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.

该应用程序在一个“交易消息（transaction message）”中将交易提案和响应“广播（broadcast）”到排序服务。

该交易将包含读/写集，背书节点的签名和通道ID(Channel ID)。

排序服务不需要检查交易的全部内容以执行它的操作，它只需从网络中的所有通道接收交易，按通道按时间顺序对它们进行排序，并在每个渠道中创建独立的交易区块。

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.

交易区块（block）被“交付（delivere）”给通道上的所有对等节点。

验证区块中的交易以确保背书策略已经被满足，并确保自读集是由交易执行生成的以来，读集变量的分类帐状态没有发生变化。

区块中的交易被标记为有效或无效。

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 by each peer 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.

每个对等节点都会将该区块附加到对应通道的自己的链中，并且对于每个有效交易，写集都将提交到当前状态数据库。

每个对等节点都会发出一个事件，以通知客户端应用程序，这个交易（调用）已被不可变地附加到链中，并通知每个交易是有效的还是无效。

Note

Applications should listen for the transaction event after submitting a transaction, for example by using the submitTransaction API, which automatically listen for transaction events. Without listening for transaction events, you will not know whether your transaction has actually been ordered, validated, and committed to the ledger.

应用程序应在提交交易后监听交易事件，例如使用submitTransaction API，该API自动监听交易事件。

如果不监听事务事件，您将不会知道您的事务是否实际上已被排序，验证并提交到分类账。

You can also use the swimlane sequence diagram below to examine the transaction flow in more detail.

您还可以使用下面的泳道顺序图更详细地检查事务流。

https://hyperledger-fabric.readthedocs.io/en/release-2.3/txflow.html