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（鏈）中，並通知該事務是否被驗證或無效。