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

一、HyperLeger Fabric架構簡介

1、通道簡介

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

2、Fabric區塊鏈網路拓撲

Fabric區塊鏈網路包括客戶端（Client），網路節點（Peer），CA（Certificate Authority）節點和排序節點（Orderer）。


客戶端的主要作用是與Fabric區塊鏈互動，實現對區塊鏈的操作。區塊鏈操作分為管理類和鏈碼類的兩種，管理類操作包括啟停節點和配置網路等；鏈碼類操作主要是鏈碼的生命週期管理，如安裝、例項化以及呼叫鏈碼。最常用的客戶端是命令列客戶端（CLI），此外是用Fabric SDK開發的應用客戶端。使用者通過不同的客戶端使用Fabric網路的功能。
Peer節點是區塊鏈去中心化網路中的對等節點，按照功能主要分為背書節點（Endorser）和確認節點（Committer，記賬節點）。背書節點主要對交易提案進行校驗、模擬執行和背書；確認節點主要負責檢驗交易的合法性，並更新和維護區塊鏈資料和賬本狀態。在實際部署中，背書節點和確認節點既可以部署在同一物理節點上，也可以分開部署。
排序節點（Orderer）主要職責是對各個節點發來的交易進行排序。在併發的情況下，各個節點交易的先後時序需要通過排序節點來確定並達成共識。排序節點按照一定規則確定交易順序後，發給各個記賬節點，把交易持久化到區塊鏈的賬本中。排序節點支援互相隔離的多個通道，使得交易只發送給相關的記賬節點（Peer）。
CA節點主要給Fabric網路中的成員提供基於數字證書的身份資訊，可以生成或取消成員的×××書（certificate）。在成員身份明確的基礎上，Fabric可以實現許可權控制的管理。
Fabric網路的元件往往歸屬於不同的組織，在組織之間形成對等的去中心化網路。每個組織通常擁有自己的客戶端、網路節點和CA節點，並且可以根據需要建立一個或多個不同的型別節點。排序節點不屬於某個組織的實體，屬於組織共同維護的節點。

3、Fabric區塊鏈架構簡介

Fabric區塊鏈的架構設計如下：

HyperLeger Fabric v1.0版本的架構包括三大部分:身份管理（Identity）、賬本和交易（Ledger | Transactions），智慧合約（Smart Contact）。
為了方便應用開發，Fabric提供不同的SDK，對服務端的鏈碼開發，目前提供Go、Java或者Node.js語言的SDK；對客戶端應用開發，目前提供Node.js、Java語言、Go語言版本的SDK。Fabric提供了RESTAPI，對於開發者，可以通過CLI快速去測試鏈碼，或者去查詢交易狀態。在區塊鏈網路裡，節點和鏈碼會發送事件來觸發一些監聽動作，方便與其它外部系統的整合。

4、身份管理

Fabric是目前為止在設計上最貼近聯盟鏈思想的區塊鏈。聯盟鏈考慮到商業應用對安全、隱私、監管、審計、效能的需求，提高准入門檻，成員必須被許可才能加入網路。Fabric的身份管理（Identity）為整個區塊鏈網路提供身份管理、隱私、保密和可審計的服務。身份管理通過公鑰基礎設施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來對公鑰進行簽發。

5、賬本

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

6、交易

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

7、智慧合約

Fabric上的智慧合約（Smart Contract）稱為鏈碼（ChainCode），是一段程式碼，用於處理網路成員所同意的業務邏輯。Fabric鏈碼和底層賬本是分開的，升級鏈碼時並不需要遷移賬本資料到新鏈碼當中，真正實現了邏輯與資料的分離。
鏈碼可採用Go、Java、Node.js語言編寫。鏈碼被編譯成一個獨立的應用程式，Fabric用Docker容器來執行鏈碼，容器裡的base映象都是經過簽名驗證的安全映象，包括OS層和開發鏈碼的語言、runtime和SDK層。一旦鏈碼容器被啟動，就會通過gRPC與啟動鏈碼的Peer節點連線。

二、業務通道

1、業務通道簡介

業務通道，即共識網路或區塊鏈網路，由不同的節點構成。節點是區塊鏈的通訊實體，是一個邏輯概念，不同型別的節點可以執行在同一臺物理伺服器上。節點可能部署在雲上或者本地，可能來自不同的公司或者組織。排序服務提供了供Peer節點訂閱的主題（如釋出-訂閱訊息佇列），每個主題是一個通道。Peer節點可以訂閱多個通道，並且只能訪問自己所訂閱通道上的交易。
在區塊鏈網路中有兩種型別的節點：Peer節點和Orderer節點。

Peer節點：鏈碼部署在Peer節點（背書節點）上，對賬本進行讀寫操作。一個Peer節點可以充當多種角色，如背書節點（endorser），確認節點（committer）。一個區塊鏈網路中會有多個Peer節點。
Orderer節點：對交易進行排序，批量打包交易，生成區塊，發給Peer節點（記賬節點）。一個區塊鏈網路中會有多個Orderer節點，共同提供排序服務。排序服務可以以多種不同的方式實現，從一箇中心化的服務（被用於開發和測試，如Solo）到分散式協議（如Kafka）。
排序服務提供了通向客戶端和Peer節點的共享通訊通道，提供了包含交易的訊息廣播服務（broadcast和deliver）。客戶端可以通過通道向通道內的所有節點廣播（broadcast）訊息，通道可以向連線到通道的所有節點投遞(deliver)訊息。
排序服務支援多通道。客戶端和Peer節點可以連線到一個具體的通道，並通過通道傳送和接收訊息。多通道使得Peer節點可以基於應用訪問控制策略來訂閱任意數量的通道；應用程式在指定Peer節點的子集中架設通道，Peer節點組成提交到該通道交易的相關者集合，而且只有通道內的Peer節點可以接收包含相關交易的區塊，與其它交易完全隔離，實現資料隔離和保密。
此外，Peers的子集將私有塊提交到不同的賬本上，允許它們保護這些私有交易，與其它Peer子集的賬本隔離開來。應用程式根據業務邏輯決定將交易傳送到1個或多個通道。

Peer 1，2和N訂閱紅色通道，並共同維護紅色賬本；Peer 1和N訂閱藍色通道並維護藍色賬本；Peer 2和peer N在黑色通道上並維護黑色賬本。每個通道都有一個相關的賬本，通常，不涉及所有Peer節點的賬本為子賬本，另一種是系統賬本，即全賬本。
目前通道分為系統通道（System Channel）和應用通道（Application Channel）。排序節點通過系統通道來管理應用通道，使用者的交易資訊通過應用通道傳遞。
通道由排序服務節點負責管理，同時排序服務節點還負責對通道中的交易進行排序。在通道中一般包含有若干成員（組織），若兩個網路實體的×××書能夠追溯到同一個根CA，則認為這兩個實體屬於同一組織。此外，通道中的每個組織都會有一個或以上的錨節點，錨節點負責與其它組織交換共享賬本的資料。
建立通道的時候定義了成員，只有通過成員MSP驗證的實體，才能夠加入到通道並訪問通道資料。

2、通道的配置

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

3、通道管理命令

通道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的路徑以及排序節點的地址。

4、動態修改通道配置

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

三、交易流程

1、Fabric交易流程簡介

Fabric v1.0的交易流程如下：
區塊鏈的賬本由Peer節點維護，並不是由排序服務叢集維護，所以，只有Peer節點（背書節點和確認節點）包含完整的區塊鏈資訊，而排序服務叢集只負責對交易進行排序，只保留處理過程中的一部分割槽塊鏈資訊。Hyperledger Fabric網路中的節點是一個邏輯的概念，並不一定是一個臺物理裝置，但對於生產環境，為了系統架構的解耦，提高擴充套件性以及通過主機隔離提高安全性，Peer節點不能和排序服務節點部署在一臺機器上，而背書節點和確認節點可以部署在同一臺機器上。背書節點校驗客戶端的簽名，然後執行智慧合約程式碼模擬交易。交易處理完成後，對交易資訊簽名，返回給客戶端。客戶端收到簽名後的交易資訊後，發給排序服務節點排序。排序服務節點將交易資訊排序打包成區塊後，廣播發給確認節點，寫入區塊鏈中。

2、客戶端構造交易提案

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

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

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

4、客戶端把交易傳送到排序服務節點

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

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

排序服務節點對接收到的交易進行共識排序，然後按照區塊生成策略，將一批交易打包到一起，生成新的區塊，呼叫deliver API投遞訊息，傳送給確認節點。

6、交易校驗

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

四、Fabric開發流程

1、Fabric開發簡介

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

2、Fabric區塊鏈開發流程

Fabric區塊鏈開發流程主要包括智慧合約編寫，通過SDK呼叫智慧合約，訂閱各類事件。
開發者建立客戶端應用和鏈碼，鏈碼被部署到區塊鏈網路的背書節點上。通過鏈碼來操作賬本，當客戶端呼叫一個交易時，實際上是在呼叫鏈碼中的一個實現業務邏輯的函式方法，並對賬本進行get, put, delete操作。客戶端應用提供使用者互動介面，並提交交易到區塊鏈網路上。