目標
- Hyperledger Fabric 網絡中的節點分類
- 熟知 Hyperledger Fabric 交易流程
任務實現
現在我們深入 Hyperledger Fabric 內部，詳細了解 Hyperledger Fabric 的交易實現流程，理解相應的核心內容。
區塊鏈技術最重要特征之一就是能夠保證實現安全的交易。Hyperledger Fabric 與公有鏈的交易實現又有很大的區別。如：權限、認證、數據隔離等等。
Hyperledger Fabric 典型的交易流程如下圖所示：
完整的交易流程解釋如下：
step1：
-
應用程序使用相應的 SDK（Node，Java，Python）提供的 API 構建交易提案並提交給相應的背書節點，交易提案中包含：
- channelID：通道信息
- chaincodeID：要調用的鏈碼信息
- timestamp：時間戳
- sign：客戶端的簽名
- txPayload：提交的事務本身包含的內容，包含兩項：
- operation：要調用的鏈碼的函數及相應的參數
- metadata：調用的相關屬性
交易提案（Proposal）消息結構如下
step2：
背書節點對接收到的交易提案請求進行驗證：
- 交易提案格式是否正確
- 交易在之前並未提交過（重復性攻擊保護）
- 提交交易提案的客戶端簽名是否有效（使用MSP）
- 提交交易提案的請求者是否在該通道中有相應的執行權限
驗證通過后調用鏈碼進行模擬執行， 產生包括響應值、讀集和寫集的事務結果。對結果進行背書並響應給客戶端。
注意，此時的調用鏈碼是模擬執行，不會對賬本中的數據進行真正意義上的更改。
交易提案響應（ProposalResponse）消息結構如下：
step3：
應用程序收集到足夠的消息和背書簽名之后，構建合法的交易請求並將交易請求廣播給 Ordering服務節點。
如果應用程序的請求僅僅是查詢分類帳，則應用程序將檢查查詢響應信息，並且不會將事務提交給 Ordering 服務。
如果客戶端應用程序的請求是更新分類賬本數據，則會將事務提交給 Ordering 服務以繼續下一步的操作，並且應用程序在提交事務之前檢查確定請求是否已滿足指定的認可策略（即指定的背書節點都認可）。
step4：
交易請求被提交到 Ordering 服務節點，該事務將包含讀/寫集，背書簽名和通道ID；Orderer 節點接收到事務請求之后，並不需要檢查交易中的具體數據，它只是從網絡中的所有通道接收交易，按時間順序對它們進行排序，並創建交易區塊。之后廣播給同一通道內所有組織的 Leader 節點。
step5：
Leader節點：Leader 節點對接收到的區塊進行驗證（交易消息結構是否正確、是否重復、是否有足夠的背書、讀寫集版本），通過驗證后將結果寫入到本地的分類賬本中。
step6：
同步廣播：Leader 節點同步廣播給組織內的其它節點（保證在同一通道內的）。
提示：在 Fabric 中，廣播給其它節點默認為臨近的3個節點。此廣播數量可以通過配置進行修改。
注：跨組織廣播則由組織內的 Anchor 節點負責。
分類賬本更新：
每個Peer節點將區塊附加到區塊鏈中，寫集被提交到當前的狀態數據庫中。並且對於每個有效的事務，發出一個事件，通知客戶端應用程序事務（調用）已被不可變地附加到鏈中，以及通知該事務是否已經過驗證或為無效事務。
原文出處：https://www.jianshu.com/p/6ea19d2e6115