Fabric交易流程

(內容可能有些亂，請見諒，日后會對格式進行整理！)

 

#### 在1.0及以后的版本中，客戶端應用會先向Fabric CA申請用戶所需要的Fabric中的准入證書，用於簽名提案以及交易，然后由客戶端（Application）端生成一個提案（Proposal）(一般應用程序會借助於目前Fabric提供的一系列SDK生成Proposal)發送至背書節點進行模擬執行並進行背書，背書節點Endorser會進行相應的校驗，然后將提案交由對應的鏈碼Chaincode進行模擬執行，之后背書節點Endorser會對執行結果進行背書,將背書的Response返回至客戶端程序Application，隨之，客戶端程收集到符合背書策略的提案響應（Proposal Response）之后，將其封裝成一個交易Transaction，調用排序節點Orderer的Broadcast接口，進行發送交易至Orderer，在v1.0-v1.4版本中，生產環境只有基於分布式消息隊列Kafka的排序打包方式，Orderer作為生產者將交易統一發送至每個通道Channel對應的Topic的Partition當中進行全局統一地排序，同時每個排序節點基於同樣的切塊規則從Kafka中將區塊切下推送Deliver至與之連接的Leader Peer（在網絡環境良好的情況下，每個組織只有一個leader），Leader Peer收到區塊后，會將區塊通過Gossip協議廣播至組織內其余節點。每個Committer在收到區塊之后會對區塊進行校驗，包括簽名、背書策略以及讀寫集的校驗，在校驗無誤的情況下進行commit，提交到賬本，同時更新世界狀態，同時訂閱了相應事件的應用程序會收到來自Event Hub的消息通知。

Orderer對來自不同通道的交易做區分，同時在Peer節點中會采用MSP對不同通道的消息做校驗，用於判斷消息是否屬於某個通道，通過Orderer以及Peer相結合，形成一個邏輯上的通道技術。

---

執行—排序—驗證

一、執行階段：

客戶端發送的交易提案是調用鏈碼功能的請求。背書節點對交易提案進行4點驗證：

1. 格式是否正確；

2. 在之前沒有被提交過；

3. (客戶端的)簽名是否有效；

4. 提交者/客戶端是否被授權執行此次提案的操作。

如果以上驗證都通過，背書節點就將提案輸入作為所調用鏈碼函數的參數，對當前狀態數據庫執行chaincode並返回經過背書節點簽名的執行結果(讀寫集)給客戶端！然后客戶端收集背書，直到滿足背書策略。

二、排序階段：

當收集到足夠數量的背書后，客戶端將提案、執行結果和背書組裝成交易，發送給排序服務。排序服務按通道、按時間順序對接收的交易進行排序，並為每個通道創建區塊(注意：排序服務接收到交易的順序並不一定是交易被打包進入區塊的順序。。。)。然后將區塊發送到每個通道上的主節點(leader)，由背書節點向其所在通道內的peers分發交易。

三、驗證階段：

當每個peer接收到新區塊后，會對其中包含的交易進行驗證，以確保滿足背書策略，以及確保賬本當前狀態的"讀集"變量沒有變化(因為"讀集"是由當前區塊中的交易執行生成的)。然后每個peer將區塊追加到本地的區塊鏈副本上，並將"寫集"提交到當前狀態數據庫！