今天就跟大家聊聊有關(guān)如何理解HyperLeger Fabric架構(gòu)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供棲霞網(wǎng)站建設(shè)、棲霞做網(wǎng)站、棲霞網(wǎng)站設(shè)計、棲霞網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、棲霞企業(yè)網(wǎng)站模板建站服務(wù)，10余年棲霞做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
Fabric邏輯架構(gòu)根據(jù)不同角度進行劃分，上層基于應(yīng)用程序角度進行設(shè)計，包括SDK、API、事件，通過SDK、API、事件來對底層區(qū)塊鏈進行操作：包括身份管理、賬本管理、交易管理、智能合約的部署和調(diào)用；下層基于底層區(qū)塊鏈進行設(shè)計，對外提供成員管理服務(wù)、共識服務(wù)、鏈碼服務(wù)、安全和密碼服務(wù)。
Fabric為應(yīng)用開發(fā)提供了標準的gRPC接口，在API的基礎(chǔ)上封裝了不同語言的SDK，包括Go、NODE.JS、Java、Python等，開發(fā)人員可以利用SDK開發(fā)基于區(qū)塊鏈的應(yīng)用；同時，區(qū)塊鏈的強一致性要求各個節(jié)點之間達成共識需要較長的執(zhí)行時間，應(yīng)用程序也是采用異步通信的模式進行開發(fā)的，事件模塊可以在觸發(fā)區(qū)塊事件或者鏈碼事件的時候執(zhí)行預(yù)先定義的回調(diào)函數(shù)。
Fabric通過將各個部分分離成不同的模塊，做到可插拔性、靈活擴展性。
（1）身份管理
聯(lián)盟鏈考慮到商業(yè)應(yīng)用對安全、隱私、監(jiān)管、審計、性能的需求，提高準入門檻，成員必須被許可才能加入網(wǎng)絡(luò)。Fabric是目前為止在設(shè)計上最貼近聯(lián)盟鏈思想的區(qū)塊鏈。聯(lián)盟鏈考慮到商業(yè)應(yīng)用對安全、隱私、監(jiān)管、審計、性能的需求，提高準入門檻，成員必須被許可才能加入網(wǎng)絡(luò)。Fabric成員管理服務(wù)為整個區(qū)塊鏈網(wǎng)絡(luò)提供身份管理、隱私、保密和可審計的服務(wù)。成員管理服務(wù)通過公鑰基礎(chǔ)設(shè)施PKI和去中心化共識機制使得非許可的區(qū)塊鏈變成許可制的區(qū)塊鏈。
Fabric區(qū)塊鏈中，采用數(shù)字證書機制負責對網(wǎng)絡(luò)中的成員身份進行管理，CA節(jié)點實現(xiàn)了PKI服務(wù)。
PKI（Public Key Infrastructure）是綜合多種密碼學手段來實現(xiàn)安全可靠傳遞消息和身份確認的一個框架和規(guī)范。通常，PKI包括三部分：CA（Certification Authority）負責證書的頒發(fā)和作廢，接收來自RA的請求； RA（Registration Authority）負責對用戶身份進行驗證，校驗數(shù)據(jù)合法性，負責登記，審核通過則發(fā)給CA；證書數(shù)據(jù)庫用于存放證書，一般采用LDAP目錄服務(wù)，標準格式采用X.500系列。
CA是PKI體系最核心的組件，主要完成對公鑰的管理。密鑰有兩種類型：用于簽名和用于加解密，對應(yīng)稱為簽名密鑰對和加密密鑰對。 用戶基于PKI體系要申請一個證書，一般可以由CA來生成證書和私鑰，也可以自己生成公鑰和私鑰，然后由CA來對公鑰進行簽發(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é)點提交交易，排序服務(wù)將批量交易打包生成區(qū)塊。SDK提供接口，利用用戶證書本地生成交易號，背書節(jié)點和記賬節(jié)點都會校驗是否存在重復交易。
（4）智能合約
Fabric的智能合約（Smart Contract）稱為鏈碼（ChainCode），是一段代碼，用于處理網(wǎng)絡(luò)成員所同意的業(yè)務(wù)邏輯。Fabric的鏈碼和底層賬本是分開的，升級鏈碼時并不需要遷移賬本數(shù)據(jù)到新鏈碼當中，真正實現(xiàn)了邏輯與數(shù)據(jù)的分離。
Fabric通過智能合約實現(xiàn)了可編程的賬本，通過鏈碼執(zhí)行提交的交易，實現(xiàn)基于區(qū)塊鏈的智能合約業(yè)務(wù)邏輯。只有智能合約才能更新賬本數(shù)據(jù)，其它模塊不能直接修改狀態(tài)數(shù)據(jù)。
鏈碼可采用Go、Java、Node.js語言編寫。鏈碼被編譯成一個獨立的應(yīng)用程序，F(xiàn)abric用Docker容器來運行鏈碼，容器里的base鏡像都是經(jīng)過簽名驗證的安全鏡像，包括OS層和開發(fā)鏈碼的語言、runtime和SDK層。一旦鏈碼容器被啟動，就會通過gRPC與啟動鏈碼的Peer節(jié)點連接。
（1）成員服務(wù)管理
MSP（Member Service Provider）成員服務(wù)模塊對成員管理進行了抽象，提供包括會員注冊，身份保護、內(nèi)容保密、交易審計等功能，可以使用可插拔的Fabric-CA模塊或第三方的CA來代替。
（2）共識服務(wù)
共識服務(wù)負責節(jié)點間共識管理、賬本的分布式計算、賬本的存儲及節(jié)點間的P2P協(xié)議功能的實現(xiàn)，是區(qū)塊鏈的核心組成部分，為區(qū)塊鏈的主體功能提供了底層技術(shù)支撐
（3）鏈碼服務(wù)
鏈碼服務(wù)為智能合約實現(xiàn)提供了一系列接口，并為鏈碼的安裝、運行、部署提供了環(huán)境。智能合約的實現(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）模塊，實現(xiàn)密鑰生成、哈希運算、簽名驗簽、加密解密等基礎(chǔ)功能。
Hyperledger Fabric采用模塊化架構(gòu)設(shè)計，利用通用的功能模塊和接口。模塊化的方法帶來了可擴展性、靈活性等優(yōu)勢，會減少模塊修改、升級帶來的影響，能很好的利用微服務(wù)實現(xiàn)區(qū)塊鏈應(yīng)用系統(tǒng)的開發(fā)和部署。
（1）模塊插件化
Fabric很多功能模塊（如CA模塊、共識算法、狀態(tài)數(shù)據(jù)庫存儲、ESCC、VSCC、BCCSP等）都是可插拔的。Fabric提供的通用接口和默認實現(xiàn)可以滿足大多數(shù)的業(yè)務(wù)需求，同時功能模塊也可以根據(jù)需求進行擴展，集成到Fabric區(qū)塊鏈網(wǎng)絡(luò)系統(tǒng)中。
（2）充分利用容器技術(shù)
Fabric中不僅節(jié)點使用容器作為運行環(huán)境，鏈碼也默認運行在安全的容器中。應(yīng)用程序或者外部系統(tǒng)不能直接操作鏈碼，必須通過背書節(jié)點提供的接口轉(zhuǎn)發(fā)給鏈碼來執(zhí)行。容器給鏈碼運行提供安全沙箱環(huán)境，把鏈碼的環(huán)境和背書節(jié)點的環(huán)境隔離開，鏈碼存在安全問題也不會影響到背書節(jié)點。
（3）可擴展性
Hyperledger Fabric1.x版本對節(jié)點的角色進行了不同的拆分，有主節(jié)點(Leader)、背書節(jié)點(Endorser)、記賬節(jié)點(Committer)、排序服務(wù)節(jié)點(Orderer)等，不同角色的節(jié)點有不同的功能。節(jié)點可以加入不同的通道中，鏈碼可以運行在不同的背書節(jié)點上，可以更好的提升并行執(zhí)行的效率和吞吐量。
（4）安全性
Hyperledger Fabric提供授權(quán)訪問的區(qū)塊鏈網(wǎng)絡(luò)，節(jié)點共同維護成員信息，只有MSP(Member Service Provide)模塊驗證、授權(quán)的終端用戶才能使用區(qū)塊鏈網(wǎng)絡(luò)的功能。多鏈和多通道的設(shè)計容易實現(xiàn)數(shù)據(jù)隔離，也提供了應(yīng)用程序和鏈碼之間的安全通道，實現(xiàn)了隱私保護。
Fabric網(wǎng)絡(luò)是通過組織來劃分的，每個組織內(nèi)都包含承擔不同功能的Peer 節(jié)點，每個Peer節(jié)點又可以擔任多種角色。所有的組織共用一個統(tǒng)一的Orderer排序服務(wù)集群?；贖yperledger Fabric區(qū)塊鏈網(wǎng)絡(luò)的設(shè)計時需要考慮組織之間的業(yè)務(wù)關(guān)系以及內(nèi)部每個模塊之間的聯(lián)系，統(tǒng)一進行規(guī)劃。
Fabric網(wǎng)絡(luò)包含客戶端節(jié)點、CA節(jié)點、Peer節(jié)點、Orderer節(jié)點。
每個組織通常擁有自己的客戶端、Peer節(jié)點和CA節(jié)點，并且可以根據(jù)需要創(chuàng)建一個或多個不同的類型節(jié)點。Orderer節(jié)點不屬于某個組織的實體，屬于組織共同維護的節(jié)點。
客戶端或應(yīng)用程序代表由終端用戶操作的實體，必須連接到某一個Peer節(jié)點或者排序服務(wù)節(jié)點上與區(qū)塊鏈網(wǎng)絡(luò)進行通信。客戶端向背書節(jié)點（Endorser Peer）提交交易提案(Proposal)，當收集到足夠背書后，向排序服務(wù)節(jié)點廣播交易，進行排序，生成區(qū)塊。
客戶端的主要作用是與Fabric區(qū)塊鏈交互，實現(xiàn)對區(qū)塊鏈的操作。區(qū)塊鏈操作分為管理類和鏈碼類的兩種，管理類操作包括啟停節(jié)點和配置網(wǎng)絡(luò)等；鏈碼類操作主要是鏈碼的生命周期管理，如安裝、實例化以及調(diào)用鏈碼。最常用的客戶端是命令行客戶端（CLI），此外是使用Fabric SDK開發(fā)的應(yīng)用客戶端。
CA節(jié)點主要給Fabric網(wǎng)絡(luò)中的成員提供基于數(shù)字證書的身份信息，可以生成或取消成員的×××書（certificate）。CA節(jié)點是Fabric網(wǎng)絡(luò)的證書頒發(fā)節(jié)點(Certificate Authority)，由服務(wù)器(fabric-ca-server)和客戶端(fabric-ca-client)組成。
CA節(jié)點接收客戶端的注冊申請，返回注冊密碼用于登錄，以便獲取×××書。在區(qū)塊鏈網(wǎng)絡(luò)上所有的操作都會驗證用戶的身份。
CA節(jié)點是可選的，也可以用其它成熟的第三方CA頒發(fā)證書。
Fabric區(qū)塊鏈網(wǎng)絡(luò)中的每個組織可以擁有一到多個Peer節(jié)點。每個Peer節(jié)點可以擔任多種角色：Endorser Peer（背書節(jié)點）、Leader Peer（主節(jié)點）、Committer Peer（記賬節(jié)點）、Anchor Peer（錨節(jié)點）。
每個Peer節(jié)點必定是一個記賬節(jié)點，除記賬節(jié)點外，也可以擔任其它一到多種角色，即某個Peer節(jié)點可以同時是記賬節(jié)點和背書節(jié)點，也可以同時是記賬節(jié)點、背書節(jié)點、主節(jié)點，錨節(jié)點。
（1）Endorser Peer（背書節(jié)點）
部分Peer節(jié)點會執(zhí)行交易并對結(jié)果進行簽名背書，充當背書節(jié)點的角色 。
背書(Endorsement)是指特定Peer節(jié)點執(zhí)行交易并向生成交易提案( proposal )的客戶端應(yīng)用程序返回YES/NO響應(yīng)的過程。
背書節(jié)點是動態(tài)的角色，是與具體鏈碼綁定的。每個鏈碼在實例化的時候都會設(shè)置背書策略(Endorsement policy)，指定哪些節(jié)點對交易背書才有效。
也只有在應(yīng)用程序向節(jié)點發(fā)起交易背書請求時才成為背書節(jié)點，其它時候是普通的記賬節(jié)點，只負責驗證交易并記賬。
（2）Leader Peer（主節(jié)點）
主節(jié)點負責和Orderer排序服務(wù)節(jié)點通信，從排序服務(wù)節(jié)點處獲取最新的區(qū)塊并在組織內(nèi)部同步?？梢詮娭圃O(shè)置，也可以選舉產(chǎn)生。
（3）Committer Peer（記賬節(jié)點）
負責驗證從排序服務(wù)節(jié)點接收的區(qū)塊里的交易，然后將區(qū)塊提交（寫入/追加）到其通道賬本的副本。記賬節(jié)點還將每個塊中的每個交易標記為有效或無效。
（4）Anchor Peer（錨節(jié)點）
在一個通道上可以被所有其它Peer節(jié)點發(fā)現(xiàn)的Peer節(jié)點，通道上的每個成員都有一個Anchor Peer(或多個Anchor Peer來防止單點故障)，允許屬于不同成員的Peer節(jié)點發(fā)現(xiàn)通道上的所有現(xiàn)有Peer節(jié)點。
排序服務(wù)節(jié)點接收包含背書簽名的交易，對未打包的交易進行排序生成區(qū)塊，廣播給Peer節(jié)點。
排序服務(wù)提供的是原子廣播，保證同一個鏈上的節(jié)點為接收到相同的消息，并且有相同的邏輯順序。
排序服務(wù)獨立于Peer進程存在并且以先來先服務(wù)的方式對Fabric網(wǎng)絡(luò)上的所有通道進行排序交易。排序服務(wù)旨在支持超出現(xiàn)有的SOLO和Kafka的可插拔實現(xiàn)。排序服務(wù)是整個網(wǎng)絡(luò)的公共綁定，包含綁定到每個成員的加密身份材料。
排序服務(wù)節(jié)點按照一定規(guī)則確定交易順序后，發(fā)給各個記賬節(jié)點，把交易持久化到區(qū)塊鏈的賬本中。排序服務(wù)節(jié)點支持互相隔離的多個通道，使得交易只發(fā)送給相關(guān)的記賬節(jié)點（Peer節(jié)點）。
商業(yè)應(yīng)用的一個重要的需求是私密×××易，為此Fabric設(shè)計了通道（Channel）來提供成員之間的隱私保護。通道是部分網(wǎng)絡(luò)成員之間擁有獨立的通信渠道，在通道中發(fā)送的交易只有屬于通道的成員才可見，因此通道可以看作是Fabric的網(wǎng)絡(luò)中部分成員的私有通信子網(wǎng)。
通道由排序服務(wù)管理。在創(chuàng)建通道的時候，需要定義通道的成員和組織、錨節(jié)點（anchor peer）和排序服務(wù)節(jié)點，一條與通道對應(yīng)的區(qū)塊鏈會同時生成，用于記錄賬本的交易，通道的初始配置信息記錄在區(qū)塊鏈的創(chuàng)世區(qū)塊中，可以通過增加一個新的配置區(qū)塊來更改通道的配置信息。
每個組織可以有多個節(jié)點加入同一個通道，組織內(nèi)的節(jié)點中可以指定一個錨節(jié)點或多個錨節(jié)點（增強系統(tǒng)可靠性，避免單點故障）。組織的錨節(jié)點代表本組織與其它組織的節(jié)點交互，從而發(fā)現(xiàn)通道中的所有節(jié)點。另外，同一組織的節(jié)點會選舉或指定主導節(jié)點（leading peer），主導節(jié)點負責接收從排序服務(wù)發(fā)來的區(qū)塊，然后轉(zhuǎn)發(fā)給本組織的其它節(jié)點。主導節(jié)點可以通過特定的算法選出，可以保證在節(jié)點數(shù)量不斷變動的情況下仍能維持整個網(wǎng)絡(luò)的穩(wěn)定性。
在Fabric網(wǎng)絡(luò)中，可能同時存在多條彼此隔離的通道，每條通道包含一條私有的區(qū)塊鏈和一個私有賬本，通道中可以實例化一個或多個鏈碼，以操作區(qū)塊鏈上的數(shù)據(jù)。
Fabric 1.x版本支持多鏈和多通道。Fabric的一條區(qū)塊鏈是包含Peer節(jié)點、賬本、排序服務(wù)的邏輯結(jié)構(gòu)，將參與者與數(shù)據(jù)（包含鏈碼）進行隔離，滿足不同業(yè)務(wù)場景下的不同的人訪問不同數(shù)據(jù)的基本要求。
通道是共識服務(wù)提供的一種通訊機制，基于發(fā)布-訂閱關(guān)系，將Peer節(jié)點和排序節(jié)點根據(jù)某個Topic連接在一起，形成一個具有保密性的通訊鏈路（虛擬），實現(xiàn)業(yè)務(wù)隔離的要求。
排序服務(wù)提供了供Peer節(jié)點訂閱的主題（如發(fā)布-訂閱消息隊列），每個主題是一個通道。Peer節(jié)點可以訂閱多個通道，并且只能訪問自己所訂閱通道上的交易，因此一個Peer節(jié)點可以通過接入多個通道參與到多條鏈中。
目前通道分為系統(tǒng)通道（System Channel）和應(yīng)用通道（Application Channel）。排序服務(wù)通過系統(tǒng)通道來管理應(yīng)用通道，用戶的交易信息通過應(yīng)用通道傳遞。
通道由排序服務(wù)節(jié)點負責管理，同時排序服務(wù)節(jié)點還負責對通道中的交易進行排序。在通道中一般包含有若干成員（組織），若兩個網(wǎng)絡(luò)實體的×××書能夠追溯到同一個根CA，則認為這兩個實體屬于同一組織。此外，通道中的每個組織都會有一個或以上的錨節(jié)點，錨節(jié)點負責與其它組織交換共享賬本的數(shù)據(jù)。
創(chuàng)建通道的時候定義了成員，只有通過成員MSP驗證的實體，才能夠加入到通道并訪問通道的數(shù)據(jù)。
排序服務(wù)支持多通道，提供了通向客戶端和Peer節(jié)點的共享通信通道，提供了包含交易的消息廣播服務(wù)（broadcast和deliver）?？蛻舳丝梢酝ㄟ^通道向連接到通道的所有節(jié)點廣播（broadcast）消息，向連接到通道的所有節(jié)點投遞(deliver)消息。多通道使得Peer節(jié)點可以基于應(yīng)用訪問控制策略來訂閱任意數(shù)量的通道，應(yīng)用程序根據(jù)業(yè)務(wù)邏輯決定將交易發(fā)送到1個或多個通道。
共識服務(wù)與（P1、PN）、（P1、P2、PN）、（P2、PN）組成三個相互獨立的通道，加入到不同通道的Peer節(jié)點能夠維護各個通道對應(yīng)的賬本和狀態(tài)。不同通道對應(yīng)現(xiàn)實世界中不同業(yè)務(wù)場景下的參與方，如銀行、保險公司、物流企業(yè)、生產(chǎn)企業(yè)等實體結(jié)構(gòu)。
通道的配置信息都被打包到一個區(qū)塊中，并存放在通道的共享賬本中，成為通道的配置區(qū)塊，配置區(qū)塊除了配置信息外不包含其它交易信息。通道可以使用配置區(qū)塊來更新配置，因此在賬本中每新添加一個配置區(qū)塊，通道就按照最新配置區(qū)塊的定義來修改配置。通道賬本的首個區(qū)塊一定是配置區(qū)塊，也稱為創(chuàng)世區(qū)塊（Genesis Block）。
通道的CLI客戶端可以使用命令對通道進行管理。
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é)點的地址。
在通道創(chuàng)建后，通道相關(guān)的配置以區(qū)塊的形式存在于通道的賬本中。如果需要修改通道的配置，可通過生成新的配置區(qū)塊去更新。修改通道配置的步驟如下：
A、通過SDK或CLI獲得最新的配置區(qū)塊。
B、編輯配置區(qū)塊。
C、計算配置更新量。
D、為配置區(qū)塊添加配置更新量。
E、SDK或CLI簽名并發(fā)送配置區(qū)塊。
若新的配置區(qū)塊通過驗證，則通道配置以最新配置區(qū)塊為準。
Fabric區(qū)塊鏈的交易分兩種，部署交易和調(diào)用交易。
部署交易把鏈碼部署到Peer節(jié)點上并準備好被調(diào)用，當一個部署交易成功執(zhí)行時，鏈碼就被部署到各個背書節(jié)點上。
調(diào)用交易是客戶端應(yīng)用程序通過Fabric提供的API調(diào)用先前已部署好的某個鏈碼的某個函數(shù)執(zhí)行交易，并相應(yīng)地讀取和寫入KV數(shù)據(jù)庫，返回是否成功或者失敗。
Fabric v1.0的交易流程如下：
區(qū)塊鏈的賬本由Peer節(jié)點維護，并不是由排序服務(wù)集群維護，所以，只有Peer節(jié)點（背書節(jié)點和確認節(jié)點）包含完整的區(qū)塊鏈信息，而排序服務(wù)集群只負責對交易進行排序，只保留處理過程中的一部分區(qū)塊鏈信息。Hyperledger Fabric網(wǎng)絡(luò)中的節(jié)點是一個邏輯的概念，并不一定是一個臺物理設(shè)備，但對于生產(chǎn)環(huán)境，為了系統(tǒng)架構(gòu)的解耦，提高擴展性以及通過主機隔離提高安全性，Peer節(jié)點不能和排序服務(wù)節(jié)點部署在一臺機器上，而背書節(jié)點和確認節(jié)點可以部署在同一臺機器上。背書節(jié)點校驗客戶端的簽名，然后執(zhí)行智能合約代碼模擬交易。交易處理完成后，對交易信息簽名，返回給客戶端?？蛻舳耸盏胶灻蟮慕灰仔畔⒑?，發(fā)給排序服務(wù)節(jié)點排序。排序服務(wù)節(jié)點將交易信息排序打包成區(qū)塊后，廣播發(fā)給確認節(jié)點，寫入?yún)^(qū)塊鏈中。
客戶端應(yīng)用程序利用SDK（Node.js，Java，Python）構(gòu)造交易提案（Proposal）。交易提案是一個調(diào)用智能合約功能函數(shù)的請求，用來確認哪些數(shù)據(jù)可以讀取或?qū)懭胭~本。
客戶端把交易提案發(fā)送給一個或多個背書節(jié)點，交易提案中包含本次交易要調(diào)用的合約標識、合約方法和參數(shù)信息以及客戶端簽名等。
SDK將交易提案打包為可識別的格式（如gRPC上的protobuf），并使用用戶的加密憑證為該交易提案生成唯一的簽名。
背書節(jié)點（endorser）收到交易提案后，驗證簽名并確定提交者是否有權(quán)執(zhí)行操作。背書節(jié)點將交易提案的參數(shù)作為輸入，在當前狀態(tài)KV數(shù)據(jù)庫上執(zhí)行交易，生成包含執(zhí)行返回值、讀操作集和寫操作集的交易結(jié)果（此時不會更新賬本），交易結(jié)果集、背書節(jié)點的簽名和背書結(jié)果（YES/NO）作為提案的結(jié)果返回給客戶端SDK，SDK解析信息判斷是否應(yīng)用于后續(xù)的交易。
客戶端應(yīng)用程序（SDK）驗證背書節(jié)點簽名，并比較各節(jié)點返回的提案結(jié)果，判斷提案結(jié)果是否一致以及是否參照指定的背書策略執(zhí)行。
客戶端收到各個背書節(jié)點的應(yīng)答后，打包到一起組成一個交易并簽名，發(fā)送給排序服務(wù)節(jié)點。
排序服務(wù)節(jié)點對接收到的交易進行共識排序，然后按照區(qū)塊生成策略，將一批交易打包到一起，生成新的區(qū)塊，調(diào)用deliver API投遞消息，發(fā)送給確認節(jié)點。
確認節(jié)點收到區(qū)塊后，會對區(qū)塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區(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ù)項以鍵值對的形式存放，賬本中所有的鍵值對構(gòu)成了賬本的狀態(tài)，稱為世界狀態(tài)（World State）。
每個通道中有唯一的賬本，通道的賬本由通道中所有成員共同維護，每個記賬節(jié)點上都保存所屬通道的賬本的一個副本，因而是分布式賬本。對賬本的訪問需要通過鏈碼實現(xiàn)對賬本鍵值對的增加、刪除、更新和查詢等操作。
賬本由區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫兩部分組成。
區(qū)塊鏈是一組不可更改的有序的區(qū)塊（數(shù)據(jù)塊），記錄著全部交易的日志。每個區(qū)塊中包含若干個交易的數(shù)據(jù)，不同區(qū)塊所包含的交易數(shù)量可以不同。區(qū)塊之間用哈希鏈（Hashed-link）關(guān)聯(lián)：每個區(qū)塊頭包含本區(qū)塊所有交易的哈希值，以及上一個區(qū)塊頭的哈希值。鏈式結(jié)構(gòu)可以確保每個區(qū)塊的數(shù)據(jù)不可更改，以及每個區(qū)塊之間的順序關(guān)系不可更改。因此，區(qū)塊鏈的區(qū)塊只可以添加在鏈的尾部。
狀態(tài)數(shù)據(jù)庫記錄了賬本中所有鍵值對的當前值，相當于對當前賬本的交易日志做了索引。鏈碼執(zhí)行交易的時候需要讀取賬本的當前狀態(tài)，從狀態(tài)數(shù)據(jù)庫可以迅速獲取鍵值的最新狀態(tài)。
如果沒有狀態(tài)數(shù)據(jù)庫，要獲得某個鍵值時，需要遍歷整個區(qū)塊鏈中和該鍵值相關(guān)的交易，效率非常低，因此，讀取狀態(tài)數(shù)據(jù)庫可以認為是快速定位和訪問某個鍵值的方法。另外，當狀態(tài)數(shù)據(jù)庫出現(xiàn)故障的時候，可以通過遍歷賬本重新生成。
當一個區(qū)塊附加到區(qū)塊鏈尾部的時候，如果區(qū)塊中的有效交易修改了鍵值對，則會在狀態(tài)數(shù)據(jù)庫中作相應(yīng)的更新，確保區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫始終保持一致。
區(qū)塊鏈的數(shù)據(jù)塊以文件形式保存在各個節(jié)點中。狀態(tài)數(shù)據(jù)庫可以是各種鍵值數(shù)據(jù)庫，F(xiàn)abric缺省使用LevelDB ，同時支持CouchDB選項。CouchDB除了支持鍵值數(shù)據(jù)外，也支持JSON格式的文檔模型，能夠做復雜的查詢。
Fabric聯(lián)盟鏈的開發(fā)人員主要分為三類：底層開發(fā)者負責系統(tǒng)部署與維護；組織管理者負責證書、MSP權(quán)限管理、共識機制等；業(yè)務(wù)開發(fā)者負責編寫鏈碼、創(chuàng)建維護通道、執(zhí)行交易等。
Fabric區(qū)塊鏈開發(fā)流程主要包括智能合約編寫，通過SDK調(diào)用智能合約，訂閱各類事件。
開發(fā)者創(chuàng)建客戶端應(yīng)用和鏈碼，鏈碼被部署到區(qū)塊鏈網(wǎng)絡(luò)的背書節(jié)點上。通過鏈碼來操作賬本，當客戶端調(diào)用一個交易時，實際上是在調(diào)用鏈碼中的一個實現(xiàn)業(yè)務(wù)邏輯的函數(shù)方法，并對賬本進行g(shù)et, put, delete操作?？蛻舳藨?yīng)用提供用戶交互界面，并提交交易到區(qū)塊鏈網(wǎng)絡(luò)上。
看完上述內(nèi)容，你們對如何理解HyperLeger Fabric架構(gòu)有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
