Transaction Flow
本文概述了在標準資產交換過程中發生的事務機制。這個場景包括兩個客戶，A和B，他們在購買和銷售蘿蔔（產品）。他們每個人在網路上都有一個peer，透過這個網路，他們傳送自己的交易，並與Ledger（賬本總賬）進行互動。
假設，這個flow有一個channel被設定並執行。應用程式客戶端已經註冊並註冊了該組織的證書頒發機構（CA），並獲得了必要的加密材料，用於對網路進行身份驗證。
chaincode（包含一組表示蘿蔔市場的初始狀態的鍵值對）被安裝在peers上，並在channel上例項化。chaincode包含定義一組事務指令的邏輯，以及一個蘿蔔商定的價格。該chaincode也已確定了一個背書策略，即peerA和peerB都必須支援任何交易。
1.客戶端A發起事務
事務的發生過程——客戶A正在傳送一個請求來購買蘿蔔。該請求的目標是peerA和peerB，它們分別代表客戶A和客戶B。背書策略規定，雙方都必須認可任何交易，因此請求將被髮送到peerA和peerB。
接下來，將構造事務協議。使用任何一個被HyperLedger Fabric支援的SDK（node、Java、Python）的應用程式建立一個可用的API來生成一個事務協議。協議是請求呼叫chaincode函式，以便可以讀取和/或寫入資料（例如，為資產編寫新的鍵值對）。SDK作為一個shim來將事務協議打包成適當的格式（在gRPC上的協議緩衝區），並使用使用者的加密憑證來為這個事務協議生成一個惟一的簽名。
2.背書peers驗證簽名並執行事務
背書peers驗證內容：（1）事務的協議是完整的，（2）在過去尚未被提交過（再現攻擊保護），（3）簽名是有效的（使用MSP），（4）提交者（客戶端，在這個例子中）是正確授權執行該操作在channel中（也就是說，每個背書peers都確保提交者滿足channel的寫入策略）。
｛MSP是peer的一個元件，允許它們驗證從客戶端到達的事務請求，並簽署事務結果（背書）。編寫策略是在channel建立時定義的，並確定哪個使用者有權向該channel提交事務。｝
3.檢查返回協議
應用程式驗證背書peer的簽名，並對提案響應進行比較，以確定提案的響應是否相同。如果chaincode只是查詢了賬本，應用程式將檢查查詢響應結果，並且通常不會將查詢事務提交給orderer。如果客戶端應用程式打算將事務提交到orderer來更新賬本，則應用程式將確定在提交之前指定的背書策略是否已經完成（例如，peerA和peerB都支援）。體系結構是這樣的，即使應用程式選擇不檢查請求響應或轉發未簽署的事務，背書策略仍將由peers執行，並支援在提交階段驗證。
4.客戶端將背書合併到交易中
應用程式將transaction proposal（事務協議）和包含該“transaction message（事務訊息）”的peer請求響應“廣播”給orderer服務，該事務將包含peer請求返回的讀寫集、背書peers的簽名以及channel ID。orderer執行其操作無需檢查該事務的全部內容，它只是從網路上的所有channels中接收事務，對相同channel中的事務按時間排序，併為每一個channel中的一個或一列事務建立區塊。
5.提交併驗證事務
由事務集建立的區塊將會被分發到channel上所有的peers中，在該區塊中的事務集將被驗證以確保滿足背書策略，並確保在事務執行生成讀取集之後，對讀集變數的賬本沒有任何更改。區塊中的事務集因此會被標記為有效或無效。
7.賬本更新
每一個channel都會將生成的區塊追加到所屬的chain（鏈）上，對於每個有效事務，都會將事務中的寫集提交到當前狀態資料庫中。因前述而發出一個事件，通知客戶端應用程式，事務（呼叫）已被追加到該chain（鏈）中，並通知該事務是否被驗證或無效。
