《Fabric交易流程》Transaction Flow 非直译文

原文链接：https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

【这篇文章不用直译。】

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.

假设Channel已经设置好配置，并正在运行着。所有用户的Peer节点应用程序已经注册了并且取得了用于权限验证的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.

chaincode 链码会被安装到Peer节点上，并且在Channel上实例化（Channel实例建立在Orders形成的网络里的），链码包含了“交易指令”和“商品价格”。链码也“背书担保规则”，A和B的Peer节点会对满足“背书担保规则”的交易，进行担保。

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用App发起一笔购买萝卜的订单，这个订单请求会被发送给节点A和节点B。 倘若“背书担保规则”设定为对所有交易均可担保，那么这个请求将被Peer节点接受。

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.

下一步是构建 “交易提案”。 这个发起交易的App会借助 Fabric 客户端 SDK中的其中 API接口 生成一个 “交易提案”。这个提案的内容是 请求调用ChainCode链码去读取或者写入账本。 （一个shim是一个库,它将一个新的API引入到一个旧的环境中,而且仅靠旧环境中已有的手段实现）Fabric客户端的SDK（以Shim库的形式）序列化“交易提案”为一个 结构化的文本格式并利用客户端用户的加密凭证为该“交易提案”生成一个签名。

2. Endorsing peers verify signature & execute the transaction       Peer为担保的交易验证签名&执行交易

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.

担保的Peer节点需要验证的条款有：

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

（2）是否被提交过（防止重放攻击）

（3）签名是否有效（签名是否为CA颁发的）

（4）提交的客户端APP（客户A）是否被授权在该Channel执行 “发起交易”的操作指令。

担保的Peer节点会在调用ChainCode链码函数时将该“交易提案”作为参数传入。 链码会根据当前账本数据库的数据去处理交易结果，交易结果包含了：返回码、读取的数据集合、写入的数据集合（这个写入操作暂时不会对数据库执行）。 这个时候还不会将对账本进行更新。然后这些被ChainCode处理后的“交易结果”会带上Peer的签名一起返回给客户端的SDK程序，客户端的SDK程序会解析这些数据，提供给App做下一步处理。

{The MSP is a peer component that allows them 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 user is entitled to submit a transaction to that channel.}

{ MSP（由CA 针对每个Peer节点进行颁发） 是一个Peer的组件，有了它才可以被允许对来自客户端的交易进行验证，以及对ChainCode处理后的交易结果进行签名。The Writing policy“写入规则” 在通道创建的时候被定义，他声明了哪些客户端用户有权利发起“交易提案”给哪些“Channel通道”。}

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.

这个应用程序会去验证担保的Peer节点的签名是否正确，并比较 proposal responses“提案响应” 是否一样。如果Chaincode 只是查询账本，那么客户端的APP只会检查proposal responses“提案响应”的正确性，而不再提交 “交易”给 Ordering Service。 如果客户端的APP尝试提交“交易”给Ordering Service 更新账单，在提交之前需要确保所有Peer的担保签名都收集齐全（如，本例中需要收集Peer A节点和Peer B节点的 proposal responses 中 签名）。同时在这个体系结构中规定了，如果客户端App选择不检查proposal responses“提案响应”的正确性，或者转发一个未被担保的交易，这个“担保规则”依然会使这个交易在“提交验证阶段” 被交由 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.

应用程序广播 “交易信息”给Ordering Service，里面包含了transaction proposal “交易提案”和 proposal responses“提案响应” 。 这个“交易信息”包括了 “账本的读写操作数据集合”（其实就是一堆指令集），以及担保节点Peer的签名信息，和Channel ID。Ordering Service不需要为了执行操作时而去再检查“交易信息”的内容，他只是简单的从Channel网络中接受信息就可以了。 每条通道的交易记录都会按照时间排序，并且按照不同Channel通道 将“交易记录”打包成区块。

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节点。这些区块的交易会被验证,以确保交易已经获得了所有Peer节点的担保背书，并且交易记录中读集合的数据和上一次读取账本时一样未被篡改过。被验证通过的记录会被标记为 valid 已验证，未通过的验证的交易记录会被标记为 invalid 未验证。

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节点都会把区块追加到对应Channel通道的链上，对于每一个被标记为通过验证的交易的“写数据集合”会被提交给数据库。同时，会触发一个事件，去通知客户端App他提交的交易已经被写入区块链（并不可再修改），如果交易无效也会同样的通知客户端App。

Note: See the swimlane diagram to better understand the server side flow and the protobuffers.