Fabric基本概念

Fabric (Hyperledger fabric) 是由 IBM 貢獻(xiàn)的超級賬本框架：利用現(xiàn)有成熟的技術(shù)來組合而成的一個(gè)區(qū)塊鏈技術(shù)的實(shí)現(xiàn)，允許可插拔實(shí)現(xiàn)各種功能的的模塊化架構(gòu)。它具有強(qiáng)大的容器技術(shù)，來承載各種主流語言來編寫的智能合約。

Fabric 大致分為底層的網(wǎng)絡(luò)層、權(quán)限管理模塊、區(qū)塊鏈應(yīng)用模塊，通過 SDK 和 CLI 對應(yīng)用開發(fā)者提供服務(wù)，如下面的圖所示。

image

chaincode：鏈碼，Hyperledger Fabric智能合約寫在鏈碼里并在區(qū)塊鏈外部應(yīng)用程序要和賬本發(fā)生交易的時(shí)候被外部應(yīng)用程序調(diào)用。在大多數(shù)情況下，鏈碼只和賬本的數(shù)據(jù)庫組件（世界狀態(tài)）交互，而不和交易日志交互。
賬本Hyperledger Fabric有一個(gè)賬本子系統(tǒng)包含兩個(gè)組件：世界狀態(tài)和交易日志。每一個(gè)參與者有一份他們參與的每個(gè)Hyperledger Fabric網(wǎng)絡(luò)的賬本的副本。世界狀態(tài)組件描述了一個(gè)給定時(shí)間點(diǎn)的賬本狀態(tài)。它是賬本的數(shù)據(jù)庫，存儲(chǔ)的是賬本當(dāng)前值。交易日志組件記錄所有導(dǎo)致世界狀態(tài)當(dāng)前值的交易。它是世界狀態(tài)的更新歷史。這樣，賬本就是世界狀態(tài)數(shù)據(jù)庫和交易日志歷史的組合體。
下面是一個(gè)世界狀態(tài)例圖，記錄的是兩輛車CAR1和CAR2的信息。應(yīng)用程序可以調(diào)用（invoke）智能合約來put和delete狀態(tài)。

image

世界狀態(tài)中有一個(gè)屬性——版本號，版本號從0開始，每當(dāng)狀態(tài)更新時(shí)版本號就遞增。狀態(tài)更新時(shí)會(huì)首先檢查版本號，以確保當(dāng)前狀態(tài)的版本與背書時(shí)的版本一致（避免并發(fā)更新）。

區(qū)塊結(jié)構(gòu)： 由三個(gè)部分組成，分別是區(qū)塊頭、區(qū)塊數(shù)據(jù)和區(qū)塊元數(shù)據(jù)。
1.區(qū)塊頭包含三個(gè)屬性（區(qū)塊號、當(dāng)前區(qū)塊哈希、前一個(gè)區(qū)塊的哈希），當(dāng)一個(gè)區(qū)塊被創(chuàng)建時(shí)寫入。

2.區(qū)塊數(shù)據(jù)包含的是排序后的交易列表。當(dāng)區(qū)塊被ordering service創(chuàng)建時(shí)寫入。

3.區(qū)塊元數(shù)據(jù)包括區(qū)塊的寫入時(shí)間，以及區(qū)塊寫入者的證書、公鑰和簽名。

交易： 在fabric中指的就是對鏈代碼（即智能合約）的操作，交易分為兩種，部署交易（deploy transaction）和調(diào)用交易（invoke transaction）。

1. 部署交易
   部署交易指的是創(chuàng)建新的鏈代碼，并且用一個(gè)程序作為參數(shù)，當(dāng)一個(gè)部署交易成功執(zhí)行時(shí)，鏈代碼就被安裝到區(qū)塊鏈上了。
2. 調(diào)用交易
   調(diào)用交易指的是運(yùn)行鏈代碼，鏈代碼執(zhí)行時(shí)可能會(huì)修改相應(yīng)的狀態(tài)，并返回輸出。
   下圖是一個(gè)交易的詳細(xì)結(jié)構(gòu)：

image

交易頭：包含交易的元數(shù)據(jù)，如鏈碼名稱、版本等
交易簽名：包含由客戶端應(yīng)用程序創(chuàng)建的加密簽名，作用是判斷交易是否被篡改
交易提案：作用是對由應(yīng)用程序提供給智能合約的輸入?yún)?shù)進(jìn)行編碼。當(dāng)智能合約運(yùn)行時(shí)，提案負(fù)責(zé)將參數(shù)傳遞過去
交易響應(yīng)：是智能合約的輸出，包含的是世界狀態(tài)在交易前后的值，以讀寫集的形式展示。

節(jié)點(diǎn): 是區(qū)塊鏈的通信實(shí)體，是一個(gè)邏輯概念，不同類型的多個(gè)節(jié)點(diǎn)可以運(yùn)行在同一個(gè)物理服務(wù)器上。節(jié)點(diǎn)主要有以下四種：

1.客戶端節(jié)點(diǎn)：客戶端必須連接到某一個(gè)peer節(jié)點(diǎn)或排序服務(wù)節(jié)點(diǎn)上才能與區(qū)塊鏈網(wǎng)絡(luò)進(jìn)行通信。客戶端向背書節(jié)點(diǎn)（endorser）提交交易提案（transaction proposal），當(dāng)收集到足夠背書后，向排序服務(wù)節(jié)點(diǎn)廣播交易提案，進(jìn)行排序，生成區(qū)塊。

2.普通節(jié)點(diǎn)peer：peer節(jié)點(diǎn)根據(jù)所承擔(dān)的角色又可以分為記賬節(jié)點(diǎn)（committer）、背書節(jié)點(diǎn)（endorser）、主節(jié)點(diǎn)（leader）和錨節(jié)點(diǎn)（anchor）。

記賬節(jié)點(diǎn)：所有的peer節(jié)點(diǎn)都是記賬節(jié)點(diǎn)（committer），負(fù)責(zé)驗(yàn)證排序服務(wù)節(jié)點(diǎn)區(qū)塊里的交易，維護(hù)狀態(tài)和總賬（Ledger）的副本。該節(jié)點(diǎn)會(huì)定期從orderer節(jié)點(diǎn)獲取包含交易的區(qū)塊，在對這些區(qū)塊進(jìn)行核發(fā)驗(yàn)證之后，會(huì)把這些區(qū)塊加入到區(qū)塊鏈中。committer節(jié)點(diǎn)無法通過配置文件配置，需要在當(dāng)前客戶端或者命令行發(fā)起交易請求的時(shí)候手動(dòng)指定相關(guān)的committer節(jié)點(diǎn)。記賬節(jié)點(diǎn)可以有多個(gè)。

背書節(jié)點(diǎn)：部分節(jié)點(diǎn)還會(huì)執(zhí)行交易并對結(jié)果進(jìn)行簽名背書，充當(dāng)背書節(jié)點(diǎn)（endorser）的角色。背書節(jié)點(diǎn)是動(dòng)態(tài)的角色，是與具體鏈碼綁定的。每個(gè)鏈碼在實(shí)例化的時(shí)候都會(huì)設(shè)置背書策略，指定哪些節(jié)點(diǎn)對交易背書后交易才是有效的。并且只有應(yīng)用程序向它發(fā)起交易背書請求的時(shí)候才是背書節(jié)點(diǎn)，其他時(shí)候都是普通的記賬節(jié)點(diǎn)，只負(fù)責(zé)驗(yàn)證交易并記賬。背書節(jié)點(diǎn)也無法通過配置文件指定，而是由發(fā)起交易請求的客戶端指定。背書節(jié)點(diǎn)可以有多個(gè)。

錨節(jié)點(diǎn)：peer節(jié)點(diǎn)還可以是錨節(jié)點(diǎn)（anchor peer），錨節(jié)點(diǎn)主要負(fù)責(zé)代表組織和其他組織進(jìn)行信息交換。每個(gè)組織都有一個(gè)錨節(jié)點(diǎn)，錨節(jié)點(diǎn)對于組織來說非常重要，如果錨節(jié)點(diǎn)出現(xiàn)問題，當(dāng)前組織就會(huì)與其他組織失去聯(lián)系。錨節(jié)點(diǎn)的配置信息是在configtxgen模塊的配置文件configtx.yaml中配置的。錨節(jié)點(diǎn)只能有一個(gè)。

主節(jié)點(diǎn)：peer節(jié)點(diǎn)還可以是主節(jié)點(diǎn)（leader peer），能與排序服務(wù)節(jié)點(diǎn)通信，負(fù)責(zé)從排序服務(wù)節(jié)點(diǎn)獲取最新的區(qū)塊并在組織內(nèi)部同步。主節(jié)點(diǎn)在整個(gè)組織中只能有一個(gè)。

3.排序服務(wù)節(jié)點(diǎn)orderer：接收包含背書簽名的交易，對未打包的交易進(jìn)行排序生成區(qū)塊，廣播給peer節(jié)點(diǎn)。排序服務(wù)提供的是原子廣播，保證同一個(gè)鏈上的節(jié)點(diǎn)接收到相同的信息，并且有相同的邏輯順序。

4.CA節(jié)點(diǎn)：fabric1.0的證書頒發(fā)機(jī)構(gòu)，由服務(wù)器和客戶端組成。CA節(jié)點(diǎn)接收客戶端的注冊申請，返回注冊密碼用于用戶登錄，以便獲取身份證書。區(qū)塊鏈上的所有操作都需要驗(yàn)證用戶身份。

image

fabric系統(tǒng)邏輯結(jié)構(gòu)圖

org：fabric系統(tǒng)是通過組織來劃分的，每個(gè)組織內(nèi)都有承擔(dān)不同功能的peer節(jié)點(diǎn)，同時(shí)每個(gè)組織都有自己對應(yīng)的fabric-ca服務(wù)器，fabric系統(tǒng)中所有的組織共用一個(gè)orderer集群。fabric中的組織在現(xiàn)實(shí)世界中可以是一個(gè)公司、一個(gè)企業(yè)，或者一個(gè)協(xié)會(huì)。在fabric中，組織是承擔(dān)著數(shù)據(jù)信用責(zé)任的區(qū)塊鏈系統(tǒng)參與方。
在設(shè)計(jì)一個(gè)fabric系統(tǒng)時(shí)，第一步就是要確定系統(tǒng)的參與方，然后從這些參與者中選出組織（生成對應(yīng)的組織編號、域名、證書等），然后再確認(rèn)組織的管理方式。組織的管理方式是指組織在遇到問題時(shí)的協(xié)作方式（如新組織的加入）。

channel：fabric的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)被設(shè)計(jì)成多賬本體系，每個(gè)賬本在fabric中被稱為channel。每個(gè)channel中都有一個(gè)完全獨(dú)立的賬本。同一個(gè)channel中的所有peer節(jié)點(diǎn)都保存一份相同的數(shù)據(jù)。
通道由成員（組織）、每個(gè)成員的錨節(jié)點(diǎn)、賬本、鏈碼應(yīng)用程序和排序服務(wù)節(jié)點(diǎn)定義。網(wǎng)絡(luò)上的每個(gè)交易都是在一個(gè)通道上執(zhí)行的，在該通道上，每一方都必須經(jīng)過身份驗(yàn)證和授權(quán)才能在該通道上進(jìn)行交易。加入通道的每一個(gè)peer都有其自己的身份，由成員服務(wù)提供者（MSP）提供。
[圖片上傳失敗...(image-75d5dc-1557391569944)]

MSP：Membership Service Provider，負(fù)責(zé)聯(lián)盟鏈成員的證書管理，它定義了哪些RCA以及ICA在鏈里是可信任的，包括定義了channel上的合作者。
每個(gè)組織都有自己的證書管理即CA, 及MSP, CA給每個(gè)peer頒發(fā)證書，MSP授權(quán)，賦予相應(yīng)權(quán)限策略。Peer ，applications，end users, administrators orders 必須擁有CA和MSP才能訪問鏈網(wǎng)。
一個(gè)MSP下含有以下結(jié)構(gòu)，如圖所示。

image

每個(gè)管理協(xié)作企業(yè)的ORG組織都可以擁有自己的MSP。如下圖所示，組織ORG1擁有的MSP叫ORG1.MSP，而組織ORG2業(yè)務(wù)復(fù)雜，所以維護(hù)了3個(gè)MSP。

image

數(shù)據(jù)庫： Hyperledger Fabric 項(xiàng)目中，目前可以支持的狀態(tài)數(shù)據(jù)庫有兩種：

LevelDB：LevelDB 是嵌入在 Peer 中的默認(rèn)鍵值對（key-value）狀態(tài)數(shù)據(jù)庫。

CouchDB：CouchDB 是一種可選的替代 levelDB 的狀態(tài)數(shù)據(jù)庫。與 LevelDB 鍵值存儲(chǔ)一樣，CouchDB 不僅可以根據(jù) key 進(jìn)行相應(yīng)的查詢，還可以根據(jù)不同的應(yīng)用場景需求實(shí)現(xiàn)復(fù)雜查詢。

PKI：Public Key Infrastructure，一種遵循標(biāo)準(zhǔn)的利用公鑰加密技術(shù)為電子商務(wù)的開展提供一套安全基礎(chǔ)平臺(tái)的技術(shù)和規(guī)范。

底層采用P2P網(wǎng)絡(luò)和gRPC協(xié)議實(shí)現(xiàn)對分布式賬本結(jié)構(gòu)的連通。通過Gossip協(xié)議進(jìn)行狀態(tài)同步、數(shù)據(jù)分發(fā)和成員探測。

共識(shí)：Fabric區(qū)塊鏈的網(wǎng)絡(luò)節(jié)點(diǎn)本質(zhì)上是互相復(fù)制的狀態(tài)機(jī)，節(jié)點(diǎn)之間需要保持相同的賬本狀態(tài)。為了實(shí)現(xiàn)分布式節(jié)點(diǎn)的一致性，各個(gè)節(jié)點(diǎn)需要通過共識(shí)過程，對賬本狀態(tài)的變化達(dá)成一致性的認(rèn)同。
Fabric區(qū)塊鏈的共識(shí)過程包括3個(gè)階段：背書、排序和校驗(yàn)。

1.背書

在背書（endorsement）階段中，背書節(jié)點(diǎn)對客戶端發(fā)來的交易提案進(jìn)行合法性校驗(yàn)，然后模擬執(zhí)行鏈碼得到交易結(jié)果，最后根據(jù)設(shè)定的背書邏輯判斷是否支持該交易提案。如果背書邏輯決定支持交易提案，會(huì)把交易提案簽名后發(fā)回給客戶端。
客戶端通常需要根據(jù)鏈碼的背書策略，向一個(gè)或者多個(gè)成員的背書節(jié)點(diǎn)發(fā)出背書請求。背書策略會(huì)定義需要哪些節(jié)點(diǎn)背書交易才有效，例如需要5個(gè)成員的背書節(jié)點(diǎn)中至少3個(gè)同意；或者某個(gè)特殊身份的成員支持等?？蛻舳酥挥性谑占銐蚨嗟谋硶?jié)點(diǎn)的交易提案簽名，交易才能被視為有效。

2.排序

排序（ordering）階段就是由排序服務(wù)節(jié)點(diǎn)對交易進(jìn)行排序，確定交易之間的時(shí)序關(guān)系。排序服務(wù)把一段時(shí)間內(nèi)收到的交易進(jìn)行排序，然后把排序后的批量交易打包成數(shù)據(jù)塊（區(qū)塊），再把區(qū)塊廣播給通道中的成員。采用排序共識(shí)方式，各個(gè)成員收到的是一組發(fā)生順序相同的交易，從而保證了所有節(jié)點(diǎn)的數(shù)據(jù)一致性。
目前，Hyperledger Fabric有三種交易排序算法：Solo、Kafka、SBFT。
Solo：只有一個(gè)排序服務(wù)節(jié)點(diǎn)負(fù)責(zé)接收交易信息并排序，是最簡單的一種排序算法，一般用于開發(fā)測試環(huán)境中。Solo共識(shí)模式屬于中心化的處理方式，不支持拜占庭容錯(cuò)。
Kafka：Kafka是Apache的一個(gè)開源項(xiàng)目，主要提供分布式的消息處理／分發(fā)服務(wù)，每個(gè)Kafka集群由多個(gè)服務(wù)節(jié)點(diǎn)組成。Hyperledger Fabric利用Kafka對交易信息進(jìn)行排序處理，提供高吞吐、低延時(shí)的處理能力，并且在集群內(nèi)部支持節(jié)點(diǎn)故障容錯(cuò)，但不支持拜占庭容錯(cuò)。
SBFT：簡單拜占庭算法，支持拜占庭容錯(cuò)的可靠排序算法，包括容忍節(jié)點(diǎn)故障以及一定數(shù)量的惡意節(jié)點(diǎn)。

排序服務(wù)是共識(shí)機(jī)制中重要的一環(huán)，所有交易都要通過排序服務(wù)的排序才可以達(dá)成全網(wǎng)共識(shí)，因此排序服務(wù)要避免成為網(wǎng)絡(luò)上的性能瓶頸。

3.校驗(yàn)

校驗(yàn)（Validation）階段是節(jié)點(diǎn)對排序后的交易進(jìn)行一系列的檢驗(yàn)，包括交易數(shù)據(jù)的完整性檢查、是否重復(fù)交易、背書簽名是否符合背書策略的要求、交易的讀寫集是否符合多版本并發(fā)控制MVCC（Multiversion Concurrency Control）的校驗(yàn)等。當(dāng)交易通過了所有校驗(yàn)后，將被標(biāo)注為合法并寫入賬本中。因?yàn)樗械拇_認(rèn)節(jié)點(diǎn)都按照相同的順序檢驗(yàn)交易，并且把合法的交易依次寫入賬本中，因此不同確認(rèn)節(jié)點(diǎn)的狀態(tài)能夠始終保持一致。

image

交易流程：前提假設(shè)是各節(jié)點(diǎn)已經(jīng)提前頒發(fā)好證書，且已正常啟動(dòng)，并加入已經(jīng)創(chuàng)建好的通道。此流程介紹的是在已經(jīng)實(shí)例化了的鏈碼通道上從發(fā)起一個(gè)調(diào)用交易到最終結(jié)賬的全過程。

1. 提交交易提案
   應(yīng)用程序（客戶端節(jié)點(diǎn)）構(gòu)造好交易提案（交易提案中包含本次交易要調(diào)用的合約標(biāo)識(shí)、合約方法和參數(shù)信息以及客戶端簽名等）請求后，根據(jù)背書策略選擇背書節(jié)點(diǎn)執(zhí)行交易提案并進(jìn)行背書簽名。背書節(jié)點(diǎn)是鏈代碼中背書策略指定的節(jié)點(diǎn)。正常情況下背書節(jié)點(diǎn)執(zhí)行后的結(jié)果是一致的，只有背書節(jié)點(diǎn)對結(jié)果的簽名不一樣。

2. 模擬執(zhí)行提案并進(jìn)行背書
   背書節(jié)點(diǎn)在收到交易提案后會(huì)進(jìn)行一些驗(yàn)證，驗(yàn)證通過后，背書節(jié)點(diǎn)會(huì)根據(jù)當(dāng)前賬本數(shù)據(jù)模擬執(zhí)行鏈碼中的業(yè)務(wù)邏輯并生成讀寫集（RwSet）。模擬執(zhí)行時(shí)不會(huì)更新賬本數(shù)據(jù)。然后背書節(jié)點(diǎn)對這些讀寫集進(jìn)行簽名生成提案響應(yīng)（proposal response），然后返回給應(yīng)用程序。
3. 收集交易的背書（返回模擬執(zhí)行結(jié)果）
   應(yīng)用程序收到proposal response后會(huì)對背書節(jié)點(diǎn)的簽名進(jìn)行驗(yàn)證（所有節(jié)點(diǎn)接收到任何消息時(shí)都需要先驗(yàn)證消息的合法性）。如果鏈碼只進(jìn)行賬本查詢操作，應(yīng)用程序只需要檢查查詢響應(yīng)，并不會(huì)將交易提交給排序服務(wù)節(jié)點(diǎn)。如果鏈碼對賬本進(jìn)行了invoke操作，則需要提交交易給排序服務(wù)進(jìn)行賬本更新（提交前會(huì)判斷背書策略是否滿足）。

4. 構(gòu)造交易請求并發(fā)送給排序服務(wù)節(jié)點(diǎn)
   應(yīng)用程序接收到所有背書節(jié)點(diǎn)的簽名后，根據(jù)背書簽名調(diào)用SDK生成交易，并廣播給排序服務(wù)節(jié)點(diǎn)。其中生成交易的過程很簡單，只需要確認(rèn)所有背書節(jié)點(diǎn)的執(zhí)行結(jié)果完全一致，再將交易提案、提案響應(yīng)和背書簽名打包生成交易即可。
5. 排序服務(wù)節(jié)點(diǎn)對交易進(jìn)行排序并生成區(qū)塊
   排序服務(wù)節(jié)點(diǎn)接收到網(wǎng)絡(luò)中所有通道發(fā)出的交易信息，讀取交易信封獲取通道名稱，按各個(gè)通道上交易的接收時(shí)間順序?qū)灰仔畔⑦M(jìn)行排序（多通道隔離），生成區(qū)塊。（在這個(gè)過程中，排序服務(wù)節(jié)點(diǎn)不會(huì)關(guān)心交易是否正確，只是負(fù)責(zé)排序和打包。交易的有效性在第7步進(jìn)行驗(yàn)證）

6. 排序服務(wù)節(jié)點(diǎn)廣播區(qū)塊給主節(jié)點(diǎn)
   排序服務(wù)節(jié)點(diǎn)生成區(qū)塊后會(huì)廣播給通道上不同組織的主節(jié)點(diǎn)。
7. 記賬節(jié)點(diǎn)驗(yàn)證區(qū)塊內(nèi)容并寫入到賬本
   所有的peer節(jié)點(diǎn)都是記賬節(jié)點(diǎn)，記錄的是節(jié)點(diǎn)已加入通道的賬本數(shù)據(jù)。記賬節(jié)點(diǎn)接收到的排序服務(wù)節(jié)點(diǎn)生成的區(qū)塊后，會(huì)驗(yàn)證區(qū)塊交易的有效性，然后提交到本地賬本并產(chǎn)生一個(gè)生成區(qū)塊的事件，監(jiān)聽區(qū)塊事件的應(yīng)用程序會(huì)進(jìn)行后續(xù)的處理。（如果接收的是配置區(qū)塊，則會(huì)更新緩存的配置信息）
8. 主節(jié)點(diǎn)在組織內(nèi)部同步最新的區(qū)塊
   如果交易是無效的，也會(huì)更新區(qū)塊，但不會(huì)更新世界狀態(tài)。（區(qū)塊存儲(chǔ)的是操作語句，而世界狀態(tài)存儲(chǔ)的是被處理的數(shù)據(jù)）

fabric聯(lián)盟鏈的開發(fā)人員主要分為三類：底層是系統(tǒng)運(yùn)維，負(fù)責(zé)系統(tǒng)的部署與維護(hù)；其次是組織管理人員，負(fù)責(zé)證書、MSP權(quán)限管理、共識(shí)機(jī)制等；最后是業(yè)務(wù)開發(fā)人員，他們負(fù)責(zé)編寫chaincode、創(chuàng)建維護(hù)channel、執(zhí)行transaction交易等，如下面的圖所示。

image

我們的開發(fā)流程主要包括寫智能合約，以及通過SDK調(diào)用智能合約，及訂閱各類事件，如圖所示。

image

下面是fabric中各個(gè)包的大概內(nèi)容：

一，bccsp ??
區(qū)塊鏈加密服務(wù)提供者（Blockchain Crypto Service Provider），提供一些密碼學(xué)相關(guān)操作的實(shí)現(xiàn)，包括 Hash、簽名、校驗(yàn)、加解密等。
主要支持 MSP 的相關(guān)調(diào)用。

二，bddtests
行為驅(qū)動(dòng)開發(fā)測試（Behaviour Driven Development）相關(guān)代碼。主要是關(guān)于各種測試，線下peer節(jié)點(diǎn)部署等相關(guān)的操作。

三，common
一些通用的功能模塊。包括常用的配置config、加密簽名的crypto、ledger設(shè)置，工具包含協(xié)議設(shè)置等等。

四，core ??
大部分核心實(shí)現(xiàn)代碼都在本包下。其它包的代碼封裝上層接口，最終調(diào)用本包內(nèi)代碼。包含區(qū)塊鏈操作Chaincode代碼實(shí)現(xiàn)、peer節(jié)點(diǎn)消息處理及行為的實(shí)現(xiàn)、容器container的實(shí)現(xiàn)如docker交互實(shí)現(xiàn)、策略實(shí)現(xiàn)policy及預(yù)處理endorser等等。

五，devenv
主要是方便本地搭建開發(fā)平臺(tái)的一些腳本。主要包含了CouchDB設(shè)置、golang編譯腳本、64位ubantu配置腳本等等。

六，docs
項(xiàng)目相關(guān)的所有文檔。包含客戶定制主題以及一些工具的源代碼。

七，events ??
EventHub 服務(wù)處理相關(guān)的模塊。主要是包含了消費(fèi)者，生產(chǎn)者的實(shí)現(xiàn)代碼。另外，Even服務(wù)其包含了四種類型定義如下：REGISTER = 0;BLOCK = 1;CHAINCODE = 2;REJECTION = 3。

八，examples
示例文件夾，包括一些 chaincode 示例和監(jiān)聽事件的示例。

九，gossip ??
流言算法–gossip算法。一個(gè)基于pull的gossip算法的實(shí)現(xiàn)。最終確保狀態(tài)一致。 該協(xié)議大致如下：
1）A發(fā)起者發(fā)送Hello（B唯一標(biāo)識(shí)，nonce）消息到B遠(yuǎn)程節(jié)點(diǎn)（多個(gè)）。
2）收Hello信息后發(fā)送SendDigest到A節(jié)點(diǎn)，其中包含nonce
3）A收到SendDigest，校驗(yàn)數(shù)據(jù)和nonce，把B作為待發(fā)送節(jié)點(diǎn)，并封裝想要pull的數(shù)據(jù)SendReq到B節(jié)點(diǎn)
4）B收到SendReq發(fā)送SendRes到A節(jié)點(diǎn)，數(shù)據(jù)為SendReq不包含的數(shù)據(jù)

十，gotools
go 相關(guān)的開發(fā)工具的安裝腳本：golint、govendor、goimports、protoc-gen-go、ginkgo、gocov、gocov-xml 等。

十一，images
一些跟 Docker 鏡像生成相關(guān)的配置和腳本。主要包括各個(gè)鏡像的 Dockerfile.in 文件。這些文件是生成 Dockerfile 的模板。

十二，msp ??
成員服務(wù)提供者（Member Service Provider），提供一組認(rèn)證相關(guān)的密碼學(xué)機(jī)制和協(xié)議，用來負(fù)責(zé)對網(wǎng)絡(luò)提供證書分發(fā)、校驗(yàn)，身份認(rèn)證管理等。一些成員管理的實(shí)現(xiàn)代碼等。

十三，orderer ??
在 fabric 1.0 架構(gòu)中，共識(shí)功能被抽取出來，作為單獨(dú)的 fabric-orderer 模塊來實(shí)現(xiàn)，完成核心的排序功能。最核心的功能是實(shí)現(xiàn)從客戶端過來的 broadcast 請求，和從 orderer 發(fā)送到 peer 節(jié)點(diǎn)的 deliver 接口。同時(shí)，orderer 需要支持多 channel 的維護(hù)。主要包含Solo、kafka及bft三個(gè)方法。

十四，peer ??
peer節(jié)點(diǎn)的相關(guān)主命令模塊。作為服務(wù)端時(shí)候，支持 node 子命令；作為命令行時(shí)候，支持 chaincode、channel 等子命令。其中包含一些命令操作的實(shí)現(xiàn)等等。

十五，proposals
一些建議，包含現(xiàn)在對區(qū)塊的結(jié)構(gòu)優(yōu)化建議及時(shí)序圖的呈現(xiàn)。還有其他方面的一些建議文件。

十六，protos ??
Protobuf 格式的數(shù)據(jù)結(jié)構(gòu)和消息協(xié)議都在同一個(gè) protos 包內(nèi)。
這里面是所有基本的數(shù)據(jù)結(jié)構(gòu)（message）定義和 GRPC 的服務(wù)（service）接口聲明。

十七，release
關(guān)于如何從dockerhub中拉取docker鏡像的相關(guān)操作及腳本代碼。

十八，release_notes
關(guān)于最新2017年6月8日beta版本更新的相關(guān)資訊。主要包括release筆記內(nèi)容及版本變根日志。

十九，sampleconfig
提供了一些樣例證書文件和配置文件。pem格式，通過openssl來查看內(nèi)容。內(nèi)容基于BASE64來進(jìn)行編碼。

二十，scripts
一些輔助腳本，多數(shù)為外部 Makefile 調(diào)用。比如一些依賴環(huán)境的安裝如python-pip、然后pip的安裝包中的一些依賴環(huán)境等。還有一些配置，如讓容器永不退出等。

二十一，test
用于測試的一些腳本。 主要包含chaincode、回歸測試腳本、容器關(guān)聯(lián)order節(jié)點(diǎn)及peer節(jié)點(diǎn)測試腳本、環(huán)境構(gòu)筑測試相關(guān)腳本如channel、以及一部分的工具LTE、OTE、PTE。

二十二，unit-test
單點(diǎn)docker配置測試腳本

二十三，vendor
關(guān)于部分提供商的內(nèi)容及管理依賴，包含 github.com、golang.org、google系列及gopkg.in相關(guān)內(nèi)容。

除了上述的包信息之外，主目錄里面還包括一些說明文檔、安裝需求說明、License 信息文件等。

Fabric v1.0 的環(huán)境搭建

測試網(wǎng)絡(luò)

重新打開一個(gè)命令行窗口，輸入：
docker exec -it cli bash

peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'

方框內(nèi)可以看見余額為：90

下面我們可以進(jìn)行轉(zhuǎn)賬操作，操作為invoke ，由a轉(zhuǎn)b 50：

peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n mycc -c '{"Args":["invoke","a","b","50"]}'

現(xiàn)在轉(zhuǎn)賬完畢， 我們試一試再查詢一下a賬戶的余額，重復(fù)之前的查詢指令，結(jié)果為：a的余額只有40了。

最后，我們需要關(guān)閉Fabric，這里先使用exit命令退出cli容器。
exit
然后類似于啟動(dòng)指令：
./network_setup.sh down