說明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!

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！