Fabric 網絡架構介紹
1. 網絡架構介紹
如圖所示，fabric網絡架構主要包含客戶端節點、CA節點、Peer節點、Orderer節點這幾個部分。並且fabric架構是安裝組織來進行划分當，每個組織都維護不同功能的peer節點。orderer節點屬於整個聯盟，一般不屬於某個組織。
其中，各個節點功能如下：
- CA節點
功能：Fabric網絡中的成員提供基於數字證書的身份信息。可選。可以用第三方生成的證書 - 客戶端節點
功能：與Fabric區塊鏈交互，實現對區塊鏈的操作。常見cli容器及SDK客戶端。客戶端代表代表最終用戶的實體。它必須連接到peer與區塊鏈進行通信。客戶端可以連接到其選擇的任何peer。客戶端創建交易。 - Peer節點
fabric每個組織都包含一個huoz多個peer節點。每個節點可以擔任多種角色。- Endorser Peer（背書節點）
功能：對客戶端發送交易提案時進行簽名背書，充當背書節點的角色 。背書(Endorsement)是指特定Peer節點執行交易並向生成交易提案( proposal )的客戶端應用程序返回YES/NO響應的過程。背書節點是動態的角色在鏈碼實例化的時設置背書策略(Endorsement policy)，指定哪些節點對交易背書才有效。只有在背書時是背書節點，其他時刻是普通節點。 - Leader Peer（主節點）
功能：主要負責與orderer排序節點通信，獲取區塊及在本組織進行同步。主節點的產生可以動態選舉或者指定。core.yaml useLeaderElection: true orgLeader: false - Committer Peer（記賬節點）
功能：對區塊及區塊交易進行驗證，驗證通過后將區塊寫入賬本中。 - Anchor Peer（錨節點）
功能：主要負責與其他組織的錨節點進行通信。
- Endorser Peer（背書節點）
- Orderer節點
功能：排序服務節點接收包含背書簽名的交易，對未打包的交易進行排序生成區塊，廣播給Peer節點。排序服務提供的是原子廣播，保證同一個鏈上的節點為接收到相同的消息，並且有相同的邏輯順序。
2.多通道設計
在Fabric中，引入了通道的概念。
一般情況下，一條區塊鏈網路的子鏈是按照“1個通道+ 1個賬本+ N個成員 ”的基本組成。
通道是兩個或多個特定網絡成員之間的通信的私有“子網”，用於進行需要數據保密的交易。在Fabric中，建立一個通道相當於建立了一個個子鏈。
創建通道是為了限制信息傳播的范圍，是和某一個賬本關聯的。每個交易都是和唯一的通道關聯的。這會明確地定義哪些實體（組織及其成員）會關注這個交易。
2.1Fabric多通道設計拓撲圖
如圖所示，存在3個通道，每個通道包含不同的peer。通道是共識服務提供的一種通訊機制，基於發布-訂閱關系，將Peer節點和排序節點根據某個Topic連接在一起，形成一個具有保密性的通訊鏈路（虛擬），實現業務隔離的要求。
排序服務提供了供Peer節點訂閱的主題（如發布-訂閱消息隊列），每個主題是一個通道。Peer節點可以訂閱多個通道，並且只能訪問自己所訂閱通道上的交易，因此一個Peer節點可以通過接入多個通道參與到多條鏈中。
目前通道分為系統通道（System Channel）和應用通道（Application Channel）。排序服務通過系統通道來管理應用通道，用戶的交易信息通過應用通道傳遞。
在創建通道的時候就定義了多個組織，每個組織一般包含多個peer，這些peer實體的msp證書都可以追溯到組織的證書。並且每個組織還定義了對應錨節點（anchor peer），通過錨節點來和其他組織錨節點通信。其相關配置都在configtx.yaml文件中，即在通道創世塊中。並且在后續如果想增加組織/成員/排序節點都可以通過修改配置塊來實現。
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.org1.example.com
Port: 7051
# 系統通道定義
TwoOrgsOrdererGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities:
<<: *OrdererCapabilities
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
# 應用通道定義
TwoOrgsChannel:
Consortium: SampleConsortium
<<: *ChannelDefaults
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Capabilities:
<<: *ApplicationCapabilities
3.交易流程
Fabric區塊鏈的交易分兩種，部署交易和調用交易。
部署交易把鏈碼部署到Peer節點上並准備好被調用，當一個部署交易成功執行時，鏈碼就被部署到各個背書節點上。
調用交易是客戶端應用程序通過Fabric提供的API調用先前已部署好的某個鏈碼的某個函數執行交易，並相應地讀取和寫入KV數據庫，返回是否成功或者失敗
典型的交易圖如圖所示。
交易流程圖如圖所示，其基本步驟為：
-
客戶端構建交易提案並發送給一個或多個背書節點。
消息格式：PROPOSE消息的格式是<PROPOSE,tx,[anchor]>，以下 tx是必需和anchor可選參數 tx=<clientID,chaincodeID,txPayload,timestamp,clientSig> clientID 是提交客戶端的ID， chaincodeID 指交易所涉及的鏈碼， txPayload 是包含提交的事務本身的有效負載， timestamp 是由客戶端維護的單調遞增（對於每個新事務）整數， clientSig是客戶端的簽名 txPayload調用事務和部署事務之間的細節將有所不同（即，調用引用特定於部署的系統鏈代碼的事務）。 對於調用交易， txPayload將包含兩個字段 txPayload = <operation, metadata> operation 表示鏈代碼操作（函數）和參數 metadata 表示與調用相關的屬性。 對於部署交易，txPayload將包含三個字段 txPayload = <source, metadata, policies> source 表示鏈碼的源代碼， metadata 表示與鏈代碼和應用程序相關的屬性， policies包含與所有對等方都可訪問的鏈代碼相關的策略 -
背書節點模擬執行交易及簽名
背書節點（endorser）收到交易提案后，驗證簽名並確定提交者是否有權執行操作。背書節點將交易提案的參數作為輸入，在當前狀態KV數據庫上執行交易，生成包含執行返回值、讀操作集和寫操作集的交易結果（此時不會更新賬本），交易結果集、背書節點的簽名和背書結果（支持/拒絕）作為提案的結果返回給客戶端。
讀寫集：
對於交易k讀取的每個密鑰，將對(k,s(k).version)添加到readset。
對於交易k修改為新值的每個鍵v'，(k,v')都會添加對writeset
請注意，背書在此步驟中不會更改其狀態，由交易模擬生成的更新不會影響狀態！ -
客戶端把交易發送到排序服務節點
客戶端收到背書（Endorser）節點返回的信息后，判斷提案結果是否一致，以及是否參照指定的背書策略執行，如果沒有足夠的背書，則中止處理；否則，客戶端把數據打包到一起組成一個交易並簽名，發送給Orderers。 -
共識排序，生成新區塊及Committer節點確認
Orderers對接收到的交易進行共識排序，然后按照區塊生成策略，將一批交易打包到一起，生成新的區塊，發送給提交（Committer）節點；提交（Committer）節點收到區塊后，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區塊鏈的狀態，完成后將區塊追加到本地的區塊鏈，並修改世界狀態。
