Hyperledger Fabric架構 — 交易流程
本文會概述資產交換期間發生的交易機制。 這個場景有A 和 B兩方，他們正在買賣貨品。 他們每個人在Fabric網路上都有自己的一個對等節點，透過自己的對等節點發送交易並與把資料寫入帳本。
交易
交易流程假定渠道已設置並正在運行。 應用程式用戶已在組織的CA註冊和登記身分，並收到了用於在網路要進行身份驗證的必要加密物件。
Chaincode（包含一組代表貨品市場初始狀態的key-value pair）安裝在對等節點上並部署到渠道。 Chaincode包含定義一組交易指令和商定好的貨品價格的邏輯。 還為這個chaincode設置了背書政策，規定 peerA 和 peerB 都必須背書任何交易。
第一步: Client A發起交易
如上圖，Client A 正在發送購買貨品的請求。這個請求針對分別代表Client A 和Client B 的 peerA 和 peerB。背書政策規定兩個對等節點必須對任何交易進行背書，因此交易請求將發送到 peerA 和 peerB。
接下來，建立交易提案(transaction proposal)。利用有使用 SDK的應用程式（Node、Java、Go）發出API call來產生交易提案。該提案是請求使用某些輸入參數來呼叫chaincode函數，目的是讀取和(或)更新帳本。
SDK 充當 shim 將交易提案打包成適當架構的格式（gRPC 上的protocol buffer），並採用使用者的加密憑證為該交易提案產生唯一的簽名。 SDK 將交易提議提交給目標對等節點，目標對等節點將代表client管理交易提交(transaction submission)。根據背書政策的要求，目標對等節點首先將交易提案轉發給其他對等節點執行。
第二步:背書節點確認簽名並執行交易
背書節點會驗證
- 交易提案格式正確
- 過去沒有提交過（replay-attack protection）
- 簽名有效（使用 MSP驗證）
- 提交者（在此例中為Client A）被正確授權在該渠道上執行建議的操（意即每個背書節點確保提交者滿足渠道的資料寫入政策）
背書節點將交易提案輸入作為被呼叫chaincode函數的參數。 然後針對當前狀態資料庫執行chaincode以產生交易結果，包括回應值、read set和write set（意即表示要建立或更新的資產的key/value pair）。 此時不會對帳本進行更新。 這些值的集合以及背書節點的簽名作為“交易提案的回應”傳回給目標對等節點。
所謂的MSP 是一個 對等節點組件，它允許對等節點驗證來自client的交易請求並簽署交易結果（背書）。 寫入政策在渠道創建時定義，並確定哪些使用者有權向該渠道提交交易。
第三步:檢驗交易的回應
目標對等節點在繼續提交交易之前驗證交易提案的回應是否跟之前提交的內容相同。 該架構使得即使在沒有這個檢查動作的情況下提交交易，當每個對等節點在提交交易之前驗證交易時，仍將檢查並執行背書政策。
第四步:目標節點將背書匯入交易中
目標對等節點將交易提議和回應放入“交易訊息”中“廣播”到排序服務。 交易包含渠道 ID、read/write set和來自每個背書節點的簽名。 排序服務不需要檢查交易的全部內容，它只需接收交易，對它們進行排序，並為每個渠道創建交易區塊。
第五步:交易被驗證(Validated)並提交(Committed)
交易區塊被“交付”給渠道上的所有對等節點。 驗證區塊內的交易以確保背書政策得到滿足，並確保read set variables的帳本狀態沒有更改，因為read set是由交易執行產生的。 區塊中的交易會根據read set variable的帳本狀態被標記為有效或無效。
第六步:帳本更新
每個對等節點都將區塊附加到渠道的鏈上，並且對於每個有效交易，write set都會把它提交(committed)到當前狀態資料庫。 每個對等節點都會發出一個事件(event)來通知Client Application這筆交易附加到鏈上並且是不可更改的，以及交易是否被驗證或無效的通知。
我們的應用程式應該在提交交易後監聽交易事件，例如使用 submitTransaction API，它會自動監聽交易事件。 如果不監聽交易事件，我們將不會知道交易是否實際上已被排序、驗證並提交給帳本。
總結:視覺化上述流程
下圖為以上所說的步驟流程視覺化圖像
