HyperLedger Fabric 交易流程

在生產環境中，一個最小的Fabric聯盟鏈網絡由4個結點組成，如下圖：

為了避免單點故障，進行結構冗余，每個節點的角色安排如下：

· 192.168.1.120 peer1, orderer1, zookeeper0, kafka0, ca1，

· 192.168.1.121 peer2, orderer2, zookeeper1, kafka1 ca2

· 192.168.1.122 peer3, zookeeper2, kafka2 ,ca3

· 192.168.1.122 peer4, kafka3  ca4, fabric瀏覽器

在Fabric中，本由一個節點處理的過程，在邏輯上被分解為不同的角色，每個角色承擔不同的功能；節點（Peer）分解為背書節點（Endorser peer）和提交節點（Committer peer），為了達到處理的順序性，提煉出排序（Orderer）角色，kafka是聯盟鏈中負責共享機制，zookeeper是個分布式應用協調器，負責點到點數據傳輸，CA負責證書發放。 Fabric是應用于聯盟鏈的場景，在處理每一筆交易時，每個環節上需要對交易信息進行權限校驗。
       Fabric交易流程圖如下所示：

交易過程詳細流程：
     1) 應用程序客戶端通過SDK調用證書服務（CA）服務，進行注冊和登記，并獲取×××書；
     2) 應用程序客戶端通過SDK向區塊鏈網絡發起一個交易提案（Proposal），交易提案把帶有本次交易要調用的合約標識、合約方法和參數信息以及客戶端簽名等信息發送給背書（Endorser）節點。

     3) 背書（Endorser）節點收到交易提案（Proposal）后，驗證簽名并確定提交者是否有權執行操作，同時根據背書策略模擬執行智能合約，并將結果及其各自的CA證書簽名發還給應用程序客戶端。

     4) 應用程序客戶端收到背書（Endorser）節點返回的信息后，判斷提案結果是否一致，以及是否參照指定的背書策略執行，如果沒有足夠的背書，則中止處理；否則，應用程序客戶端把數據打包到一起組成一個交易并簽名，發送給Orderers。
     5) Orderers對接收到的交易進行共識排序，然后按照區塊生成策略，將一批交易打包到一起，生成新的區塊，發送給提交（Committer）節點；
     6) 提交（Committer）節點收到區塊后，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區塊鏈的狀態，完成后將區塊追加到本地的區塊鏈，并修改世界狀態。

還有一個關于Fabric聯盟鏈交易理解的說明：

這個示例中包含客戶A和B，在進行蘿卜買賣。他們各自有一個網絡節點，通過節點他們發送交易并和賬本進行交互。

首先，假設必要的條件：

該流程假設通道已建立并正常運行。用戶已注冊并使用組織認證授權（CA）登記，同時獲得必要的加密材料來進行網絡驗證。

鏈碼（包含一組代表蘿卜市場初始狀態的鍵值對）被安裝在節點上并在通道上進行實例化。鏈碼包含定義交易指令集合的邏輯和達成一致的蘿卜價格。設置一項針對鏈碼的背書策略，表明節點A和B都必須對任何交易進行背書。

1. 客戶A發起交易

客戶A發出蘿卜購買請求。請求目標節點A和B，分別代表客戶A和B。背書策略表明兩個節點必須為任何交易進行背書，因而請求被發送到節點A和B。

接下來構建交易提案。一個以可用SDK（node, java, python）為支撐的應用利用有效的API來生成交易提案。這項提案作為調用鏈碼功能的請求來完成數據到賬本的讀取和/或寫入（即為資產寫入新的鍵值對）。SDK有兩個作用：把交易提案包裝成合適架構格式的庫（基于gRPC的協議緩沖）；使用用戶的加密證書來創建交易提案的唯一簽名。

2. 背書節點驗證簽名&執行交易

背書節點使用MSP驗證簽名并確定請求者是否被合理授權進行提案的操作（使用通道ACL）。背書節點以交易提案憑證為輸入，基于當前狀態的數據庫執行來生成交易結果，輸出包括反饋值、讀取集合和寫入集合。截止現在賬本還未進行更新。這些值的集合，背書節點的簽名以及是/否的背書聲明一同作為“提案反饋”被傳輸回到SDK，SDK對應用消耗的載荷進行解析。

3. 審查提案反饋

應用對背書節點簽名進行驗證，比較提案反饋（鏈接到包含載荷代理的術語條款）來決定是否一致，指定的背書策略是否被執行（即節點A和B都進行了背書）。這種架構可以保證即使一個應用選擇不進行反饋審查或者轉發了沒有背書的交易，背書策略依然會被節點執行并在驗證提交階段維持。

4. 客戶組合交易背書

應用對交易提案進行廣播，以“交易信息”對訂購服務實現反饋。交易包含讀/寫集合，背書節點簽名和通道ID。訂購服務不讀取交易細節，只是從網絡中所有通道接收交易，根據每個通道按時間順序調用，創建每個通道的交易區塊。

5. 交易驗證和提交

交易區塊被發布到通道中的所有節點。區塊中的交易被驗證來確保背書策略被執行并且賬本的讀取集合變量沒有發生變化，因為讀取集合是執行交易生成的。區塊中的交易被標記為有效或無效。

6. 賬本更新

每個節點都把區塊追加到通道的鏈中，對每項有效交易，寫入集合被提交到當前狀態的數據庫。發出事務通知客戶端應用，交易（調用）被永久追加到鏈中以及交易是有效或者無效的。