fabric交易流程

1 ClientA 发起交易，构建交易提案（tx proposal），并对提案进行签名

创建签名提案消息，发送给peer进行背书，获取ProposalResponse消息

2 背书节点进行验证并模拟执行交易

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

验证之后背书节点模拟执行交易，产生读写集合（read set,write set）加上签名信息构建成ProposalResponse。注意此时账本并没有进行更新

3 对ProposalResponse进行检查

验证背书节点的签名，保证ProposalResponse的正确性。
如果只是链码查询操作，并不会提交到orderer服务。如果需要更新账本，向orderer服务提交交易之前，应用会检测是否满足背书策略（endorsement policy）
The application verifies the endorsing peer signatures and compares the proposal responses to determine if the proposal responses are the same.
If the client application intends to submit the transaction to the ordering service to update the ledger

4 集成交易

将交易提案和提案响应集成为交易信息发送给orderer服务。
交易信息包括读写集，背书节点签名，chennel ID.
orderer服务从所有的channel中收取交易信息，并创建区块。
orderer收到信息之后不需要进行检查

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.

5 交易验证和提交

Transaction is validated and committed

将区块信息广播到channel中的所有peer,
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.

6 账本更新

peer将区块信息加入到链上，并将每一个有效交易的写集合提交到当前数据库状态。
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.