如何理解HyperLeger Fabric架構(gòu)

今天就跟大家聊聊有關(guān)如何理解HyperLeger Fabric架構(gòu)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

HyperLeger Fabric開發(fā)

一、HyperLeger Fabric邏輯架構(gòu)

1、HyperLeger Fabric邏輯架構(gòu)簡介

Fabric邏輯架構(gòu)根據(jù)不同角度進(jìn)行劃分，上層基于應(yīng)用程序角度進(jìn)行設(shè)計(jì)，包括SDK、API、事件，通過SDK、API、事件來對底層區(qū)塊鏈進(jìn)行操作：包括身份管理、賬本管理、交易管理、智能合約的部署和調(diào)用；下層基于底層區(qū)塊鏈進(jìn)行設(shè)計(jì)，對外提供成員管理服務(wù)、共識服務(wù)、鏈碼服務(wù)、安全和密碼服務(wù)。
Fabric為應(yīng)用開發(fā)提供了標(biāo)準(zhǔn)的gRPC接口，在API的基礎(chǔ)上封裝了不同語言的SDK，包括Go、NODE.JS、Java、Python等，開發(fā)人員可以利用SDK開發(fā)基于區(qū)塊鏈的應(yīng)用；同時，區(qū)塊鏈的強(qiáng)一致性要求各個節(jié)點(diǎn)之間達(dá)成共識需要較長的執(zhí)行時間，應(yīng)用程序也是采用異步通信的模式進(jìn)行開發(fā)的，事件模塊可以在觸發(fā)區(qū)塊事件或者鏈碼事件的時候執(zhí)行預(yù)先定義的回調(diào)函數(shù)。
Fabric通過將各個部分分離成不同的模塊，做到可插拔性、靈活擴(kuò)展性。

2、應(yīng)用層邏輯架構(gòu)

（1）身份管理
聯(lián)盟鏈考慮到商業(yè)應(yīng)用對安全、隱私、監(jiān)管、審計(jì)、性能的需求，提高準(zhǔn)入門檻，成員必須被許可才能加入網(wǎng)絡(luò)。Fabric是目前為止在設(shè)計(jì)上最貼近聯(lián)盟鏈思想的區(qū)塊鏈。聯(lián)盟鏈考慮到商業(yè)應(yīng)用對安全、隱私、監(jiān)管、審計(jì)、性能的需求，提高準(zhǔn)入門檻，成員必須被許可才能加入網(wǎng)絡(luò)。Fabric成員管理服務(wù)為整個區(qū)塊鏈網(wǎng)絡(luò)提供身份管理、隱私、保密和可審計(jì)的服務(wù)。成員管理服務(wù)通過公鑰基礎(chǔ)設(shè)施PKI和去中心化共識機(jī)制使得非許可的區(qū)塊鏈變成許可制的區(qū)塊鏈。
Fabric區(qū)塊鏈中，采用數(shù)字證書機(jī)制負(fù)責(zé)對網(wǎng)絡(luò)中的成員身份進(jìn)行管理，CA節(jié)點(diǎn)實(shí)現(xiàn)了PKI服務(wù)。
PKI（Public Key Infrastructure）是綜合多種密碼學(xué)手段來實(shí)現(xiàn)安全可靠傳遞消息和身份確認(rèn)的一個框架和規(guī)范。通常，PKI包括三部分：CA（Certification Authority）負(fù)責(zé)證書的頒發(fā)和作廢，接收來自RA的請求； RA（Registration Authority）負(fù)責(zé)對用戶身份進(jìn)行驗(yàn)證，校驗(yàn)數(shù)據(jù)合法性，負(fù)責(zé)登記，審核通過則發(fā)給CA；證書數(shù)據(jù)庫用于存放證書，一般采用LDAP目錄服務(wù)，標(biāo)準(zhǔn)格式采用X.500系列。
CA是PKI體系最核心的組件，主要完成對公鑰的管理。密鑰有兩種類型：用于簽名和用于加解密，對應(yīng)稱為簽名密鑰對和加密密鑰對。 用戶基于PKI體系要申請一個證書，一般可以由CA來生成證書和私鑰，也可以自己生成公鑰和私鑰，然后由CA來對公鑰進(jìn)行簽發(fā)。
（2）賬本管理
授權(quán)的用戶是可以查詢賬本數(shù)據(jù)的，可以通過多種方式查詢，包括：
A、根據(jù)區(qū)塊號查詢區(qū)塊
B、根據(jù)區(qū)塊哈希查詢區(qū)塊
C、根據(jù)交易號查詢區(qū)塊
D、根據(jù)交易號查詢交易
E、根據(jù)通道名稱查詢區(qū)塊鏈信息
（3）交易管理
賬本數(shù)據(jù)只能通過交易執(zhí)行才能更新，應(yīng)用程序通過交易管理提交提案(Proposal)，在獲取到足夠數(shù)量交易背書(Endorsement)后，再給排序服務(wù)節(jié)點(diǎn)提交交易，排序服務(wù)將批量交易打包生成區(qū)塊。SDK提供接口，利用用戶證書本地生成交易號，背書節(jié)點(diǎn)和記賬節(jié)點(diǎn)都會校驗(yàn)是否存在重復(fù)交易。
（4）智能合約
Fabric的智能合約（Smart Contract）稱為鏈碼（ChainCode），是一段代碼，用于處理網(wǎng)絡(luò)成員所同意的業(yè)務(wù)邏輯。Fabric的鏈碼和底層賬本是分開的，升級鏈碼時并不需要遷移賬本數(shù)據(jù)到新鏈碼當(dāng)中，真正實(shí)現(xiàn)了邏輯與數(shù)據(jù)的分離。
Fabric通過智能合約實(shí)現(xiàn)了可編程的賬本，通過鏈碼執(zhí)行提交的交易，實(shí)現(xiàn)基于區(qū)塊鏈的智能合約業(yè)務(wù)邏輯。只有智能合約才能更新賬本數(shù)據(jù)，其它模塊不能直接修改狀態(tài)數(shù)據(jù)。
鏈碼可采用Go、Java、Node.js語言編寫。鏈碼被編譯成一個獨(dú)立的應(yīng)用程序，F(xiàn)abric用Docker容器來運(yùn)行鏈碼，容器里的base鏡像都是經(jīng)過簽名驗(yàn)證的安全鏡像，包括OS層和開發(fā)鏈碼的語言、runtime和SDK層。一旦鏈碼容器被啟動，就會通過gRPC與啟動鏈碼的Peer節(jié)點(diǎn)連接。

3、底層邏輯架構(gòu)

（1）成員服務(wù)管理
MSP（Member Service Provider）成員服務(wù)模塊對成員管理進(jìn)行了抽象，提供包括會員注冊，身份保護(hù)、內(nèi)容保密、交易審計(jì)等功能，可以使用可插拔的Fabric-CA模塊或第三方的CA來代替。
（2）共識服務(wù)
共識服務(wù)負(fù)責(zé)節(jié)點(diǎn)間共識管理、賬本的分布式計(jì)算、賬本的存儲及節(jié)點(diǎn)間的P2P協(xié)議功能的實(shí)現(xiàn)，是區(qū)塊鏈的核心組成部分，為區(qū)塊鏈的主體功能提供了底層技術(shù)支撐
（3）鏈碼服務(wù)
鏈碼服務(wù)為智能合約實(shí)現(xiàn)提供了一系列接口，并為鏈碼的安裝、運(yùn)行、部署提供了環(huán)境。智能合約的實(shí)現(xiàn)依賴于安全的執(zhí)行環(huán)境，確保安全的執(zhí)行過程和用戶數(shù)據(jù)的隔離。Fabric采用Docker管理普通的鏈碼，提供安全的沙箱環(huán)境和鏡像文件倉庫，可支持多種語言的鏈碼。
（4）安全和密碼服務(wù)
安全問題是企業(yè)級區(qū)塊鏈關(guān)心的問題，Hyperledger Fabric專門定義了一個BCCSP（BlockChain Cryptographic Service Provider）模塊，實(shí)現(xiàn)密鑰生成、哈希運(yùn)算、簽名驗(yàn)簽、加密解密等基礎(chǔ)功能。

4、HyperLeger Fabric邏輯架構(gòu)的特點(diǎn)

Hyperledger Fabric采用模塊化架構(gòu)設(shè)計(jì)，利用通用的功能模塊和接口。模塊化的方法帶來了可擴(kuò)展性、靈活性等優(yōu)勢，會減少模塊修改、升級帶來的影響，能很好的利用微服務(wù)實(shí)現(xiàn)區(qū)塊鏈應(yīng)用系統(tǒng)的開發(fā)和部署。
（1）模塊插件化
Fabric很多功能模塊（如CA模塊、共識算法、狀態(tài)數(shù)據(jù)庫存儲、ESCC、VSCC、BCCSP等）都是可插拔的。Fabric提供的通用接口和默認(rèn)實(shí)現(xiàn)可以滿足大多數(shù)的業(yè)務(wù)需求，同時功能模塊也可以根據(jù)需求進(jìn)行擴(kuò)展，集成到Fabric區(qū)塊鏈網(wǎng)絡(luò)系統(tǒng)中。
（2）充分利用容器技術(shù)
Fabric中不僅節(jié)點(diǎn)使用容器作為運(yùn)行環(huán)境，鏈碼也默認(rèn)運(yùn)行在安全的容器中。應(yīng)用程序或者外部系統(tǒng)不能直接操作鏈碼，必須通過背書節(jié)點(diǎn)提供的接口轉(zhuǎn)發(fā)給鏈碼來執(zhí)行。容器給鏈碼運(yùn)行提供安全沙箱環(huán)境，把鏈碼的環(huán)境和背書節(jié)點(diǎn)的環(huán)境隔離開，鏈碼存在安全問題也不會影響到背書節(jié)點(diǎn)。
（3）可擴(kuò)展性
Hyperledger Fabric1.x版本對節(jié)點(diǎn)的角色進(jìn)行了不同的拆分，有主節(jié)點(diǎn)(Leader)、背書節(jié)點(diǎn)(Endorser)、記賬節(jié)點(diǎn)(Committer)、排序服務(wù)節(jié)點(diǎn)(Orderer)等，不同角色的節(jié)點(diǎn)有不同的功能。節(jié)點(diǎn)可以加入不同的通道中，鏈碼可以運(yùn)行在不同的背書節(jié)點(diǎn)上，可以更好的提升并行執(zhí)行的效率和吞吐量。
（4）安全性
Hyperledger Fabric提供授權(quán)訪問的區(qū)塊鏈網(wǎng)絡(luò)，節(jié)點(diǎn)共同維護(hù)成員信息，只有MSP(Member Service Provide)模塊驗(yàn)證、授權(quán)的終端用戶才能使用區(qū)塊鏈網(wǎng)絡(luò)的功能。多鏈和多通道的設(shè)計(jì)容易實(shí)現(xiàn)數(shù)據(jù)隔離，也提供了應(yīng)用程序和鏈碼之間的安全通道，實(shí)現(xiàn)了隱私保護(hù)。

二、HyperLeger Fabric網(wǎng)絡(luò)架構(gòu)

1、HyperLeger Fabric網(wǎng)絡(luò)架構(gòu)簡介

 Fabric網(wǎng)絡(luò)是通過組織來劃分的，每個組織內(nèi)都包含承擔(dān)不同功能的Peer 節(jié)點(diǎn)，每個Peer節(jié)點(diǎn)又可以擔(dān)任多種角色。所有的組織共用一個統(tǒng)一的Orderer排序服務(wù)集群?；贖yperledger Fabric區(qū)塊鏈網(wǎng)絡(luò)的設(shè)計(jì)時需要考慮組織之間的業(yè)務(wù)關(guān)系以及內(nèi)部每個模塊之間的聯(lián)系，統(tǒng)一進(jìn)行規(guī)劃。

Fabric網(wǎng)絡(luò)包含客戶端節(jié)點(diǎn)、CA節(jié)點(diǎn)、Peer節(jié)點(diǎn)、Orderer節(jié)點(diǎn)。

每個組織通常擁有自己的客戶端、Peer節(jié)點(diǎn)和CA節(jié)點(diǎn)，并且可以根據(jù)需要創(chuàng)建一個或多個不同的類型節(jié)點(diǎn)。Orderer節(jié)點(diǎn)不屬于某個組織的實(shí)體，屬于組織共同維護(hù)的節(jié)點(diǎn)。

2、客戶端節(jié)點(diǎn)

 客戶端或應(yīng)用程序代表由終端用戶操作的實(shí)體，必須連接到某一個Peer節(jié)點(diǎn)或者排序服務(wù)節(jié)點(diǎn)上與區(qū)塊鏈網(wǎng)絡(luò)進(jìn)行通信?？蛻舳讼虮硶?jié)點(diǎn)（Endorser Peer）提交交易提案(Proposal)，當(dāng)收集到足夠背書后，向排序服務(wù)節(jié)點(diǎn)廣播交易，進(jìn)行排序，生成區(qū)塊。
客戶端的主要作用是與Fabric區(qū)塊鏈交互，實(shí)現(xiàn)對區(qū)塊鏈的操作。區(qū)塊鏈操作分為管理類和鏈碼類的兩種，管理類操作包括啟停節(jié)點(diǎn)和配置網(wǎng)絡(luò)等；鏈碼類操作主要是鏈碼的生命周期管理，如安裝、實(shí)例化以及調(diào)用鏈碼。最常用的客戶端是命令行客戶端（CLI），此外是使用Fabric SDK開發(fā)的應(yīng)用客戶端。

3、CA節(jié)點(diǎn)

CA節(jié)點(diǎn)主要給Fabric網(wǎng)絡(luò)中的成員提供基于數(shù)字證書的身份信息，可以生成或取消成員的×××?xí)╟ertificate）。CA節(jié)點(diǎn)是Fabric網(wǎng)絡(luò)的證書頒發(fā)節(jié)點(diǎn)(Certificate Authority)，由服務(wù)器(fabric-ca-server)和客戶端(fabric-ca-client)組成。
CA節(jié)點(diǎn)接收客戶端的注冊申請，返回注冊密碼用于登錄，以便獲取×××?xí)?。在區(qū)塊鏈網(wǎng)絡(luò)上所有的操作都會驗(yàn)證用戶的身份。
CA節(jié)點(diǎn)是可選的，也可以用其它成熟的第三方CA頒發(fā)證書。

4、Peer節(jié)點(diǎn)

Fabric區(qū)塊鏈網(wǎng)絡(luò)中的每個組織可以擁有一到多個Peer節(jié)點(diǎn)。每個Peer節(jié)點(diǎn)可以擔(dān)任多種角色：Endorser Peer（背書節(jié)點(diǎn)）、Leader Peer（主節(jié)點(diǎn)）、Committer Peer（記賬節(jié)點(diǎn)）、Anchor Peer（錨節(jié)點(diǎn)）。
每個Peer節(jié)點(diǎn)必定是一個記賬節(jié)點(diǎn)，除記賬節(jié)點(diǎn)外，也可以擔(dān)任其它一到多種角色，即某個Peer節(jié)點(diǎn)可以同時是記賬節(jié)點(diǎn)和背書節(jié)點(diǎn)，也可以同時是記賬節(jié)點(diǎn)、背書節(jié)點(diǎn)、主節(jié)點(diǎn)，錨節(jié)點(diǎn)。
（1）Endorser Peer（背書節(jié)點(diǎn)）
  部分Peer節(jié)點(diǎn)會執(zhí)行交易并對結(jié)果進(jìn)行簽名背書，充當(dāng)背書節(jié)點(diǎn)的角色 。
  背書(Endorsement)是指特定Peer節(jié)點(diǎn)執(zhí)行交易并向生成交易提案( proposal )的客戶端應(yīng)用程序返回YES/NO響應(yīng)的過程。
  背書節(jié)點(diǎn)是動態(tài)的角色，是與具體鏈碼綁定的。每個鏈碼在實(shí)例化的時候都會設(shè)置背書策略(Endorsement policy)，指定哪些節(jié)點(diǎn)對交易背書才有效。
   也只有在應(yīng)用程序向節(jié)點(diǎn)發(fā)起交易背書請求時才成為背書節(jié)點(diǎn)，其它時候是普通的記賬節(jié)點(diǎn)，只負(fù)責(zé)驗(yàn)證交易并記賬。
（2）Leader Peer（主節(jié)點(diǎn)）
      主節(jié)點(diǎn)負(fù)責(zé)和Orderer排序服務(wù)節(jié)點(diǎn)通信，從排序服務(wù)節(jié)點(diǎn)處獲取最新的區(qū)塊并在組織內(nèi)部同步。可以強(qiáng)制設(shè)置，也可以選舉產(chǎn)生。
（3）Committer Peer（記賬節(jié)點(diǎn)）
    負(fù)責(zé)驗(yàn)證從排序服務(wù)節(jié)點(diǎn)接收的區(qū)塊里的交易，然后將區(qū)塊提交（寫入/追加）到其通道賬本的副本。記賬節(jié)點(diǎn)還將每個塊中的每個交易標(biāo)記為有效或無效。
（4）Anchor Peer（錨節(jié)點(diǎn)）
 在一個通道上可以被所有其它Peer節(jié)點(diǎn)發(fā)現(xiàn)的Peer節(jié)點(diǎn)，通道上的每個成員都有一個Anchor Peer(或多個Anchor Peer來防止單點(diǎn)故障)，允許屬于不同成員的Peer節(jié)點(diǎn)發(fā)現(xiàn)通道上的所有現(xiàn)有Peer節(jié)點(diǎn)。

5、Orderer（排序服務(wù)節(jié)點(diǎn)）

排序服務(wù)節(jié)點(diǎn)接收包含背書簽名的交易，對未打包的交易進(jìn)行排序生成區(qū)塊，廣播給Peer節(jié)點(diǎn)。
排序服務(wù)提供的是原子廣播，保證同一個鏈上的節(jié)點(diǎn)為接收到相同的消息，并且有相同的邏輯順序。
排序服務(wù)獨(dú)立于Peer進(jìn)程存在并且以先來先服務(wù)的方式對Fabric網(wǎng)絡(luò)上的所有通道進(jìn)行排序交易。排序服務(wù)旨在支持超出現(xiàn)有的SOLO和Kafka的可插拔實(shí)現(xiàn)。排序服務(wù)是整個網(wǎng)絡(luò)的公共綁定，包含綁定到每個成員的加密身份材料。
排序服務(wù)節(jié)點(diǎn)按照一定規(guī)則確定交易順序后，發(fā)給各個記賬節(jié)點(diǎn)，把交易持久化到區(qū)塊鏈的賬本中。排序服務(wù)節(jié)點(diǎn)支持互相隔離的多個通道，使得交易只發(fā)送給相關(guān)的記賬節(jié)點(diǎn)（Peer節(jié)點(diǎn)）。

三、Fabric多鏈多通道設(shè)計(jì)

1、通道簡介

商業(yè)應(yīng)用的一個重要的需求是私密×××易，為此Fabric設(shè)計(jì)了通道（Channel）來提供成員之間的隱私保護(hù)。通道是部分網(wǎng)絡(luò)成員之間擁有獨(dú)立的通信渠道，在通道中發(fā)送的交易只有屬于通道的成員才可見，因此通道可以看作是Fabric的網(wǎng)絡(luò)中部分成員的私有通信子網(wǎng)。
通道由排序服務(wù)管理。在創(chuàng)建通道的時候，需要定義通道的成員和組織、錨節(jié)點(diǎn)（anchor peer）和排序服務(wù)節(jié)點(diǎn)，一條與通道對應(yīng)的區(qū)塊鏈會同時生成，用于記錄賬本的交易，通道的初始配置信息記錄在區(qū)塊鏈的創(chuàng)世區(qū)塊中，可以通過增加一個新的配置區(qū)塊來更改通道的配置信息。
每個組織可以有多個節(jié)點(diǎn)加入同一個通道，組織內(nèi)的節(jié)點(diǎn)中可以指定一個錨節(jié)點(diǎn)或多個錨節(jié)點(diǎn)（增強(qiáng)系統(tǒng)可靠性，避免單點(diǎn)故障）。組織的錨節(jié)點(diǎn)代表本組織與其它組織的節(jié)點(diǎn)交互，從而發(fā)現(xiàn)通道中的所有節(jié)點(diǎn)。另外，同一組織的節(jié)點(diǎn)會選舉或指定主導(dǎo)節(jié)點(diǎn)（leading peer），主導(dǎo)節(jié)點(diǎn)負(fù)責(zé)接收從排序服務(wù)發(fā)來的區(qū)塊，然后轉(zhuǎn)發(fā)給本組織的其它節(jié)點(diǎn)。主導(dǎo)節(jié)點(diǎn)可以通過特定的算法選出，可以保證在節(jié)點(diǎn)數(shù)量不斷變動的情況下仍能維持整個網(wǎng)絡(luò)的穩(wěn)定性。
在Fabric網(wǎng)絡(luò)中，可能同時存在多條彼此隔離的通道，每條通道包含一條私有的區(qū)塊鏈和一個私有賬本，通道中可以實(shí)例化一個或多個鏈碼，以操作區(qū)塊鏈上的數(shù)據(jù)。

2、Fabric多鏈多通道設(shè)計(jì)

Fabric 1.x版本支持多鏈和多通道。Fabric的一條區(qū)塊鏈?zhǔn)前琍eer節(jié)點(diǎn)、賬本、排序服務(wù)的邏輯結(jié)構(gòu)，將參與者與數(shù)據(jù)（包含鏈碼）進(jìn)行隔離，滿足不同業(yè)務(wù)場景下的不同的人訪問不同數(shù)據(jù)的基本要求。

通道是共識服務(wù)提供的一種通訊機(jī)制，基于發(fā)布-訂閱關(guān)系，將Peer節(jié)點(diǎn)和排序節(jié)點(diǎn)根據(jù)某個Topic連接在一起，形成一個具有保密性的通訊鏈路（虛擬），實(shí)現(xiàn)業(yè)務(wù)隔離的要求。
排序服務(wù)提供了供Peer節(jié)點(diǎn)訂閱的主題（如發(fā)布-訂閱消息隊(duì)列），每個主題是一個通道。Peer節(jié)點(diǎn)可以訂閱多個通道，并且只能訪問自己所訂閱通道上的交易，因此一個Peer節(jié)點(diǎn)可以通過接入多個通道參與到多條鏈中。
目前通道分為系統(tǒng)通道（System Channel）和應(yīng)用通道（Application Channel）。排序服務(wù)通過系統(tǒng)通道來管理應(yīng)用通道，用戶的交易信息通過應(yīng)用通道傳遞。
通道由排序服務(wù)節(jié)點(diǎn)負(fù)責(zé)管理，同時排序服務(wù)節(jié)點(diǎn)還負(fù)責(zé)對通道中的交易進(jìn)行排序。在通道中一般包含有若干成員（組織），若兩個網(wǎng)絡(luò)實(shí)體的×××?xí)軌蜃匪莸酵粋€根CA，則認(rèn)為這兩個實(shí)體屬于同一組織。此外，通道中的每個組織都會有一個或以上的錨節(jié)點(diǎn)，錨節(jié)點(diǎn)負(fù)責(zé)與其它組織交換共享賬本的數(shù)據(jù)。
創(chuàng)建通道的時候定義了成員，只有通過成員MSP驗(yàn)證的實(shí)體，才能夠加入到通道并訪問通道的數(shù)據(jù)。
排序服務(wù)支持多通道，提供了通向客戶端和Peer節(jié)點(diǎn)的共享通信通道，提供了包含交易的消息廣播服務(wù)（broadcast和deliver）?？蛻舳丝梢酝ㄟ^通道向連接到通道的所有節(jié)點(diǎn)廣播（broadcast）消息，向連接到通道的所有節(jié)點(diǎn)投遞(deliver)消息。多通道使得Peer節(jié)點(diǎn)可以基于應(yīng)用訪問控制策略來訂閱任意數(shù)量的通道，應(yīng)用程序根據(jù)業(yè)務(wù)邏輯決定將交易發(fā)送到1個或多個通道。

共識服務(wù)與（P1、PN）、（P1、P2、PN）、（P2、PN）組成三個相互獨(dú)立的通道，加入到不同通道的Peer節(jié)點(diǎn)能夠維護(hù)各個通道對應(yīng)的賬本和狀態(tài)。不同通道對應(yīng)現(xiàn)實(shí)世界中不同業(yè)務(wù)場景下的參與方，如銀行、保險(xiǎn)公司、物流企業(yè)、生產(chǎn)企業(yè)等實(shí)體結(jié)構(gòu)。

3、通道的配置

通道的配置信息都被打包到一個區(qū)塊中，并存放在通道的共享賬本中，成為通道的配置區(qū)塊，配置區(qū)塊除了配置信息外不包含其它交易信息。通道可以使用配置區(qū)塊來更新配置，因此在賬本中每新添加一個配置區(qū)塊，通道就按照最新配置區(qū)塊的定義來修改配置。通道賬本的首個區(qū)塊一定是配置區(qū)塊，也稱為創(chuàng)世區(qū)塊（Genesis Block）。

4、通道管理命令

通道的CLI客戶端可以使用命令對通道進(jìn)行管理。
peer channel create: 用于創(chuàng)建通道，主要參數(shù)有-c, -f, -o分別用于指定通道ID, configtx的路徑和orderer的地址。
peer channel fetch：抓取通道中的特定區(qū)塊，通過-c和-f參數(shù)來指定通道ID和orderer地址。
peer channel join：加入通道，通過-b參數(shù)指定初始區(qū)塊。
peer channel list：列出peer加入的通道。
peer channel update ：簽名并且發(fā)送configtx以升級通道配置，需要通過-c, -f, -o參數(shù)分別指定通道ID, configtx的路徑以及排序節(jié)點(diǎn)的地址。

5、動態(tài)修改通道配置

在通道創(chuàng)建后，通道相關(guān)的配置以區(qū)塊的形式存在于通道的賬本中。如果需要修改通道的配置，可通過生成新的配置區(qū)塊去更新。修改通道配置的步驟如下：
A、通過SDK或CLI獲得最新的配置區(qū)塊。
B、編輯配置區(qū)塊。
C、計(jì)算配置更新量。
D、為配置區(qū)塊添加配置更新量。
E、SDK或CLI簽名并發(fā)送配置區(qū)塊。
若新的配置區(qū)塊通過驗(yàn)證，則通道配置以最新配置區(qū)塊為準(zhǔn)。

四、交易流程簡介

1、交易簡介

Fabric區(qū)塊鏈的交易分兩種，部署交易和調(diào)用交易。
部署交易把鏈碼部署到Peer節(jié)點(diǎn)上并準(zhǔn)備好被調(diào)用，當(dāng)一個部署交易成功執(zhí)行時，鏈碼就被部署到各個背書節(jié)點(diǎn)上。
調(diào)用交易是客戶端應(yīng)用程序通過Fabric提供的API調(diào)用先前已部署好的某個鏈碼的某個函數(shù)執(zhí)行交易，并相應(yīng)地讀取和寫入KV數(shù)據(jù)庫，返回是否成功或者失敗。

2、Fabric交易流程簡介

Fabric v1.0的交易流程如下：
區(qū)塊鏈的賬本由Peer節(jié)點(diǎn)維護(hù)，并不是由排序服務(wù)集群維護(hù)，所以，只有Peer節(jié)點(diǎn)（背書節(jié)點(diǎn)和確認(rèn)節(jié)點(diǎn)）包含完整的區(qū)塊鏈信息，而排序服務(wù)集群只負(fù)責(zé)對交易進(jìn)行排序，只保留處理過程中的一部分區(qū)塊鏈信息。Hyperledger Fabric網(wǎng)絡(luò)中的節(jié)點(diǎn)是一個邏輯的概念，并不一定是一個臺物理設(shè)備，但對于生產(chǎn)環(huán)境，為了系統(tǒng)架構(gòu)的解耦，提高擴(kuò)展性以及通過主機(jī)隔離提高安全性，Peer節(jié)點(diǎn)不能和排序服務(wù)節(jié)點(diǎn)部署在一臺機(jī)器上，而背書節(jié)點(diǎn)和確認(rèn)節(jié)點(diǎn)可以部署在同一臺機(jī)器上。背書節(jié)點(diǎn)校驗(yàn)客戶端的簽名，然后執(zhí)行智能合約代碼模擬交易。交易處理完成后，對交易信息簽名，返回給客戶端?？蛻舳耸盏胶灻蟮慕灰仔畔⒑螅l(fā)給排序服務(wù)節(jié)點(diǎn)排序。排序服務(wù)節(jié)點(diǎn)將交易信息排序打包成區(qū)塊后，廣播發(fā)給確認(rèn)節(jié)點(diǎn)，寫入?yún)^(qū)塊鏈中。

3、客戶端構(gòu)造交易提案

客戶端應(yīng)用程序利用SDK（Node.js，Java，Python）構(gòu)造交易提案（Proposal）。交易提案是一個調(diào)用智能合約功能函數(shù)的請求，用來確認(rèn)哪些數(shù)據(jù)可以讀取或?qū)懭胭~本。
客戶端把交易提案發(fā)送給一個或多個背書節(jié)點(diǎn)，交易提案中包含本次交易要調(diào)用的合約標(biāo)識、合約方法和參數(shù)信息以及客戶端簽名等。
SDK將交易提案打包為可識別的格式（如gRPC上的protobuf），并使用用戶的加密憑證為該交易提案生成唯一的簽名。

4、背書節(jié)點(diǎn)模擬執(zhí)行交易

背書節(jié)點(diǎn)（endorser）收到交易提案后，驗(yàn)證簽名并確定提交者是否有權(quán)執(zhí)行操作。背書節(jié)點(diǎn)將交易提案的參數(shù)作為輸入，在當(dāng)前狀態(tài)KV數(shù)據(jù)庫上執(zhí)行交易，生成包含執(zhí)行返回值、讀操作集和寫操作集的交易結(jié)果（此時不會更新賬本），交易結(jié)果集、背書節(jié)點(diǎn)的簽名和背書結(jié)果（YES/NO）作為提案的結(jié)果返回給客戶端SDK，SDK解析信息判斷是否應(yīng)用于后續(xù)的交易。

5、客戶端把交易發(fā)送到排序服務(wù)節(jié)點(diǎn)

客戶端應(yīng)用程序（SDK）驗(yàn)證背書節(jié)點(diǎn)簽名，并比較各節(jié)點(diǎn)返回的提案結(jié)果，判斷提案結(jié)果是否一致以及是否參照指定的背書策略執(zhí)行。
客戶端收到各個背書節(jié)點(diǎn)的應(yīng)答后，打包到一起組成一個交易并簽名，發(fā)送給排序服務(wù)節(jié)點(diǎn)。

6、共識排序，生成新區(qū)塊

排序服務(wù)節(jié)點(diǎn)對接收到的交易進(jìn)行共識排序，然后按照區(qū)塊生成策略，將一批交易打包到一起，生成新的區(qū)塊，調(diào)用deliver API投遞消息，發(fā)送給確認(rèn)節(jié)點(diǎn)。

7、交易校驗(yàn)

確認(rèn)節(jié)點(diǎn)收到區(qū)塊后，會對區(qū)塊中的每筆交易進(jìn)行校驗(yàn)，檢查交易依賴的輸入輸出是否符合當(dāng)前區(qū)塊鏈的狀態(tài)，完成后將區(qū)塊追加到本地的區(qū)塊鏈，并修改K-V狀態(tài)數(shù)據(jù)庫。

五、賬本簡介

Fabric使用建立在HTTP/2上的P2P協(xié)議來管理分布式賬本，采取可插拔的方式來根據(jù)具體需求來設(shè)置共識協(xié)議，比如PBFT，Raft，PoW和PoS等。
Fabric網(wǎng)絡(luò)的數(shù)據(jù)以分布式賬本的形式存儲。賬本由一系列有順序和防篡改的記錄組成，記錄包含著數(shù)據(jù)的全部狀態(tài)改變。賬本中的數(shù)據(jù)項(xiàng)以鍵值對的形式存放，賬本中所有的鍵值對構(gòu)成了賬本的狀態(tài)，稱為世界狀態(tài)（World State）。
每個通道中有唯一的賬本，通道的賬本由通道中所有成員共同維護(hù)，每個記賬節(jié)點(diǎn)上都保存所屬通道的賬本的一個副本，因而是分布式賬本。對賬本的訪問需要通過鏈碼實(shí)現(xiàn)對賬本鍵值對的增加、刪除、更新和查詢等操作。
賬本由區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫兩部分組成。
區(qū)塊鏈?zhǔn)且唤M不可更改的有序的區(qū)塊（數(shù)據(jù)塊），記錄著全部交易的日志。每個區(qū)塊中包含若干個交易的數(shù)據(jù)，不同區(qū)塊所包含的交易數(shù)量可以不同。區(qū)塊之間用哈希鏈（Hashed-link）關(guān)聯(lián)：每個區(qū)塊頭包含本區(qū)塊所有交易的哈希值，以及上一個區(qū)塊頭的哈希值。鏈?zhǔn)浇Y(jié)構(gòu)可以確保每個區(qū)塊的數(shù)據(jù)不可更改，以及每個區(qū)塊之間的順序關(guān)系不可更改。因此，區(qū)塊鏈的區(qū)塊只可以添加在鏈的尾部。
狀態(tài)數(shù)據(jù)庫記錄了賬本中所有鍵值對的當(dāng)前值，相當(dāng)于對當(dāng)前賬本的交易日志做了索引。鏈碼執(zhí)行交易的時候需要讀取賬本的當(dāng)前狀態(tài)，從狀態(tài)數(shù)據(jù)庫可以迅速獲取鍵值的最新狀態(tài)。
如果沒有狀態(tài)數(shù)據(jù)庫，要獲得某個鍵值時，需要遍歷整個區(qū)塊鏈中和該鍵值相關(guān)的交易，效率非常低，因此，讀取狀態(tài)數(shù)據(jù)庫可以認(rèn)為是快速定位和訪問某個鍵值的方法。另外，當(dāng)狀態(tài)數(shù)據(jù)庫出現(xiàn)故障的時候，可以通過遍歷賬本重新生成。
當(dāng)一個區(qū)塊附加到區(qū)塊鏈尾部的時候，如果區(qū)塊中的有效交易修改了鍵值對，則會在狀態(tài)數(shù)據(jù)庫中作相應(yīng)的更新，確保區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫始終保持一致。
區(qū)塊鏈的數(shù)據(jù)塊以文件形式保存在各個節(jié)點(diǎn)中。狀態(tài)數(shù)據(jù)庫可以是各種鍵值數(shù)據(jù)庫，F(xiàn)abric缺省使用LevelDB ，同時支持CouchDB選項(xiàng)。CouchDB除了支持鍵值數(shù)據(jù)外，也支持JSON格式的文檔模型，能夠做復(fù)雜的查詢。

六、Fabric開發(fā)流程

1、Fabric開發(fā)簡介

Fabric聯(lián)盟鏈的開發(fā)人員主要分為三類：底層開發(fā)者負(fù)責(zé)系統(tǒng)部署與維護(hù)；組織管理者負(fù)責(zé)證書、MSP權(quán)限管理、共識機(jī)制等；業(yè)務(wù)開發(fā)者負(fù)責(zé)編寫鏈碼、創(chuàng)建維護(hù)通道、執(zhí)行交易等。

2、Fabric區(qū)塊鏈開發(fā)流程

Fabric區(qū)塊鏈開發(fā)流程主要包括智能合約編寫，通過SDK調(diào)用智能合約，訂閱各類事件。
開發(fā)者創(chuàng)建客戶端應(yīng)用和鏈碼，鏈碼被部署到區(qū)塊鏈網(wǎng)絡(luò)的背書節(jié)點(diǎn)上。通過鏈碼來操作賬本，當(dāng)客戶端調(diào)用一個交易時，實(shí)際上是在調(diào)用鏈碼中的一個實(shí)現(xiàn)業(yè)務(wù)邏輯的函數(shù)方法，并對賬本進(jìn)行g(shù)et, put, delete操作。客戶端應(yīng)用提供用戶交互界面，并提交交易到區(qū)塊鏈網(wǎng)絡(luò)上。

看完上述內(nèi)容，你們對如何理解HyperLeger Fabric架構(gòu)有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。