可信區(qū)塊鏈聯(lián)盟鏈平臺架構(gòu)由上層應用由桌面客戶端,、移動客戶端,、瀏覽器客戶API組成。用戶主要由API 將業(yè)務數(shù)據(jù)接入到系統(tǒng),。該平臺架構(gòu)底層是基于Hyperledger Fabric V1.0.0架構(gòu)構(gòu)建的,。該底層架構(gòu)主要由接入網(wǎng)關(guān)、區(qū)塊鏈應用兩大部分功能組成,，接入網(wǎng)關(guān)包含了注冊,、認證、授權(quán),、監(jiān)控,、審計五大功能,，區(qū)塊鏈應用則主要由鏈上程序、區(qū)塊鏈管理,、可撥插共識模塊三大模塊組成,。可信區(qū)塊鏈聯(lián)盟鏈平臺架構(gòu)如圖所示,。
鏈上程序主要包括智能合約,、圖靈完備高級語言、合約容器/虛擬機,。Hyperledger Fabric的智能合約smart contract稱為鏈碼chaincode,，是一段代碼，它處理網(wǎng)絡成員所同意的業(yè)務邏輯,。和以太坊相比,，Hyperledger Fabric鏈碼和底層賬本是分開的，升級鏈碼時并不需要遷移賬本數(shù)據(jù)到新鏈碼當中,，真正實現(xiàn)了邏輯與數(shù)據(jù)的分離,。鏈碼可采用Go,、Java,、Node.js語言編寫。鏈碼被編譯成一個獨立的應用程序,，fabric用Docker容器來運行chaincode,，里面的base鏡像都是經(jīng)過簽名驗證的安全鏡像，包括OS層和開發(fā)chaincode的語言,、runtime和SDK層,。一旦chaincode容器被啟動，它就會通過gRPC與啟動這個chaincode的Peer節(jié)點連接,。
區(qū)塊鏈管理主要包括賬戶管理,、區(qū)塊鏈管理、區(qū)塊校驗,、交易校驗,。Hyperledger Fabric是目前為止在設計上最貼近聯(lián)盟鏈思想的區(qū)塊鏈。聯(lián)盟鏈考慮到商業(yè)應用對安全,、隱私,、監(jiān)管、審計,、性能的需求,，提高準入門檻，成員必須被許可才能加入網(wǎng)絡,。Fabric成員管理服務為整個區(qū)塊鏈網(wǎng)絡提供身份管理,、隱私,、保密和可審計的服務。成員管理服務通過公鑰基礎設施PKI和去中心化共識機制使得非許可的區(qū)塊鏈變成許可制的區(qū)塊鏈,?？蓳懿骞沧R模塊，Hyperledger Fabric使用建立在HTTP/2上的P2P協(xié)議來管理分布式賬本,。采取可插拔的方式來根據(jù)具體需求來設置共識協(xié)議,，比如PBFT，Raft,，PoW和PoS等,。
1. 超級賬本聯(lián)盟鏈區(qū)塊鏈網(wǎng)絡的創(chuàng)建
超級賬本聯(lián)盟鏈區(qū)塊鏈網(wǎng)絡的創(chuàng)建主要包括客戶端節(jié)點創(chuàng)建、Peer節(jié)點創(chuàng)建,、排序服務節(jié)點創(chuàng)建及CA證書節(jié)點創(chuàng)建,。
客戶端節(jié)點的創(chuàng)建：客戶端是用戶和應用跟區(qū)塊鏈網(wǎng)絡打交道的橋梁?？蛻舳酥饕▋纱舐毮埽?
1）操作Fabric網(wǎng)絡：包括更新網(wǎng)絡配置,、啟停節(jié)點等；
2）操作運行在網(wǎng)絡中的鏈碼：包括安裝,、實例化,、發(fā)起交易調(diào)用鏈碼等。
Peer節(jié)點的創(chuàng)建：Peer意味著在網(wǎng)絡中負責接受交易請求,、維護一致賬本的各個fabric-peer實例,。這些實例可能運行在裸機、虛擬機甚至容器中,。節(jié)點之間彼此通過gRPC消息進行通信,。按照功能角色劃分，Peer可以包括三種類型：
1）Endorser（背書節(jié)點）：負責對來自客戶端的交易提案進行檢查和背書,；
2）Committer（確認節(jié)點）：負責檢查交易請求,，執(zhí)行交易并維護區(qū)塊鏈和賬本結(jié) 構(gòu)；
3）Submitter（提交節(jié)點）：負責接收交易,，轉(zhuǎn)發(fā)給排序者,，目前未單獨出現(xiàn)。
排序服務節(jié)點的創(chuàng)建：負責對所收到的交易在網(wǎng)絡中進行全局排序,。Orderer主要提供了Broadcast（srv ab.AtomicBroadcast_BroadcastServer） error和Deliver（srvab.AtomicBroadcast_DeliverServer） error兩個接口,。前者代表客戶端將數(shù)據(jù)（交易）發(fā)給Orderer，后者代表從Orderer獲取到排序后構(gòu)造的區(qū)塊結(jié)構(gòu),?？蛻舳丝梢允褂胊tomicBroadcastClient結(jié)構(gòu)訪問這兩個接口。
CA證書節(jié)點的創(chuàng)建：負責網(wǎng)絡中所有證書的管理（分發(fā)、撤銷等）,，實現(xiàn)標準的PKI架構(gòu),。主要代碼在單獨的fabric-ca項目中。CA在簽發(fā)證書后,，自身不參與到網(wǎng)絡中的交易過程,。
2. 身份管理功能
在Gossip網(wǎng)絡中，每個節(jié)點都有超級賬本網(wǎng)絡認可的MSP（Membership Service Provider）頒發(fā)的證書（身份,，Indentity）,，從證書計算哈希值導出（目前的實現(xiàn)是直接用Endpoint轉(zhuǎn)換而來的）的一個標識符稱為節(jié)點的PKI-ID。
超級賬本的Peer節(jié)點組成了一個P2P的網(wǎng)絡,，客戶端SDK(Go,、Java、Python,、Node. js等不同語言)會提交請求給Per節(jié)點,，Peer節(jié)點處理后會提交交易提案（TransactionProposal）給背書節(jié)點（Endorser），然后進行背書簽名（Endorsement）,，最后經(jīng)過排序服務達成共識后廣播給Peer節(jié)點,。
身份管理模塊管理節(jié)點標識符和證書之前的映射，在內(nèi)部維護了以PKI-ID為鍵,、證書為值的映射表pkiID2Cert,，可以通過PKI?ID獲取節(jié)點的證書，也可以更新節(jié)點的證書,。同時還內(nèi)置了MCS（MessageCryptoService）模塊,，它可以對消息進行簽名和驗證。更新節(jié)點證書的時候也會通過MCS模塊驗證證書是否有效,，檢查從證書導出的標識符是否和PKI-ID匹配。
在生成環(huán)境中,，假設所有節(jié)點都是雙向TLS部署的,，TLS連接的雙方都有一個有效的TLS證書。當節(jié)點和對端節(jié)點第一次連接時,，會有一個握手協(xié)議,，這個協(xié)議驗證它是否擁有TLS證書的私鑰，因而在TLS會話中綁定成員身份,。握手是相互的,，過程比較簡單，握手節(jié)點主動發(fā)送給對端點一條ConnEstablish消息,，包含的內(nèi)容有：
節(jié)點TLS證書的哈希值,。
節(jié)點的PKI-ID。
MSP身份證書,。
3. 賬本管理功能
在Fabric中,，賬本（Ledger）是一個有序的,、防篡改的全交易記錄的區(qū)塊哈希鏈，它被ordering service構(gòu)造,，記錄了所有的成功和不成功的狀態(tài)更新交易,。在1.0的版本中每個信道（channel）在orderer上都存儲了一個獨立的賬本，信道中的每個參與節(jié)點（peer）都存儲了一份該賬本的拷貝,。同時賬本提供了SQL形式的查詢功能,，以便進行高效的對賬和爭議解決。
因為賬本是建立在信道的基礎上,，并通過鏈碼（chaincode）對其進行操作或修改,，這就產(chǎn)生了兩種方式：第一種是賬本可以在整個網(wǎng)絡中共享（可以理解為整個網(wǎng)絡是一個特殊的公共信道），第二種是賬本可以私有化,，只包括一組特定的參與者,。在后一種方式中，這些參與者將創(chuàng)建一個單獨的信道,，從而分離其交易事務（transactions）和賬本,。為了解決透明度和隱私的沖突，鏈碼只會被安裝在擁有讀寫權(quán)限的參與節(jié)點上,，換句話說如果沒有合適的鏈碼支持,，參與節(jié)點將無法與賬本進行正確數(shù)據(jù)的對接。更進一步在混淆數(shù)據(jù),，鏈碼中操作的鍵值可以在被追加到賬本之前使用像AES這樣的算法進行全部或選擇性的加密,。
4. 交易管理
區(qū)塊鏈客戶端把交易請求發(fā)給之前約定好的所有背書節(jié)點（endorsing peer）。這里說明一下endorsing peer的選擇是有一定范圍的,，并不是在所有的endorsing peer里隨意選擇,，是由交易所屬的ChainCode和該Chaincode所定義的Endorsement Policy共同決定的。
背書節(jié)點收到上述信息后,，首先用Client的公鑰驗證它的簽名,，背書節(jié)點執(zhí)行智能合約（是模擬交易，不會寫到賬本里）,，將執(zhí)行的結(jié)果反饋給客戶端,。
客戶端搜集“足夠”多的背書節(jié)點的結(jié)果后，就說明這個交易通過了Endorsement階段,。通過之后就打包發(fā)給共識節(jié)點（orderers）。其中“足夠”的數(shù)量是多少,，取決于背書策略Endorsement Policy是如果規(guī)定的,，相反如果Client沒有搜集到足夠多的信息的話，這個交易就會被廢止掉。Client可以選擇重新發(fā)起交易,。
共識階段雖然有不同的算法,，不過目的都是把有效的交易加入新生成的區(qū)塊,，并通知所有節(jié)點使他們賬本保存一致,。共識節(jié)點將結(jié)果廣播所有的節(jié)點（peer）。然后各節(jié)點再更新自己賬本,。
5. 鏈碼生命周期管理
鏈碼提供了4個管理鏈碼生命周期的命令,，分別是鏈碼的打包、安裝,、實例化,、升級。在以后的版本中,，還可能提供鏈碼的停止和啟動命令,，在不刪除鏈碼的情況下可以停止和啟動鏈碼,。鏈碼在安裝和實例化以后,，就處于激活的狀態(tài)，應用程序或者命令就可以調(diào)用和觸發(fā)智能合約的功能了,。鏈碼安裝以后隨時都是可以升級的,。
鏈碼的打包
鏈碼的內(nèi)容主要包括以下3個部分：
1）鏈碼源碼，但需要通過ChaincodeDeploymentSpec或CDS定義,。CDS依據(jù)代碼及其 他一些屬性來定義鏈碼。
2）實例化策略,。
3）鏈碼的簽名,。
鏈碼的安裝
鏈碼安裝的時候會把鏈碼的源碼到前面已經(jīng)介紹過的結(jié)構(gòu)Chaincode DeploymentSpec中，安裝到需要運行鏈碼的Peer節(jié)點上,。鏈碼安裝是針對節(jié)點的,，每次安裝只對單個節(jié)點有效。需要給每個要運行鏈碼的背書節(jié)點都安裝一遍,，具體需要安裝到哪些節(jié)點，可以根據(jù)背書策略來選擇,。
從安全角度考慮,，鏈碼應該只需要安裝在需要執(zhí)行的背書節(jié)點上，可以保護鏈碼的邏輯被未授權(quán)的節(jié)點獲取到,。沒有安裝鏈碼的節(jié)點是不能執(zhí)行鏈碼的智能合約的,，但是可以驗證鏈上的交易并且提交到本地賬戶中。
鏈碼的實例化
鏈碼的實例化會調(diào)用鏈碼生命周期系統(tǒng)鏈碼（LSCC）在通道上創(chuàng)建和初始化鏈碼。鏈碼在實例化之前是和通道無關(guān)的,，實例化的時候才和通道綁定,。鏈碼可以和多個通道綁定，在通道上初始化后記錄到通道的狀態(tài)數(shù)據(jù)庫中,。同一個鏈碼在不同通道上的數(shù)據(jù)是隔離的,。
鏈碼實例化的時候會檢查是否符合鏈碼實例化的策略和通道的寫入策略。實例化的策略驗證過程是檢查實例化交易的簽名是否符合策略的規(guī)則,，驗證通過才會寫入到賬本和狀態(tài)數(shù)據(jù)中,。通道的寫入策略是在創(chuàng)建通道時指定的，這也是從安全角度考慮的,，避免未授權(quán)的用戶部署鏈碼和調(diào)用鏈碼,。默認的實例化策略是通道的任何一個管理員，所以鏈碼的實例化交易提交者必須也是通道的管理員鏈碼的實例化會指定鏈碼的背書策略,，用來確定通道上哪些節(jié)點執(zhí)行的交易才能添加到賬本中,。
鏈碼的升級
鏈碼安裝以后是隨時于可以升級的，鏈碼的名稱需要保持不變,，必須要更新的是鏈碼的版本,，其他的部分，比如鏈碼的所有者和實例化策略都是可選的,。鏈碼的版本是用字符串表示的,，并沒有指定比較版本大小的規(guī)則，是以更新的先后順序為準的,，具體的操作方法線下自行確定,。
同樣，升級之前還需要把鏈碼安裝到對應的背書節(jié)點上,。鏈碼的升級和實例化是類似的操作,，也是綁定鏈碼到通道上，執(zhí)行初始化的操作,。鏈碼升級只會影響到指定的通道沒有綁定鏈碼新版本的通道還是繼續(xù)舊的版本,。同一個背書節(jié)點上，不同通道綁定的鏈碼可能是不同的版本,，所以升級的時候不會主動刪除舊的版本,。
鏈碼升級的時候同樣會檢查實例化策略，采用的是通道上鏈碼最新版本的實例化策略檢查通過以后才會更新為鏈碼新版本指定的實例化策略,。
鏈碼的停止和啟動
鏈碼的停止與啟動功能還沒實現(xiàn),，只能手動刪除鏈碼的容器和鏡像，再刪除背書節(jié)點本地保存的鏈碼,。
6. 通道的管理
Hyperledger Fabric 通道是兩個或多個特定網(wǎng)絡成員之間的通信的私有“子網(wǎng)”,，用于進行需要數(shù)據(jù)保密的交易,。channel由成員（組織）、每個成員的錨點,、共享賬本,，鏈碼應用程序和order服務節(jié)點定義。網(wǎng)絡上的每個transaction都在一個channel上執(zhí)行,，每個通信方必須經(jīng)過身份驗證并授權(quán)在該channel上進行交易,。加入channel的每個peer都具有由成員服務提供商（MSP）給出的自己的身份。
要創(chuàng)建新的channel,，客戶端SDK會調(diào)用configuration system chaincode和引用屬性,，如錨點和成員（組織）。該請求為channel ledger創(chuàng)建一個genesis block,，它存儲有關(guān)channel策略,，成員和錨點的配置信息。當將新成員添加到現(xiàn)有channel時,，這個genesis block或最近被重新配置的塊將會分享給新成員,。
channel中每個成員的leading peer的選舉決定了哪個peer代表成員與ordering service進行通信。如果沒有指定leader,，則可以使用算法來指定leader,。共識服務將交易排序并以一個block的形式發(fā)送給一個leader，然后leader將其分發(fā)給其成員 peer,，并用gossip 協(xié)議進行跨channel通信,。
雖然任何一個錨點可以屬于多個信道，并且因此維護多個賬本,，但沒有賬本數(shù)據(jù)可以從一個channel傳遞到另一個channel,。ledger按channel分隔，由configuration chaincode,，identity membership service和gossip數(shù)據(jù)傳播協(xié)議來定義和實現(xiàn),。被隔離的數(shù)據(jù)包括交易信息，賬本狀態(tài)和channel成員資料,，這些數(shù)據(jù)僅限于在channel上具有可驗證成員資格的peer間傳播,。通過信道隔離peer和賬本數(shù)據(jù)，允許需要私有和機密事務的網(wǎng)絡成員與同一個塊鏈網(wǎng)絡上的業(yè)務競爭對手和其他受限制的成員共存,。
7. Docker管理鏈碼
鏈碼運行在與承認對等體進程隔離的安全Docker容器中,。Chaincode通過應用程序提交的交易來初始化和管理分類帳狀態(tài)。鏈碼通常處理網(wǎng)絡成員所同意的業(yè)務邏輯,，因此可被視為“智能合同”,。 由鏈碼創(chuàng)建的狀態(tài)僅限于該鏈碼，不能被另一個鏈碼直接訪問,。 然而,，在同一個網(wǎng)絡中，給定適當?shù)臋?quán)限,，鏈碼可以調(diào)用另一個鏈碼來訪問其狀態(tài),。Docker管理鏈碼，確保智能合約的安全執(zhí)行環(huán)境,，同時也確保安全的執(zhí)行過程與用戶數(shù)據(jù)的隔離,。Docker提供了安全的沙箱環(huán)境和鏡像文件倉庫。
8. 超級賬本聯(lián)盟鏈共識服務
超級賬本中把共識分為交易背書,、交易排序和交易驗證3個階段,。
1）交易背書
應用程序根據(jù)背書策略的要求選擇背書節(jié)點，給這些節(jié)點發(fā)送需要執(zhí)行的交易提案（Proposal）,。背書節(jié)點調(diào)用鏈碼（Chaincode）執(zhí)行這些交易提案,交易過程是執(zhí)行是模擬執(zhí)行的,，并不真正提交數(shù)據(jù)到賬本中。執(zhí)行完成以后調(diào)用交易背書系統(tǒng)鏈碼ESCC對模擬執(zhí)行結(jié)果進行簽名背書,。
2）交易排序
排序階段接受已經(jīng)簽名背書的交易,，確定交易的順序和數(shù)量，將排好序的交易打包到區(qū)塊中,，廣播給Peer節(jié)點進行驗證,。通常，從效率方面考慮,，排序服務不會輸出單個交易作為一個區(qū)塊,，而是把多個交易打包成一個區(qū)塊。
3）交易驗證
Peer節(jié)點驗證接收到區(qū)塊里包含的交易的有效性,，包括背書策略驗證及雙花檢測（double-spending）,。可以將驗證錯誤分為兩大類:語法錯誤和邏輯錯誤,。語法錯誤包括無效輸入,、未驗證的簽名以及重復的交易（雙花攻擊），重復的交易應該丟棄,。第二類錯誤比較復雜,，比如會導致雙花或者MVCC失敗的交易，這需要定義策略來決定程序是繼續(xù)執(zhí)行還是終止,。策略還可以定義是否需要記錄日志以便對這類交易進行審計,。交易驗證依賴鏈碼的業(yè)務邏輯，目前默認的交易驗證系統(tǒng)鏈碼ⅤSCC只支持背書策略的驗證,。
9. Kafka的排序服務
基于Kafka的排序服務利用Kafka作為交易的消息隊列,，實現(xiàn)高吞吐量的數(shù)據(jù)分發(fā)每個通道都對應Kafka的一個主題（topic），排序服務節(jié)點在不同階段充當不同的角色,。
1）接收交易階段：排序服務節(jié)點充當?shù)氖荎afka的生產(chǎn)者（producer）,，接收到交易后
通過權(quán)限檢查轉(zhuǎn)發(fā)給對應通道的主題,。
2）消息處理階段：排序服務節(jié)點充當?shù)氖荎afka的消費者（consumer），實時監(jiān)聽消息進行后續(xù)的處理,，生成區(qū)塊或者交易分割消息等,。
10. 超級賬本聯(lián)盟鏈數(shù)據(jù)區(qū)塊的構(gòu)建
聯(lián)盟鏈數(shù)據(jù)區(qū)塊主要包括狀態(tài)數(shù)據(jù)和賬本數(shù)據(jù)兩大模塊，其中賬本數(shù)據(jù)主要包含交易數(shù)據(jù)及構(gòu)建的區(qū)塊信息數(shù)據(jù),。
狀態(tài)（state）
區(qū)塊鏈的最新狀態(tài)被建模為一個版本化的鍵值存儲（KVS）,，鍵是名字，值是任意二進制大對象（blobs）,。這些鍵值對被運行在區(qū)塊鏈上的鏈碼（應用程序）通過put和getKVS操作來操縱,。狀態(tài)被持久化存儲并且狀態(tài)的更新被記錄為日志。請注意狀態(tài)模型采用的是版本化的KVS,，具體實現(xiàn)可以使用實際的KVS存儲,，但是也可以用關(guān)系數(shù)據(jù)庫系統(tǒng)或其他的解決方案。
狀態(tài)由對等點維護,，而不是order節(jié)點和客戶端,。狀態(tài)分區(qū)。KVS中的鍵可以從它們鏈碼的名字識別,，在這個意義上,，只有一個特定鏈碼的交易可以修改屬于這個鏈碼的鍵。原則上,，任何鏈碼都可以讀取屬于其他鏈碼的鍵,。為了支持跨鏈碼交易，修改屬于兩個或更多個鏈碼的狀態(tài)作為一個V1后的功能點,。
賬本
賬本提供一份可驗證歷史信息,，記錄所有在系統(tǒng)操作中發(fā)生的成功的狀態(tài)改變（即有效交易）和未成功的對改變狀態(tài)的嘗試（即無效交易）。賬本由排序服務構(gòu)建為一個完整排序的交易（有效的和無效的）區(qū)塊的哈希鏈,。哈希鏈強制要求賬本中的區(qū)塊是完全排序的并且每個區(qū)塊內(nèi)包含的交易是完全排序的,。
賬本存儲在所有的對等點里，也可以選擇保存在一部分排序者里,。存在排序者節(jié)點內(nèi)的賬本我們叫排序者的賬本（OedererLedger）,，而存在對等點的賬本我們叫對等點賬本（PeerLedger）。對等點賬本與排序者賬本不同之處在于對等點賬本本地維護一個比特掩碼來區(qū)分有效交易和無效交易,。
對等點可以修訂對等點賬本,。排序者維護排序者賬本用于容錯和（對等點賬本的）可用性并可以隨時決定修訂對等點賬本，前提是排序服務的屬性保持不變,。賬本允許對等點重播所有交易的歷史來重構(gòu)狀態(tài),。因此，狀態(tài)是一個可選的數(shù)據(jù)結(jié)構(gòu),。
可信聯(lián)盟區(qū)塊鏈產(chǎn)品系統(tǒng)系統(tǒng)應用領(lǐng)域如圖所示,。
