Hyperledger Fabric Transaction Flow——事務處理流程

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