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)灯抛，并返回輸出。
下圖是一個交易的詳細結(jié)構(gòu)：
交易頭：包含交易的元數(shù)據(jù)音瓷，如鏈碼名稱对嚼、版本等
交易簽名：包含由客戶端應(yīng)用程序創(chuàng)建的加密簽名，作用是判斷交易是否被篡改
交易提案：作用是對由應(yīng)用程序提供給智能合約的輸入?yún)?shù)進行編碼绳慎。當(dāng)智能合約運行時纵竖，提案負責(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），負責(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é)點，只負責(zé)驗證交易并記賬匈勋。背書節(jié)點也無法通過配置文件指定礼旅，而是由發(fā)起交易請求的客戶端指定。背書節(jié)點可以有多個洽洁。
錨節(jié)點：peer節(jié)點還可以是錨節(jié)點（anchor peer）痘系，錨節(jié)點主要負責(zé)代表組織和其他組織進行信息交換。每個組織都有一個錨節(jié)點诡挂，錨節(jié)點對于組織來說非常重要碎浇，如果錨節(jié)點出現(xiàn)問題临谱，當(dāng)前組織就會與其他組織失去聯(lián)系璃俗。錨節(jié)點的配置信息是在configtxgen模塊的配置文件configtx.yaml中配置的。錨節(jié)點只能有一個悉默。
主節(jié)點：peer節(jié)點還可以是主節(jié)點（leader peer）城豁，能與排序服務(wù)節(jié)點通信，負責(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)的組織編號苫拍、域名芜繁、證書等），然后再確認組織的管理方式绒极。組織的管理方式是指組織在遇到問題時的協(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脓钾，負責(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 中的默認鍵值對（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导狡，一種遵循標準的利用公鑰加密技術(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)的變化達成一致性的認同贫橙。
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é)點負責(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ù)的排序才可以達成全網(wǎng)共識，因此排序服務(wù)要避免成為網(wǎng)絡(luò)上的性能瓶頸腥泥。
3.校驗
校驗（Validation）階段是節(jié)點對排序后的交易進行一系列的檢驗匾南，包括交易數(shù)據(jù)的完整性檢查、是否重復(fù)交易蛔外、背書簽名是否符合背書策略的要求蛆楞、交易的讀寫集是否符合多版本并發(fā)控制MVCC（Multiversion Concurrency Control）的校驗等溯乒。當(dāng)交易通過了所有校驗后，將被標注為合法并寫入賬本中豹爹。因為所有的確認節(jié)點都按照相同的順序檢驗交易裆悄，并且把合法的交易依次寫入賬本中，因此不同確認節(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)用的合約標識、合約方法和參數(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é)點唧领。其中生成交易的過程很簡單，只需要確認所有背書節(jié)點的執(zhí)行結(jié)果完全一致雌续，再將交易提案斩个、提案響應(yīng)和背書簽名打包生成交易即可。 - 排序服務(wù)節(jié)點對交易進行排序并生成區(qū)塊
排序服務(wù)節(jié)點接收到網(wǎng)絡(luò)中所有通道發(fā)出的交易信息西雀，讀取交易信封獲取通道名稱萨驶，按各個通道上交易的接收時間順序?qū)灰仔畔⑦M行排序（多通道隔離），生成區(qū)塊艇肴。（在這個過程中腔呜，排序服務(wù)節(jié)點不會關(guān)心交易是否正確，只是負責(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)運維仗岖，負責(zé)系統(tǒng)的部署與維護；其次是組織管理人員览妖，負責(zé)證書轧拄、MSP權(quán)限管理、共識機制等讽膏；最后是業(yè)務(wù)開發(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唯一標識，nonce）消息到B遠程節(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）沟涨，提供一組認證相關(guān)的密碼學(xué)機制和協(xié)議，用來負責(zé)對網(wǎng)絡(luò)提供證書分發(fā)异吻、校驗裹赴，身份認證管理等。一些成員管理的實現(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
