Fabric基本概念
Fabric (Hyperledger fabric) 是由 IBM 貢獻的超級賬本框架：利用現(xiàn)有成熟的技術(shù)來組合而成的一個區(qū)塊鏈技術(shù)的實現(xiàn)，允許可插拔實現(xiàn)各種功能的的模塊化架構(gòu)。它具有強大的容器技術(shù)，來承載各種主流語言來編寫的智能合約。
Fabric 大致分為底層的網(wǎng)絡(luò)層、權(quán)限管理模塊、區(qū)塊鏈應(yīng)用模塊，通過 SDK 和 CLI 對應(yīng)用開發(fā)者提供服務(wù)，如下面的圖所示。
chaincode：鏈碼，Hyperledger Fabric智能合約寫在鏈碼里并在區(qū)塊鏈外部應(yīng)用程序要和賬本發(fā)生交易的時候被外部應(yīng)用程序調(diào)用。在大多數(shù)情況下，鏈碼只和賬本的數(shù)據(jù)庫組件（世界狀態(tài)）交互，而不和交易日志交互。
賬本Hyperledger Fabric有一個賬本子系統(tǒng)包含兩個組件：世界狀態(tài)和交易日志。每一個參與者有一份他們參與的每個Hyperledger Fabric網(wǎng)絡(luò)的賬本的副本。世界狀態(tài)組件描述了一個給定時間點的賬本狀態(tài)。它是賬本的數(shù)據(jù)庫，存儲的是賬本當(dāng)前值。交易日志組件記錄所有導(dǎo)致世界狀態(tài)當(dāng)前值的交易。它是世界狀態(tài)的更新歷史。這樣，賬本就是世界狀態(tài)數(shù)據(jù)庫和交易日志歷史的組合體。
下面是一個世界狀態(tài)例圖，記錄的是兩輛車CAR1和CAR2的信息。應(yīng)用程序可以調(diào)用（invoke）智能合約來put和delete狀態(tài)。
世界狀態(tài)中有一個屬性——版本號，版本號從0開始，每當(dāng)狀態(tài)更新時版本號就遞增。狀態(tài)更新時會首先檢查版本號，以確保當(dāng)前狀態(tài)的版本與背書時的版本一致（避免并發(fā)更新）。
區(qū)塊結(jié)構(gòu)： 由三個部分組成，分別是區(qū)塊頭、區(qū)塊數(shù)據(jù)和區(qū)塊元數(shù)據(jù)。
1.區(qū)塊頭包含三個屬性（區(qū)塊號、當(dāng)前區(qū)塊哈希、前一個區(qū)塊的哈希），當(dāng)一個區(qū)塊被創(chuàng)建時寫入。
2.區(qū)塊數(shù)據(jù)包含的是排序后的交易列表。當(dāng)區(qū)塊被ordering service創(chuàng)建時寫入。
3.區(qū)塊元數(shù)據(jù)包括區(qū)塊的寫入時間，以及區(qū)塊寫入者的證書、公鑰和簽名。
交易： 在fabric中指的就是對鏈代碼（即智能合約）的操作，交易分為兩種，部署交易（deploy transaction）和調(diào)用交易（invoke transaction）。
- 部署交易
部署交易指的是創(chuàng)建新的鏈代碼，并且用一個程序作為參數(shù)，當(dāng)一個部署交易成功執(zhí)行時，鏈代碼就被安裝到區(qū)塊鏈上了。 - 調(diào)用交易
調(diào)用交易指的是運行鏈代碼，鏈代碼執(zhí)行時可能會修改相應(yīng)的狀態(tài)，并返回輸出。
下圖是一個交易的詳細(xì)結(jié)構(gòu)：
交易頭：包含交易的元數(shù)據(jù)，如鏈碼名稱、版本等
交易簽名：包含由客戶端應(yīng)用程序創(chuàng)建的加密簽名，作用是判斷交易是否被篡改
交易提案：作用是對由應(yīng)用程序提供給智能合約的輸入?yún)?shù)進行編碼。當(dāng)智能合約運行時，提案負(fù)責(zé)將參數(shù)傳遞過去
交易響應(yīng)：是智能合約的輸出，包含的是世界狀態(tài)在交易前后的值，以讀寫集的形式展示。
節(jié)點: 是區(qū)塊鏈的通信實體，是一個邏輯概念，不同類型的多個節(jié)點可以運行在同一個物理服務(wù)器上。節(jié)點主要有以下四種：
1.客戶端節(jié)點：客戶端必須連接到某一個peer節(jié)點或排序服務(wù)節(jié)點上才能與區(qū)塊鏈網(wǎng)絡(luò)進行通信。客戶端向背書節(jié)點（endorser）提交交易提案（transaction proposal），當(dāng)收集到足夠背書后，向排序服務(wù)節(jié)點廣播交易提案，進行排序，生成區(qū)塊。
2.普通節(jié)點peer：peer節(jié)點根據(jù)所承擔(dān)的角色又可以分為記賬節(jié)點（committer）、背書節(jié)點（endorser）、主節(jié)點（leader）和錨節(jié)點（anchor）。
記賬節(jié)點：所有的peer節(jié)點都是記賬節(jié)點（committer），負(fù)責(zé)驗證排序服務(wù)節(jié)點區(qū)塊里的交易，維護狀態(tài)和總賬（Ledger）的副本。該節(jié)點會定期從orderer節(jié)點獲取包含交易的區(qū)塊，在對這些區(qū)塊進行核發(fā)驗證之后，會把這些區(qū)塊加入到區(qū)塊鏈中。committer節(jié)點無法通過配置文件配置，需要在當(dāng)前客戶端或者命令行發(fā)起交易請求的時候手動指定相關(guān)的committer節(jié)點。記賬節(jié)點可以有多個。
背書節(jié)點：部分節(jié)點還會執(zhí)行交易并對結(jié)果進行簽名背書，充當(dāng)背書節(jié)點（endorser）的角色。背書節(jié)點是動態(tài)的角色，是與具體鏈碼綁定的。每個鏈碼在實例化的時候都會設(shè)置背書策略，指定哪些節(jié)點對交易背書后交易才是有效的。并且只有應(yīng)用程序向它發(fā)起交易背書請求的時候才是背書節(jié)點，其他時候都是普通的記賬節(jié)點，只負(fù)責(zé)驗證交易并記賬。背書節(jié)點也無法通過配置文件指定，而是由發(fā)起交易請求的客戶端指定。背書節(jié)點可以有多個。
錨節(jié)點：peer節(jié)點還可以是錨節(jié)點（anchor peer），錨節(jié)點主要負(fù)責(zé)代表組織和其他組織進行信息交換。每個組織都有一個錨節(jié)點，錨節(jié)點對于組織來說非常重要，如果錨節(jié)點出現(xiàn)問題，當(dāng)前組織就會與其他組織失去聯(lián)系。錨節(jié)點的配置信息是在configtxgen模塊的配置文件configtx.yaml中配置的。錨節(jié)點只能有一個。
主節(jié)點：peer節(jié)點還可以是主節(jié)點（leader peer），能與排序服務(wù)節(jié)點通信，負(fù)責(zé)從排序服務(wù)節(jié)點獲取最新的區(qū)塊并在組織內(nèi)部同步。主節(jié)點在整個組織中只能有一個。
3.排序服務(wù)節(jié)點orderer：接收包含背書簽名的交易，對未打包的交易進行排序生成區(qū)塊，廣播給peer節(jié)點。排序服務(wù)提供的是原子廣播，保證同一個鏈上的節(jié)點接收到相同的信息，并且有相同的邏輯順序。
4.CA節(jié)點：fabric1.0的證書頒發(fā)機構(gòu)，由服務(wù)器和客戶端組成。CA節(jié)點接收客戶端的注冊申請，返回注冊密碼用于用戶登錄，以便獲取身份證書。區(qū)塊鏈上的所有操作都需要驗證用戶身份。
fabric系統(tǒng)邏輯結(jié)構(gòu)圖
org：fabric系統(tǒng)是通過組織來劃分的，每個組織內(nèi)都有承擔(dān)不同功能的peer節(jié)點，同時每個組織都有自己對應(yīng)的fabric-ca服務(wù)器，fabric系統(tǒng)中所有的組織共用一個orderer集群。fabric中的組織在現(xiàn)實世界中可以是一個公司、一個企業(yè)，或者一個協(xié)會。在fabric中，組織是承擔(dān)著數(shù)據(jù)信用責(zé)任的區(qū)塊鏈系統(tǒng)參與方。
在設(shè)計一個fabric系統(tǒng)時，第一步就是要確定系統(tǒng)的參與方，然后從這些參與者中選出組織（生成對應(yīng)的組織編號、域名、證書等），然后再確認(rèn)組織的管理方式。組織的管理方式是指組織在遇到問題時的協(xié)作方式（如新組織的加入）。
channel：fabric的數(shù)據(jù)存儲結(jié)構(gòu)被設(shè)計成多賬本體系，每個賬本在fabric中被稱為channel。每個channel中都有一個完全獨立的賬本。同一個channel中的所有peer節(jié)點都保存一份相同的數(shù)據(jù)。
通道由成員（組織）、每個成員的錨節(jié)點、賬本、鏈碼應(yīng)用程序和排序服務(wù)節(jié)點定義。網(wǎng)絡(luò)上的每個交易都是在一個通道上執(zhí)行的，在該通道上，每一方都必須經(jīng)過身份驗證和授權(quán)才能在該通道上進行交易。加入通道的每一個peer都有其自己的身份，由成員服務(wù)提供者（MSP）提供。
[圖片上傳失敗...(image-75d5dc-1557391569944)]
MSP：Membership Service Provider，負(fù)責(zé)聯(lián)盟鏈成員的證書管理，它定義了哪些RCA以及ICA在鏈里是可信任的，包括定義了channel上的合作者。
每個組織都有自己的證書管理即CA, 及MSP, CA給每個peer頒發(fā)證書，MSP授權(quán)，賦予相應(yīng)權(quán)限策略。Peer ，applications，end users, administrators orders 必須擁有CA和MSP才能訪問鏈網(wǎng)。
一個MSP下含有以下結(jié)構(gòu)，如圖所示。
每個管理協(xié)作企業(yè)的ORG組織都可以擁有自己的MSP。如下圖所示，組織ORG1擁有的MSP叫ORG1.MSP，而組織ORG2業(yè)務(wù)復(fù)雜，所以維護了3個MSP。
數(shù)據(jù)庫： Hyperledger Fabric 項目中，目前可以支持的狀態(tài)數(shù)據(jù)庫有兩種：
LevelDB：LevelDB 是嵌入在 Peer 中的默認(rèn)鍵值對（key-value）狀態(tài)數(shù)據(jù)庫。
CouchDB：CouchDB 是一種可選的替代 levelDB 的狀態(tài)數(shù)據(jù)庫。與 LevelDB 鍵值存儲一樣，CouchDB 不僅可以根據(jù) key 進行相應(yīng)的查詢，還可以根據(jù)不同的應(yīng)用場景需求實現(xiàn)復(fù)雜查詢。
PKI：Public Key Infrastructure，一種遵循標(biāo)準(zhǔn)的利用公鑰加密技術(shù)為電子商務(wù)的開展提供一套安全基礎(chǔ)平臺的技術(shù)和規(guī)范。
底層采用P2P網(wǎng)絡(luò)和gRPC協(xié)議實現(xiàn)對分布式賬本結(jié)構(gòu)的連通。通過Gossip協(xié)議進行狀態(tài)同步、數(shù)據(jù)分發(fā)和成員探測。
共識：Fabric區(qū)塊鏈的網(wǎng)絡(luò)節(jié)點本質(zhì)上是互相復(fù)制的狀態(tài)機，節(jié)點之間需要保持相同的賬本狀態(tài)。為了實現(xiàn)分布式節(jié)點的一致性，各個節(jié)點需要通過共識過程，對賬本狀態(tài)的變化達(dá)成一致性的認(rèn)同。
Fabric區(qū)塊鏈的共識過程包括3個階段：背書、排序和校驗。
1.背書
在背書（endorsement）階段中，背書節(jié)點對客戶端發(fā)來的交易提案進行合法性校驗，然后模擬執(zhí)行鏈碼得到交易結(jié)果，最后根據(jù)設(shè)定的背書邏輯判斷是否支持該交易提案。如果背書邏輯決定支持交易提案，會把交易提案簽名后發(fā)回給客戶端。
客戶端通常需要根據(jù)鏈碼的背書策略，向一個或者多個成員的背書節(jié)點發(fā)出背書請求。背書策略會定義需要哪些節(jié)點背書交易才有效，例如需要5個成員的背書節(jié)點中至少3個同意；或者某個特殊身份的成員支持等?？蛻舳酥挥性谑占銐蚨嗟谋硶?jié)點的交易提案簽名，交易才能被視為有效。
2.排序
排序（ordering）階段就是由排序服務(wù)節(jié)點對交易進行排序，確定交易之間的時序關(guān)系。排序服務(wù)把一段時間內(nèi)收到的交易進行排序，然后把排序后的批量交易打包成數(shù)據(jù)塊（區(qū)塊），再把區(qū)塊廣播給通道中的成員。采用排序共識方式，各個成員收到的是一組發(fā)生順序相同的交易，從而保證了所有節(jié)點的數(shù)據(jù)一致性。
目前，Hyperledger Fabric有三種交易排序算法：Solo、Kafka、SBFT。
Solo：只有一個排序服務(wù)節(jié)點負(fù)責(zé)接收交易信息并排序，是最簡單的一種排序算法，一般用于開發(fā)測試環(huán)境中。Solo共識模式屬于中心化的處理方式，不支持拜占庭容錯。
Kafka：Kafka是Apache的一個開源項目，主要提供分布式的消息處理／分發(fā)服務(wù)，每個Kafka集群由多個服務(wù)節(jié)點組成。Hyperledger Fabric利用Kafka對交易信息進行排序處理，提供高吞吐、低延時的處理能力，并且在集群內(nèi)部支持節(jié)點故障容錯，但不支持拜占庭容錯。
SBFT：簡單拜占庭算法，支持拜占庭容錯的可靠排序算法，包括容忍節(jié)點故障以及一定數(shù)量的惡意節(jié)點。
排序服務(wù)是共識機制中重要的一環(huán)，所有交易都要通過排序服務(wù)的排序才可以達(dá)成全網(wǎng)共識，因此排序服務(wù)要避免成為網(wǎng)絡(luò)上的性能瓶頸。
3.校驗
校驗（Validation）階段是節(jié)點對排序后的交易進行一系列的檢驗，包括交易數(shù)據(jù)的完整性檢查、是否重復(fù)交易、背書簽名是否符合背書策略的要求、交易的讀寫集是否符合多版本并發(fā)控制MVCC（Multiversion Concurrency Control）的校驗等。當(dāng)交易通過了所有校驗后，將被標(biāo)注為合法并寫入賬本中。因為所有的確認(rèn)節(jié)點都按照相同的順序檢驗交易，并且把合法的交易依次寫入賬本中，因此不同確認(rèn)節(jié)點的狀態(tài)能夠始終保持一致。
交易流程：前提假設(shè)是各節(jié)點已經(jīng)提前頒發(fā)好證書，且已正常啟動，并加入已經(jīng)創(chuàng)建好的通道。此流程介紹的是在已經(jīng)實例化了的鏈碼通道上從發(fā)起一個調(diào)用交易到最終結(jié)賬的全過程。
- 提交交易提案
應(yīng)用程序（客戶端節(jié)點）構(gòu)造好交易提案（交易提案中包含本次交易要調(diào)用的合約標(biāo)識、合約方法和參數(shù)信息以及客戶端簽名等）請求后，根據(jù)背書策略選擇背書節(jié)點執(zhí)行交易提案并進行背書簽名。背書節(jié)點是鏈代碼中背書策略指定的節(jié)點。正常情況下背書節(jié)點執(zhí)行后的結(jié)果是一致的，只有背書節(jié)點對結(jié)果的簽名不一樣。
- 模擬執(zhí)行提案并進行背書
背書節(jié)點在收到交易提案后會進行一些驗證，驗證通過后，背書節(jié)點會根據(jù)當(dāng)前賬本數(shù)據(jù)模擬執(zhí)行鏈碼中的業(yè)務(wù)邏輯并生成讀寫集（RwSet）。模擬執(zhí)行時不會更新賬本數(shù)據(jù)。然后背書節(jié)點對這些讀寫集進行簽名生成提案響應(yīng)（proposal response），然后返回給應(yīng)用程序。 - 收集交易的背書（返回模擬執(zhí)行結(jié)果）
應(yīng)用程序收到proposal response后會對背書節(jié)點的簽名進行驗證（所有節(jié)點接收到任何消息時都需要先驗證消息的合法性）。如果鏈碼只進行賬本查詢操作，應(yīng)用程序只需要檢查查詢響應(yīng)，并不會將交易提交給排序服務(wù)節(jié)點。如果鏈碼對賬本進行了invoke操作，則需要提交交易給排序服務(wù)進行賬本更新（提交前會判斷背書策略是否滿足）。
- 構(gòu)造交易請求并發(fā)送給排序服務(wù)節(jié)點
應(yīng)用程序接收到所有背書節(jié)點的簽名后，根據(jù)背書簽名調(diào)用SDK生成交易，并廣播給排序服務(wù)節(jié)點。其中生成交易的過程很簡單，只需要確認(rèn)所有背書節(jié)點的執(zhí)行結(jié)果完全一致，再將交易提案、提案響應(yīng)和背書簽名打包生成交易即可。 - 排序服務(wù)節(jié)點對交易進行排序并生成區(qū)塊
排序服務(wù)節(jié)點接收到網(wǎng)絡(luò)中所有通道發(fā)出的交易信息，讀取交易信封獲取通道名稱，按各個通道上交易的接收時間順序?qū)灰仔畔⑦M行排序（多通道隔離），生成區(qū)塊。（在這個過程中，排序服務(wù)節(jié)點不會關(guān)心交易是否正確，只是負(fù)責(zé)排序和打包。交易的有效性在第7步進行驗證）
- 排序服務(wù)節(jié)點廣播區(qū)塊給主節(jié)點
排序服務(wù)節(jié)點生成區(qū)塊后會廣播給通道上不同組織的主節(jié)點。 - 記賬節(jié)點驗證區(qū)塊內(nèi)容并寫入到賬本
所有的peer節(jié)點都是記賬節(jié)點，記錄的是節(jié)點已加入通道的賬本數(shù)據(jù)。記賬節(jié)點接收到的排序服務(wù)節(jié)點生成的區(qū)塊后，會驗證區(qū)塊交易的有效性，然后提交到本地賬本并產(chǎn)生一個生成區(qū)塊的事件，監(jiān)聽區(qū)塊事件的應(yīng)用程序會進行后續(xù)的處理。（如果接收的是配置區(qū)塊，則會更新緩存的配置信息） - 主節(jié)點在組織內(nèi)部同步最新的區(qū)塊
如果交易是無效的，也會更新區(qū)塊，但不會更新世界狀態(tài)。（區(qū)塊存儲的是操作語句，而世界狀態(tài)存儲的是被處理的數(shù)據(jù)）
fabric聯(lián)盟鏈的開發(fā)人員主要分為三類：底層是系統(tǒng)運維，負(fù)責(zé)系統(tǒng)的部署與維護；其次是組織管理人員，負(fù)責(zé)證書、MSP權(quán)限管理、共識機制等；最后是業(yè)務(wù)開發(fā)人員，他們負(fù)責(zé)編寫chaincode、創(chuàng)建維護channel、執(zhí)行transaction交易等，如下面的圖所示。
我們的開發(fā)流程主要包括寫智能合約，以及通過SDK調(diào)用智能合約，及訂閱各類事件，如圖所示。
下面是fabric中各個包的大概內(nèi)容：
一，bccsp ??
區(qū)塊鏈加密服務(wù)提供者（Blockchain Crypto Service Provider），提供一些密碼學(xué)相關(guān)操作的實現(xiàn)，包括 Hash、簽名、校驗、加解密等。
主要支持 MSP 的相關(guān)調(diào)用。
二，bddtests
行為驅(qū)動開發(fā)測試（Behaviour Driven Development）相關(guān)代碼。主要是關(guān)于各種測試，線下peer節(jié)點部署等相關(guān)的操作。
三，common
一些通用的功能模塊。包括常用的配置config、加密簽名的crypto、ledger設(shè)置，工具包含協(xié)議設(shè)置等等。
四，core ??
大部分核心實現(xiàn)代碼都在本包下。其它包的代碼封裝上層接口，最終調(diào)用本包內(nèi)代碼。包含區(qū)塊鏈操作Chaincode代碼實現(xiàn)、peer節(jié)點消息處理及行為的實現(xiàn)、容器container的實現(xiàn)如docker交互實現(xiàn)、策略實現(xiàn)policy及預(yù)處理endorser等等。
五，devenv
主要是方便本地搭建開發(fā)平臺的一些腳本。主要包含了CouchDB設(shè)置、golang編譯腳本、64位ubantu配置腳本等等。
六，docs
項目相關(guān)的所有文檔。包含客戶定制主題以及一些工具的源代碼。
七，events ??
EventHub 服務(wù)處理相關(guān)的模塊。主要是包含了消費者，生產(chǎn)者的實現(xiàn)代碼。另外，Even服務(wù)其包含了四種類型定義如下：REGISTER = 0;BLOCK = 1;CHAINCODE = 2;REJECTION = 3。
八，examples
示例文件夾，包括一些 chaincode 示例和監(jiān)聽事件的示例。
九，gossip ??
流言算法–gossip算法。一個基于pull的gossip算法的實現(xiàn)。最終確保狀態(tài)一致。 該協(xié)議大致如下：
1）A發(fā)起者發(fā)送Hello（B唯一標(biāo)識，nonce）消息到B遠(yuǎn)程節(jié)點（多個）。
2）收Hello信息后發(fā)送SendDigest到A節(jié)點，其中包含nonce
3）A收到SendDigest，校驗數(shù)據(jù)和nonce，把B作為待發(fā)送節(jié)點，并封裝想要pull的數(shù)據(jù)SendReq到B節(jié)點
4）B收到SendReq發(fā)送SendRes到A節(jié)點，數(shù)據(jù)為SendReq不包含的數(shù)據(jù)
十，gotools
go 相關(guān)的開發(fā)工具的安裝腳本：golint、govendor、goimports、protoc-gen-go、ginkgo、gocov、gocov-xml 等。
十一，images
一些跟 Docker 鏡像生成相關(guān)的配置和腳本。主要包括各個鏡像的 Dockerfile.in 文件。這些文件是生成 Dockerfile 的模板。
十二，msp ??
成員服務(wù)提供者（Member Service Provider），提供一組認(rèn)證相關(guān)的密碼學(xué)機制和協(xié)議，用來負(fù)責(zé)對網(wǎng)絡(luò)提供證書分發(fā)、校驗，身份認(rèn)證管理等。一些成員管理的實現(xiàn)代碼等。
十三，orderer ??
在 fabric 1.0 架構(gòu)中，共識功能被抽取出來，作為單獨的 fabric-orderer 模塊來實現(xiàn)，完成核心的排序功能。最核心的功能是實現(xiàn)從客戶端過來的 broadcast 請求，和從 orderer 發(fā)送到 peer 節(jié)點的 deliver 接口。同時，orderer 需要支持多 channel 的維護。主要包含Solo、kafka及bft三個方法。
十四，peer ??
peer節(jié)點的相關(guān)主命令模塊。作為服務(wù)端時候，支持 node 子命令；作為命令行時候，支持 chaincode、channel 等子命令。其中包含一些命令操作的實現(xiàn)等等。
十五，proposals
一些建議，包含現(xiàn)在對區(qū)塊的結(jié)構(gòu)優(yōu)化建議及時序圖的呈現(xiàn)。還有其他方面的一些建議文件。
十六，protos ??
Protobuf 格式的數(shù)據(jù)結(jié)構(gòu)和消息協(xié)議都在同一個 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來進行編碼。
二十，scripts
一些輔助腳本，多數(shù)為外部 Makefile 調(diào)用。比如一些依賴環(huán)境的安裝如python-pip、然后pip的安裝包中的一些依賴環(huán)境等。還有一些配置，如讓容器永不退出等。
二十一，test
用于測試的一些腳本。 主要包含chaincode、回歸測試腳本、容器關(guān)聯(lián)order節(jié)點及peer節(jié)點測試腳本、環(huán)境構(gòu)筑測試相關(guān)腳本如channel、以及一部分的工具LTE、OTE、PTE。
二十二，unit-test
單點docker配置測試腳本
二十三，vendor
關(guān)于部分提供商的內(nèi)容及管理依賴，包含 github.com、golang.org、google系列及gopkg.in相關(guān)內(nèi)容。
除了上述的包信息之外，主目錄里面還包括一些說明文檔、安裝需求說明、License 信息文件等。
測試網(wǎng)絡(luò)
重新打開一個命令行窗口，輸入：
docker exec -it cli bash
peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
方框內(nèi)可以看見余額為：90
下面我們可以進行轉(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
然后類似于啟動指令：
./network_setup.sh down
