HyperLeger Fabric開發（三）——HyperLeger Fabric架構

HyperLeger Fabric開發（三）——HyperLeger Fabric架構

1、HyperLeger Fabric邏輯架構

一、HyperLeger Fabric邏輯架構簡介

Fabric邏輯架構根據不一樣角度進行劃分，上層基於應用程序角度進行設計，包括SDK、API、事件，經過SDK、API、事件來對底層區塊鏈進行操做：包括身份管理、帳本管理、交易管理、智能合約的部署和調用；下層基於底層區塊鏈進行設計，對外提供成員管理服務、共識服務、鏈碼服務、安全和密碼服務。
Fabric爲應用開發提供了標準的gRPC接口，在API的基礎上封裝了不一樣語言的SDK，包括Go、NODE.JS、Java、Python等，開發人員能夠利用SDK開發基於區塊鏈的應用；同時，區塊鏈的強一致性要求各個節點之間達成共識須要較長的執行時間，應用程序也是採用異步通訊的模式進行開發的，事件模塊能夠在觸發區塊事件或者鏈碼事件的時候執行預先定義的回調函數。
Fabric經過將各個部分分離成不一樣的模塊，作到可插拔性、靈活擴展性。

二、應用層邏輯架構

（1）身份管理
聯盟鏈考慮到商業應用對安全、隱私、監管、審計、性能的需求，提升准入門檻，成員必須被許可才能加入網絡。Fabric是目前爲止在設計上最貼近聯盟鏈思想的區塊鏈。聯盟鏈考慮到商業應用對安全、隱私、監管、審計、性能的需求，提升准入門檻，成員必須被許可才能加入網絡。Fabric成員管理服務爲整個區塊鏈網絡提供身份管理、隱私、保密和可審計的服務。成員管理服務經過公鑰基礎設施PKI和去中心化共識機制使得非許可的區塊鏈變成許可制的區塊鏈。
Fabric區塊鏈中，採用數字證書機制負責對網絡中的成員身份進行管理，CA節點實現了PKI服務。
PKI（Public Key Infrastructure）是綜合多種密碼學手段來實現安全可靠傳遞消息和身份確認的一個框架和規範。一般，PKI包括三部分：CA（Certification Authority）負責證書的頒發和做廢，接收來自RA的請求； RA（Registration Authority）負責對用戶身份進行驗證，校驗數據合法性，負責登記，審覈經過則發給CA；證書數據庫用於存放證書，通常採用LDAP目錄服務，標準格式採用X.500系列。
CA是PKI體系最核心的組件，主要完成對公鑰的管理。密鑰有兩種類型：用於簽名和用於加解密，對應稱爲簽名密鑰對和加密密鑰對。 用戶基於PKI體系要申請一個證書，通常能夠由CA來生成證書和私鑰，也能夠本身生成公鑰和私鑰，而後由CA來對公鑰進行簽發。
（2）帳本管理
受權的用戶是能夠查詢帳本數據的，能夠經過多種方式查詢，包括：
A、根據區塊號查詢區塊
B、根據區塊哈希查詢區塊
C、根據交易號查詢區塊
D、根據交易號查詢交易
E、根據通道名稱查詢區塊鏈信息
（3）交易管理
帳本數據只能經過交易執行才能更新，應用程序經過交易管理提交提案(Proposal)，在獲取到足夠數量交易背書(Endorsement)後，再給排序服務節點提交交易，排序服務將批量交易打包生成區塊。SDK提供接口，利用用戶證書本地生成交易號，背書節點和記帳節點都會校驗是否存在重複交易。
（4）智能合約
Fabric的智能合約（Smart Contract）稱爲鏈碼（ChainCode），是一段代碼，用於處理網絡成員所贊成的業務邏輯。Fabric的鏈碼和底層帳本是分開的，升級鏈碼時並不須要遷移帳本數據到新鏈碼當中，真正實現了邏輯與數據的分離。
Fabric經過智能合約實現了可編程的帳本，經過鏈碼執行提交的交易，實現基於區塊鏈的智能合約業務邏輯。只有智能合約才能更新帳本數據，其它模塊不能直接修改狀態數據。
鏈碼可採用Go、Java、Node.js語言編寫。鏈碼被編譯成一個獨立的應用程序，Fabric用Docker容器來運行鏈碼，容器裏的base鏡像都是通過簽名驗證的安全鏡像，包括OS層和開發鏈碼的語言、runtime和SDK層。一旦鏈碼容器被啓動，就會經過gRPC與啓動鏈碼的Peer節點鏈接。

三、底層邏輯架構

（1）成員服務管理
MSP（Member Service Provider）成員服務模塊對成員管理進行了抽象，提供包括會員註冊，身份保護、內容保密、交易審計等功能，可使用可插拔的Fabric-CA模塊或第三方的CA來代替。
（2）共識服務
共識服務負責節點間共識管理、帳本的分佈式計算、帳本的存儲及節點間的P2P協議功能的實現，是區塊鏈的核心組成部分，爲區塊鏈的主體功能提供了底層技術支撐
（3）鏈碼服務
鏈碼服務爲智能合約實現提供了一系列接口，併爲鏈碼的安裝、運行、部署提供了環境。智能合約的實現依賴於安全的執行環境，確保安全的執行過程和用戶數據的隔離。Fabric採用Docker管理普通的鏈碼，提供安全的沙箱環境和鏡像文件倉庫，可支持多種語言的鏈碼。
（4）安全和密碼服務
安全問題是企業級區塊鏈關心的問題，Hyperledger Fabric專門定義了一個BCCSP（BlockChain Cryptographic Service Provider）模塊，實現密鑰生成、哈希運算、簽名驗籤、加密解密等基礎功能。

四、HyperLeger Fabric邏輯架構的特色

Hyperledger Fabric採用模塊化架構設計，利用通用的功能模塊和接口。模塊化的方法帶來了可擴展性、靈活性等優點，會減小模塊修改、升級帶來的影響，能很好的利用微服務實現區塊鏈應用系統的開發和部署。
（1）模塊插件化
Fabric不少功能模塊（如CA模塊、共識算法、狀態數據庫存儲、ESCC、VSCC、BCCSP等）都是可插拔的。Fabric提供的通用接口和默認實現能夠知足大多數的業務需求，同時功能模塊也能夠根據需求進行擴展，集成到Fabric區塊鏈網絡系統中。
（2）充分利用容器技術
Fabric中不只節點使用容器做爲運行環境，鏈碼也默認運行在安全的容器中。應用程序或者外部系統不能直接操做鏈碼，必須經過背書節點提供的接口轉發給鏈碼來執行。容器給鏈碼運行提供安全沙箱環境，把鏈碼的環境和背書節點的環境隔離開，鏈碼存在安全問題也不會影響到背書節點。
（3）可擴展性
Hyperledger Fabric1.x版本對節點的角色進行了不一樣的拆分，有主節點(Leader)、背書節點(Endorser)、記帳節點(Committer)、排序服務節點(Orderer)等，不一樣角色的節點有不一樣的功能。節點能夠加入不一樣的通道中，鏈碼能夠運行在不一樣的背書節點上，能夠更好的提高並行執行的效率和吞吐量。
（4）安全性
Hyperledger Fabric提供受權訪問的區塊鏈網絡，節點共同維護成員信息，只有MSP(Member Service Provide)模塊驗證、受權的終端用戶才能使用區塊鏈網絡的功能。多鏈和多通道的設計容易實現數據隔離，也提供了應用程序和鏈碼之間的安全通道，實現了隱私保護。

2、HyperLeger Fabric網絡架構

一、HyperLeger Fabric網絡架構簡介

 Fabric網絡是經過組織來劃分的，每一個組織內都包含承擔不一樣功能的Peer 節點，每一個Peer節點又能夠擔任多種角色。全部的組織共用一個統一的Orderer排序服務集羣。基於Hyperledger Fabric區塊鏈網絡的設計時須要考慮組織之間的業務關係以及內部每一個模塊之間的聯繫，統一進行規劃。

Fabric網絡包含客戶端節點、CA節點、Peer節點、Orderer節點。

每一個組織一般擁有本身的客戶端、Peer節點和CA節點，而且能夠根據須要建立一個或多個不一樣的類型節點。Orderer節點不屬於某個組織的實體，屬於組織共同維護的節點。

二、客戶端節點

 客戶端或應用程序表明由終端用戶操做的實體，必須鏈接到某一個Peer節點或者排序服務節點上與區塊鏈網絡進行通訊。客戶端向背書節點（Endorser Peer）提交交易提案(Proposal)，當收集到足夠背書後，向排序服務節點廣播交易，進行排序，生成區塊。
客戶端的主要做用是與Fabric區塊鏈交互，實現對區塊鏈的操做。區塊鏈操做分爲管理類和鏈碼類的兩種，管理類操做包括啓停節點和配置網絡等；鏈碼類操做主要是鏈碼的生命週期管理，如安裝、實例化以及調用鏈碼。最經常使用的客戶端是命令行客戶端（CLI），此外是使用Fabric SDK開發的應用客戶端。

三、CA節點

CA節點主要給Fabric網絡中的成員提供基於數字證書的身份信息，能夠生成或取消成員的×××書（certificate）。CA節點是Fabric網絡的證書頒發節點(Certificate Authority)，由服務器(fabric-ca-server)和客戶端(fabric-ca-client)組成。
CA節點接收客戶端的註冊申請，返回註冊密碼用於登陸，以便獲取×××書。在區塊鏈網絡上全部的操做都會驗證用戶的身份。
CA節點是可選的，也能夠用其它成熟的第三方CA頒發證書。

四、Peer節點

Fabric區塊鏈網絡中的每一個組織能夠擁有一到多個Peer節點。每一個Peer節點能夠擔任多種角色：Endorser Peer（背書節點）、Leader Peer（主節點）、Committer Peer（記帳節點）、Anchor Peer（錨節點）。
每一個Peer節點一定是一個記帳節點，除記帳節點外，也能夠擔任其它一到多種角色，即某個Peer節點能夠同時是記帳節點和背書節點，也能夠同時是記帳節點、背書節點、主節點，錨節點。
（1）Endorser Peer（背書節點）
  部分Peer節點會執行交易並對結果進行簽名背書，充當背書節點的角色 。
  背書(Endorsement)是指特定Peer節點執行交易並向生成交易提案( proposal )的客戶端應用程序返回YES/NO響應的過程。
  背書節點是動態的角色，是與具體鏈碼綁定的。每一個鏈碼在實例化的時候都會設置背書策略(Endorsement policy)，指定哪些節點對交易背書纔有效。
   也只有在應用程序向節點發起交易背書請求時才成爲背書節點，其它時候是普通的記帳節點，只負責驗證交易並記帳。
（2）Leader Peer（主節點）
      主節點負責和Orderer排序服務節點通訊，從排序服務節點處獲取最新的區塊並在組織內部同步。能夠強制設置，也能夠選舉產生。
（3）Committer Peer（記帳節點）
  負責驗證從排序服務節點接收的區塊裏的交易，而後將區塊提交（寫入/追加）到其通道帳本的副本。記帳節點還將每一個塊中的每一個交易標記爲有效或無效。
（4）Anchor Peer（錨節點）
 在一個通道上能夠被全部其它Peer節點發現的Peer節點，通道上的每一個成員都有一個Anchor Peer(或多個Anchor Peer來防止單點故障)，容許屬於不一樣成員的Peer節點發現通道上的全部現有Peer節點。

五、Orderer（排序服務節點）

排序服務節點接收包含背書籤名的交易，對未打包的交易進行排序生成區塊，廣播給Peer節點。
排序服務提供的是原子廣播，保證同一個鏈上的節點爲接收到相同的消息，而且有相同的邏輯順序。
排序服務獨立於Peer進程存在而且以先來先服務的方式對Fabric網絡上的全部通道進行排序交易。排序服務旨在支持超出現有的SOLO和Kafka的可插拔實現。排序服務是整個網絡的公共綁定，包含綁定到每一個成員的加密身份材料。
排序服務節點按照必定規則肯定交易順序後，發給各個記帳節點，把交易持久化到區塊鏈的帳本中。排序服務節點支持互相隔離的多個通道，使得交易只發送給相關的記帳節點（Peer節點）。

3、Fabric多鏈多通道設計

一、通道簡介

商業應用的一個重要的需求是私密×××易，爲此Fabric設計了通道（Channel）來提供成員之間的隱私保護。通道是部分網絡成員之間擁有獨立的通訊渠道，在通道中發送的交易只有屬於通道的成員纔可見，所以通道能夠看做是Fabric的網絡中部分紅員的私有通訊子網。
通道由排序服務管理。在建立通道的時候，須要定義通道的成員和組織、錨節點（anchor peer）和排序服務節點，一條與通道對應的區塊鏈會同時生成，用於記錄帳本的交易，通道的初始配置信息記錄在區塊鏈的創世區塊中，能夠經過增長一個新的配置區塊來更改通道的配置信息。
每一個組織能夠有多個節點加入同一個通道，組織內的節點中能夠指定一個錨節點或多個錨節點（加強系統可靠性，避免單點故障）。組織的錨節點表明本組織與其它組織的節點交互，從而發現通道中的全部節點。另外，同一組織的節點會選舉或指定主導節點（leading peer），主導節點負責接收從排序服務發來的區塊，而後轉發給本組織的其它節點。主導節點能夠經過特定的算法選出，能夠保證在節點數量不斷變更的狀況下仍能維持整個網絡的穩定性。
在Fabric網絡中，可能同時存在多條彼此隔離的通道，每條通道包含一條私有的區塊鏈和一個私有帳本，通道中能夠實例化一個或多個鏈碼，以操做區塊鏈上的數據。

二、Fabric多鏈多通道設計

Fabric 1.x版本支持多鏈和多通道。Fabric的一條區塊鏈是包含Peer節點、帳本、排序服務的邏輯結構，將參與者與數據（包含鏈碼）進行隔離，知足不一樣業務場景下的不一樣的人訪問不一樣數據的基本要求。

通道是共識服務提供的一種通信機制，基於發佈-訂閱關係，將Peer節點和排序節點根據某個Topic鏈接在一塊兒，造成一個具備保密性的通信鏈路（虛擬），實現業務隔離的要求。
排序服務提供了供Peer節點訂閱的主題（如發佈-訂閱消息隊列），每一個主題是一個通道。Peer節點能夠訂閱多個通道，而且只能訪問本身所訂閱通道上的交易，所以一個Peer節點能夠經過接入多個通道參與到多條鏈中。
目前通道分爲系統通道（System Channel）和應用通道（Application Channel）。排序服務經過系統通道來管理應用通道，用戶的交易信息經過應用通道傳遞。
通道由排序服務節點負責管理，同時排序服務節點還負責對通道中的交易進行排序。在通道中通常包含有若干成員（組織），若兩個網絡實體的×××書可以追溯到同一個根CA，則認爲這兩個實體屬於同一組織。此外，通道中的每一個組織都會有一個或以上的錨節點，錨節點負責與其它組織交換共享帳本的數據。
建立通道的時候定義了成員，只有經過成員MSP驗證的實體，纔可以加入到通道並訪問通道的數據。
排序服務支持多通道，提供了通向客戶端和Peer節點的共享通訊通道，提供了包含交易的消息廣播服務（broadcast和deliver）。客戶端能夠經過通道向鏈接到通道的全部節點廣播（broadcast）消息，向鏈接到通道的全部節點投遞(deliver)消息。多通道使得Peer節點能夠基於應用訪問控制策略來訂閱任意數量的通道，應用程序根據業務邏輯決定將交易發送到1個或多個通道。

共識服務與（P一、PN）、（P一、P二、PN）、（P二、PN）組成三個相互獨立的通道，加入到不一樣通道的Peer節點可以維護各個通道對應的帳本和狀態。不一樣通道對應現實世界中不一樣業務場景下的參與方，如銀行、保險公司、物流企業、生產企業等實體結構。

三、通道的配置

通道的配置信息都被打包到一個區塊中，並存放在通道的共享帳本中，成爲通道的配置區塊，配置區塊除了配置信息外不包含其它交易信息。通道可使用配置區塊來更新配置，所以在帳本中每新添加一個配置區塊，通道就按照最新配置區塊的定義來修改配置。通道帳本的首個區塊必定是配置區塊，也稱爲創世區塊（Genesis Block）。

四、通道管理命令

通道的CLI客戶端可使用命令對通道進行管理。
peer channel create: 用於建立通道，主要參數有-c, -f, -o分別用於指定通道ID, configtx的路徑和orderer的地址。
peer channel fetch：抓取通道中的特定區塊，經過-c和-f參數來指定通道ID和orderer地址。
peer channel join：加入通道，經過-b參數指定初始區塊。
peer channel list：列出peer加入的通道。
peer channel update ：簽名而且發送configtx以升級通道配置，須要經過-c, -f, -o參數分別指定通道ID, configtx的路徑以及排序節點的地址。

五、動態修改通道配置

在通道建立後，通道相關的配置以區塊的形式存在於通道的帳本中。若是須要修改通道的配置，可經過生成新的配置區塊去更新。修改通道配置的步驟以下：
A、經過SDK或CLI得到最新的配置區塊。
B、編輯配置區塊。
C、計算配置更新量。
D、爲配置區塊添加配置更新量。
E、SDK或CLI簽名併發送配置區塊。
若新的配置區塊經過驗證，則通道配置以最新配置區塊爲準。

4、交易流程簡介

一、交易簡介

Fabric區塊鏈的交易分兩種，部署交易和調用交易。
部署交易把鏈碼部署到Peer節點上並準備好被調用，當一個部署交易成功執行時，鏈碼就被部署到各個背書節點上。
調用交易是客戶端應用程序經過Fabric提供的API調用先前已部署好的某個鏈碼的某個函數執行交易，並相應地讀取和寫入KV數據庫，返回是否成功或者失敗。

二、Fabric交易流程簡介

Fabric v1.0的交易流程以下：
區塊鏈的帳本由Peer節點維護，並非由排序服務集羣維護，因此，只有Peer節點（背書節點和確認節點）包含完整的區塊鏈信息，而排序服務集羣只負責對交易進行排序，只保留處理過程當中的一部分區塊鏈信息。Hyperledger Fabric網絡中的節點是一個邏輯的概念，並不必定是一個臺物理設備，但對於生產環境，爲了系統架構的解耦，提升擴展性以及經過主機隔離提升安全性，Peer節點不能和排序服務節點部署在一臺機器上，而背書節點和確認節點能夠部署在同一臺機器上。背書節點校驗客戶端的簽名，而後執行智能合約代碼模擬交易。交易處理完成後，對交易信息簽名，返回給客戶端。客戶端收到簽名後的交易信息後，發給排序服務節點排序。排序服務節點將交易信息排序打包成區塊後，廣播發給確認節點，寫入區塊鏈中。

三、客戶端構造交易提案

客戶端應用程序利用SDK（Node.js，Java，Python）構造交易提案（Proposal）。交易提案是一個調用智能合約功能函數的請求，用來確認哪些數據能夠讀取或寫入帳本。
客戶端把交易提案發送給一個或多個背書節點，交易提案中包含本次交易要調用的合約標識、合約方法和參數信息以及客戶端簽名等。
SDK將交易提案打包爲可識別的格式（如gRPC上的protobuf），並使用用戶的加密憑證爲該交易提案生成惟一的簽名。

四、背書節點模擬執行交易

背書節點（endorser）收到交易提案後，驗證簽名並肯定提交者是否有權執行操做。背書節點將交易提案的參數做爲輸入，在當前狀態KV數據庫上執行交易，生成包含執行返回值、讀操做集和寫操做集的交易結果（此時不會更新帳本），交易結果集、背書節點的簽名和背書結果（YES/NO）做爲提案的結果返回給客戶端SDK，SDK解析信息判斷是否應用於後續的交易。

五、客戶端把交易發送到排序服務節點

客戶端應用程序（SDK）驗證背書節點簽名，並比較各節點返回的提案結果，判斷提案結果是否一致以及是否參照指定的背書策略執行。
客戶端收到各個背書節點的應答後，打包到一塊兒組成一個交易並簽名，發送給排序服務節點。

六、共識排序，生成新區塊

排序服務節點對接收到的交易進行共識排序，而後按照區塊生成策略，將一批交易打包到一塊兒，生成新的區塊，調用deliver API投遞消息，發送給確認節點。

七、交易校驗

確認節點收到區塊後，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區塊鏈的狀態，完成後將區塊追加到本地的區塊鏈，並修改K-V狀態數據庫。

5、帳本簡介

Fabric使用創建在HTTP/2上的P2P協議來管理分佈式帳本，採起可插拔的方式來根據具體需求來設置共識協議，好比PBFT，Raft，PoW和PoS等。
Fabric網絡的數據以分佈式帳本的形式存儲。帳本由一系列有順序和防篡改的記錄組成，記錄包含着數據的所有狀態改變。帳本中的數據項以鍵值對的形式存放，帳本中全部的鍵值對構成了帳本的狀態，稱爲世界狀態（World State）。
每一個通道中有惟一的帳本，通道的帳本由通道中全部成員共同維護，每一個記帳節點上都保存所屬通道的帳本的一個副本，於是是分佈式帳本。對帳本的訪問須要經過鏈碼實現對帳本鍵值對的增長、刪除、更新和查詢等操做。
帳本由區塊鏈和狀態數據庫兩部分組成。
區塊鏈是一組不可更改的有序的區塊（數據塊），記錄着所有交易的日誌。每一個區塊中包含若干個交易的數據，不一樣區塊所包含的交易數量能夠不一樣。區塊之間用哈希鏈（Hashed-link）關聯：每一個區塊頭包含本區塊全部交易的哈希值，以及上一個區塊頭的哈希值。鏈式結構能夠確保每一個區塊的數據不可更改，以及每一個區塊之間的順序關係不可更改。所以，區塊鏈的區塊只能夠添加在鏈的尾部。
狀態數據庫記錄了帳本中全部鍵值對的當前值，至關於對當前帳本的交易日誌作了索引。鏈碼執行交易的時候須要讀取帳本的當前狀態，從狀態數據庫能夠迅速獲取鍵值的最新狀態。
若是沒有狀態數據庫，要得到某個鍵值時，須要遍歷整個區塊鏈中和該鍵值相關的交易，效率很是低，所以，讀取狀態數據庫能夠認爲是快速定位和訪問某個鍵值的方法。另外，當狀態數據庫出現故障的時候，能夠經過遍歷帳本從新生成。
當一個區塊附加到區塊鏈尾部的時候，若是區塊中的有效交易修改了鍵值對，則會在狀態數據庫中做相應的更新，確保區塊鏈和狀態數據庫始終保持一致。
區塊鏈的數據塊以文件形式保存在各個節點中。狀態數據庫能夠是各類鍵值數據庫，Fabric缺省使用LevelDB ，同時支持CouchDB選項。CouchDB除了支持鍵值數據外，也支持JSON格式的文檔模型，可以作複雜的查詢。

6、Fabric開發流程

一、Fabric開發簡介

Fabric聯盟鏈的開發人員主要分爲三類：底層開發者負責系統部署與維護；組織管理者負責證書、MSP權限管理、共識機制等；業務開發者負責編寫鏈碼、建立維護通道、執行交易等。

二、Fabric區塊鏈開發流程

Fabric區塊鏈開發流程主要包括智能合約編寫，經過SDK調用智能合約，訂閱各種事件。
開發者建立客戶端應用和鏈碼，鏈碼被部署到區塊鏈網絡的背書節點上。經過鏈碼來操做帳本，當客戶端調用一個交易時，其實是在調用鏈碼中的一個實現業務邏輯的函數方法，並對帳本進行get, put, delete操做。客戶端應用提供用戶交互界面，並提交交易到區塊鏈網絡上。