区块链超级账本的典型交易流程

说明1：本文翻译自hyperledger/fabric项目官方文档的Flow章节。为了学术严禁（为了渣翻译蒙混过关）贴了中原文对照。（原文地址：http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html#transaction-flow）

说明2：灵魂翻译，只可意会不可言传。如果发现部分翻译并不能和原文一一对应，请发挥想象。

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.

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.

本流程假定通道已经设置启动并正常运行，应用的用户也已经成功从组织CA哪里注册并登记了自己的身份，同时收到了从CA返回的用于接入区块链网络进行认证的相关密钥要素。

智能合约代码已经在各相关peer节点上安装并在通道内实例化（智能合约内包含有模拟初始的萝卜市场的key-value集合）。智能合约里是一系列交易指令的逻辑定义和约定好萝卜价格。一个声明任何交易都必须被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客户正在发送一个购买萝卜的请求，这个请求的目标是分别代表A客户和B客户的 peerA 节点和 peerB 节点。由于智能合约上的背书策略声明了任何交易都必须被 peerA 和 peerB 背书才行，所以请求被发到了 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（sdk有Nodejs，Java，Python等多种）中适用的API来构建交易提案。交易提案是一个用来调用智能合约中的方法的请求，只有通过调用智能合约才能对账本进行读写（比如将一个新的代表资产的键值对数据写入到账本中）。SDK的作用就是将这个交易提案打包成合适的数据结构（根据gRPC协议定义的proto buffer结构），并使用用户的加密凭证对这个交易提案产生一个唯一的数字签名。

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

背书节点需要检查交易提案的格式是否正确，检查这个提案以前是否被提交过（防止重放攻击），检查提案的签名是否合法，以及提案的提交者（本案例中的A客户）在这个通道内是否拥有操作提案的权限（既每个背书的节点需要确保提案提交者满足通道的写策略）。背书节点将提案的输入集合作为调用智能合约方法的参数。只能和与基于当前的状态库去执行交易并产生一个包含返回值的交易结果、读集以及写集。在这个时候，并不会对账本进行更新。这些数据在加上背书节点的数字签名被作为一个提案回复返回给SDK，SDK将结果解析并返给应用处理。

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.

应用端首先验证背书节点的数字签名，然后比对各个提案返回来验证他们是否一致。如果交易中智能合约仅仅只是对账本进行了查询，那么应用端一般只是检查下查询结果，然后并不会将交易结果发送给排序服务。如果应用端想想要将交易提交给排序服务从而对账本进行更新，那么在提交前需要确保交易结果完全满足了背书策略（本例中，需要 peerA 和 peerB 同时背书）。在超级账本的架构中，即使一个应用端选择不去检查提案返回结果，或者不对交易进行背书，peer节点依然会强制执行背书策略，并在账本提交验证阶段保持背书策略。

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.

应用端将交易提案和回复通过一个“交易信息”“广播”（译者注：这里指orderer service的broadcast接口）给排序服务。一个交易信息中包含交易的读写集、各背书节点的数字签名和通道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.

交易区块会被推送到通道内的所有peer节点上。区块中的交易会被验证，确保背书策略都被满足，确保交易执行时的读集在提交时并没有变化。区块中的交易根据验证结果被标记上有效或者无效。

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节点将新区块追加到对应通道的区块链上，每一个合法交易的写集会被提交到当前的状态库中。同时发出一个事件，通知客户端应用交易已经被不可更改的写入区块链中了以及这个交易是否合法。

上面的翻译可能有点啰嗦，这里有另一张官方文档的图，比较清晰的说明了整个过程。

一个典型的交易过程，一般有5个过程。如果是做不用更改账本的查询动作，只需要其中前3个就OK了。

连接peer节点

通过组织CA签发的用户证书，客户端可以连接上peer节点，用于发送交易或者建立事件监听。

发送交易提案

客户端组织交易提案，发送给背书的peer节点去做背书；

背书节点完成身份校验后，或调用节点上的智能合约（chaincode），执行相应的合约方法；

背书节点返回执行结果给客户端；

收集提案结果

如果是查询动作，客户端收到返回结果整个交易过程就接收了；

如果是更新动作，则客户端需要对返回结果进行处理，比如比对各结果是否一致，收集的背书信息是否满足背书策略等。

发起排序请求

客户端将收集到的背书及交易信息发送给orderer服务进行排序（既所谓的共识）；

orderer服务会将交易信息根据严格规则进行打包，生成区块（block）；

orderer会将新区块推送给相关通道内的peer节点；

等到账本更新

peer节点收到新区块后，对区块进行验证，然后将区块追加到账本中（既将区块追加到区块链上）；

同时有效交易会根据读写集对状态库进行更新。

That's All!