Hyperledger fabric基本概念
首先fabric是由IBM貢獻(xiàn)的超級賬本框架济瓢。它是一個利用現(xiàn)有成熟的技術(shù)來組合而成的一個區(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ù)，如下面的圖所示氛濒。
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)組件描述了一個給定時間點(diǎn)的賬本狀態(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)用交易指的是運(yùn)行鏈代碼哮塞，鏈代碼執(zhí)行時可能會修改相應(yīng)的狀態(tài)刨秆，并返回輸出。
下圖是一個交易的詳細(xì)結(jié)構(gòu)：
交易頭：包含交易的元數(shù)據(jù)忆畅，如鏈碼名稱衡未、版本等
交易簽名：包含由客戶端應(yīng)用程序創(chuàng)建的加密簽名，作用是判斷交易是否被篡改
交易提案：作用是對由應(yīng)用程序提供給智能合約的輸入?yún)?shù)進(jìn)行編碼家凯。當(dāng)智能合約運(yùn)行時缓醋，提案負(fù)責(zé)將參數(shù)傳遞過去
交易響應(yīng)：是智能合約的輸出，包含的是世界狀態(tài)在交易前后的值绊诲，以讀寫集的形式展示送粱。
節(jié)點(diǎn): 是區(qū)塊鏈的通信實(shí)體，是一個邏輯概念掂之，不同類型的多個節(jié)點(diǎn)可以運(yùn)行在同一個物理服務(wù)器上抗俄。節(jié)點(diǎn)主要有以下四種：
1.客戶端節(jié)點(diǎn)：客戶端必須連接到某一個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)會定期從orderer節(jié)點(diǎn)獲取包含交易的區(qū)塊读跷，在對這些區(qū)塊進(jìn)行核發(fā)驗(yàn)證之后，會把這些區(qū)塊加入到區(qū)塊鏈中禾唁。committer節(jié)點(diǎn)無法通過配置文件配置效览，需要在當(dāng)前客戶端或者命令行發(fā)起交易請求的時候手動指定相關(guān)的committer節(jié)點(diǎn)。記賬節(jié)點(diǎn)可以有多個荡短。
背書節(jié)點(diǎn)：部分節(jié)點(diǎn)還會執(zhí)行交易并對結(jié)果進(jìn)行簽名背書丐枉，充當(dāng)背書節(jié)點(diǎn)（endorser）的角色。背書節(jié)點(diǎn)是動態(tài)的角色掘托，是與具體鏈碼綁定的瘦锹。每個鏈碼在實(shí)例化的時候都會設(shè)置背書策略，指定哪些節(jié)點(diǎn)對交易背書后交易才是有效的闪盔。并且只有應(yīng)用程序向它發(fā)起交易背書請求的時候才是背書節(jié)點(diǎn)弯院，其他時候都是普通的記賬節(jié)點(diǎn)，只負(fù)責(zé)驗(yàn)證交易并記賬泪掀。背書節(jié)點(diǎn)也無法通過配置文件指定听绳，而是由發(fā)起交易請求的客戶端指定。背書節(jié)點(diǎn)可以有多個异赫。
錨節(jié)點(diǎn)：peer節(jié)點(diǎn)還可以是錨節(jié)點(diǎn)（anchor peer）椅挣，錨節(jié)點(diǎn)主要負(fù)責(zé)代表組織和其他組織進(jìn)行信息交換。每個組織都有一個錨節(jié)點(diǎn)祝辣，錨節(jié)點(diǎn)對于組織來說非常重要贴妻，如果錨節(jié)點(diǎn)出現(xiàn)問題，當(dāng)前組織就會與其他組織失去聯(lián)系蝙斜。錨節(jié)點(diǎn)的配置信息是在configtxgen模塊的配置文件configtx.yaml中配置的名惩。錨節(jié)點(diǎn)只能有一個。
主節(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)在整個組織中只能有一個。
3.排序服務(wù)節(jié)點(diǎn)orderer：接收包含背書簽名的交易弯予，對未打包的交易進(jìn)行排序生成區(qū)塊戚宦，廣播給peer節(jié)點(diǎn)。排序服務(wù)提供的是原子廣播锈嫩，保證同一個鏈上的節(jié)點(diǎn)接收到相同的信息受楼，并且有相同的邏輯順序。
4.CA節(jié)點(diǎn)：fabric1.0的證書頒發(fā)機(jī)構(gòu)呼寸，由服務(wù)器和客戶端組成艳汽。CA節(jié)點(diǎn)接收客戶端的注冊申請，返回注冊密碼用于用戶登錄对雪，以便獲取身份證書河狐。區(qū)塊鏈上的所有操作都需要驗(yàn)證用戶身份。
fabric系統(tǒng)邏輯結(jié)構(gòu)圖
org：fabric系統(tǒng)是通過組織來劃分的瑟捣，每個組織內(nèi)都有承擔(dān)不同功能的peer節(jié)點(diǎn)馋艺，同時每個組織都有自己對應(yīng)的fabric-ca服務(wù)器，fabric系統(tǒng)中所有的組織共用一個orderer集群迈套。fabric中的組織在現(xiàn)實(shí)世界中可以是一個公司捐祠、一個企業(yè)，或者一個協(xié)會交汤。在fabric中雏赦，組織是承擔(dān)著數(shù)據(jù)信用責(zé)任的區(qū)塊鏈系統(tǒng)參與方。
在設(shè)計(jì)一個fabric系統(tǒng)時芙扎，第一步就是要確定系統(tǒng)的參與方，然后從這些參與者中選出組織（生成對應(yīng)的組織編號填大、域名戒洼、證書等），然后再確認(rèn)組織的管理方式允华。組織的管理方式是指組織在遇到問題時的協(xié)作方式（如新組織的加入）圈浇。
channel：fabric的數(shù)據(jù)存儲結(jié)構(gòu)被設(shè)計(jì)成多賬本體系，每個賬本在fabric中被稱為channel靴寂。每個channel中都有一個完全獨(dú)立的賬本磷蜀。同一個channel中的所有peer節(jié)點(diǎn)都保存一份相同的數(shù)據(jù)。
通道由成員（組織）百炬、每個成員的錨節(jié)點(diǎn)褐隆、賬本、鏈碼應(yīng)用程序和排序服務(wù)節(jié)點(diǎn)定義剖踊。網(wǎng)絡(luò)上的每個交易都是在一個通道上執(zhí)行的庶弃，在該通道上衫贬，每一方都必須經(jīng)過身份驗(yàn)證和授權(quán)才能在該通道上進(jì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ù)雜，所以維護(hù)了3個MSP歇僧。
數(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 鍵值存儲一樣祸轮，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ǔ)平臺的技術(shù)和規(guī)范。
底層采用P2P網(wǎng)絡(luò)和gRPC協(xié)議實(shí)現(xiàn)對分布式賬本結(jié)構(gòu)的連通舷夺。通過Gossip協(xié)議進(jìn)行狀態(tài)同步苦酱、數(shù)據(jù)分發(fā)和成員探測。
共識：Fabric區(qū)塊鏈的網(wǎng)絡(luò)節(jié)點(diǎn)本質(zhì)上是互相復(fù)制的狀態(tài)機(jī)给猾，節(jié)點(diǎn)之間需要保持相同的賬本狀態(tài)疫萤。為了實(shí)現(xiàn)分布式節(jié)點(diǎn)的一致性，各個節(jié)點(diǎn)需要通過共識過程敢伸，對賬本狀態(tài)的變化達(dá)成一致性的認(rèn)同扯饶。
Fabric區(qū)塊鏈的共識過程包括3個階段：背書、排序和校驗(yàn)。
1.背書
在背書（endorsement）階段中帝际，背書節(jié)點(diǎn)對客戶端發(fā)來的交易提案進(jìn)行合法性校驗(yàn)蔓同，然后模擬執(zhí)行鏈碼得到交易結(jié)果，最后根據(jù)設(shè)定的背書邏輯判斷是否支持該交易提案蹲诀。如果背書邏輯決定支持交易提案斑粱，會把交易提案簽名后發(fā)回給客戶端。
客戶端通常需要根據(jù)鏈碼的背書策略脯爪，向一個或者多個成員的背書節(jié)點(diǎn)發(fā)出背書請求则北。背書策略會定義需要哪些節(jié)點(diǎn)背書交易才有效，例如需要5個成員的背書節(jié)點(diǎn)中至少3個同意痕慢；或者某個特殊身份的成員支持等尚揣。客戶端只有在收集足夠多的背書節(jié)點(diǎn)的交易提案簽名掖举，交易才能被視為有效快骗。
2.排序
排序（ordering）階段就是由排序服務(wù)節(jié)點(diǎn)對交易進(jìn)行排序，確定交易之間的時序關(guān)系塔次。排序服務(wù)把一段時間內(nèi)收到的交易進(jìn)行排序方篮，然后把排序后的批量交易打包成數(shù)據(jù)塊（區(qū)塊），再把區(qū)塊廣播給通道中的成員励负。采用排序共識方式藕溅，各個成員收到的是一組發(fā)生順序相同的交易，從而保證了所有節(jié)點(diǎn)的數(shù)據(jù)一致性继榆。
目前巾表，Hyperledger Fabric有三種交易排序算法：Solo、Kafka略吨、SBFT集币。
Solo：只有一個排序服務(wù)節(jié)點(diǎn)負(fù)責(zé)接收交易信息并排序，是最簡單的一種排序算法翠忠，一般用于開發(fā)測試環(huán)境中惠猿。Solo共識模式屬于中心化的處理方式，不支持拜占庭容錯负间。
Kafka：Kafka是Apache的一個開源項(xiàng)目，主要提供分布式的消息處理／分發(fā)服務(wù)姜凄，每個Kafka集群由多個服務(wù)節(jié)點(diǎn)組成政溃。Hyperledger Fabric利用Kafka對交易信息進(jìn)行排序處理，提供高吞吐态秧、低延時的處理能力董虱，并且在集群內(nèi)部支持節(jié)點(diǎn)故障容錯，但不支持拜占庭容錯。
SBFT：簡單拜占庭算法愤诱，支持拜占庭容錯的可靠排序算法云头，包括容忍節(jié)點(diǎn)故障以及一定數(shù)量的惡意節(jié)點(diǎn)。
排序服務(wù)是共識機(jī)制中重要的一環(huán)淫半，所有交易都要通過排序服務(wù)的排序才可以達(dá)成全網(wǎng)共識溃槐，因此排序服務(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)能夠始終保持一致势告。
交易流程：前提假設(shè)是各節(jié)點(diǎn)已經(jīng)提前頒發(fā)好證書蛇捌，且已正常啟動，并加入已經(jīng)創(chuàng)建好的通道培慌。此流程介紹的是在已經(jīng)實(shí)例化了的鏈碼通道上從發(fā)起一個調(diào)用交易到最終結(jié)賬的全過程豁陆。
- 提交交易提案
應(yīng)用程序（客戶端節(jié)點(diǎn)）構(gòu)造好交易提案（交易提案中包含本次交易要調(diào)用的合約標(biāo)識、合約方法和參數(shù)信息以及客戶端簽名等）請求后吵护，根據(jù)背書策略選擇背書節(jié)點(diǎn)執(zhí)行交易提案并進(jìn)行背書簽名盒音。背書節(jié)點(diǎn)是鏈代碼中背書策略指定的節(jié)點(diǎn)。正常情況下背書節(jié)點(diǎn)執(zhí)行后的結(jié)果是一致的馅而，只有背書節(jié)點(diǎn)對結(jié)果的簽名不一樣祥诽。
- 模擬執(zhí)行提案并進(jìn)行背書
背書節(jié)點(diǎn)在收到交易提案后會進(jìn)行一些驗(yàn)證，驗(yàn)證通過后瓮恭，背書節(jié)點(diǎn)會根據(jù)當(dāng)前賬本數(shù)據(jù)模擬執(zhí)行鏈碼中的業(yè)務(wù)邏輯并生成讀寫集（RwSet）雄坪。模擬執(zhí)行時不會更新賬本數(shù)據(jù)。然后背書節(jié)點(diǎn)對這些讀寫集進(jìn)行簽名生成提案響應(yīng)（proposal response）屯蹦，然后返回給應(yīng)用程序维哈。 - 收集交易的背書（返回模擬執(zhí)行結(jié)果）
應(yīng)用程序收到proposal response后會對背書節(jié)點(diǎn)的簽名進(jìn)行驗(yàn)證（所有節(jié)點(diǎn)接收到任何消息時都需要先驗(yàn)證消息的合法性）。如果鏈碼只進(jìn)行賬本查詢操作登澜，應(yīng)用程序只需要檢查查詢響應(yīng)阔挠，并不會將交易提交給排序服務(wù)節(jié)點(diǎn)。如果鏈碼對賬本進(jìn)行了invoke操作脑蠕，則需要提交交易給排序服務(wù)進(jìn)行賬本更新（提交前會判斷背書策略是否滿足）购撼。
- 構(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)和背書簽名打包生成交易即可毫玖。 - 排序服務(wù)節(jié)點(diǎn)對交易進(jìn)行排序并生成區(qū)塊
排序服務(wù)節(jié)點(diǎn)接收到網(wǎng)絡(luò)中所有通道發(fā)出的交易信息，讀取交易信封獲取通道名稱谐腰，按各個通道上交易的接收時間順序?qū)灰仔畔⑦M(jìn)行排序（多通道隔離）孕豹，生成區(qū)塊。（在這個過程中十气，排序服務(wù)節(jié)點(diǎn)不會關(guān)心交易是否正確励背，只是負(fù)責(zé)排序和打包。交易的有效性在第7步進(jìn)行驗(yàn)證）
- 排序服務(wù)節(jié)點(diǎn)廣播區(qū)塊給主節(jié)點(diǎn)
排序服務(wù)節(jié)點(diǎn)生成區(qū)塊后會廣播給通道上不同組織的主節(jié)點(diǎn)砸西。 - 記賬節(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ū)塊后芹枷，會驗(yàn)證區(qū)塊交易的有效性衅疙，然后提交到本地賬本并產(chǎn)生一個生成區(qū)塊的事件，監(jiān)聽區(qū)塊事件的應(yīng)用程序會進(jìn)行后續(xù)的處理鸳慈。（如果接收的是配置區(qū)塊饱溢，則會更新緩存的配置信息） - 主節(jié)點(diǎn)在組織內(nèi)部同步最新的區(qū)塊
如果交易是無效的，也會更新區(qū)塊走芋，但不會更新世界狀態(tài)绩郎。（區(qū)塊存儲的是操作語句，而世界狀態(tài)存儲的是被處理的數(shù)據(jù)）
fabric聯(lián)盟鏈的開發(fā)人員主要分為三類：底層是系統(tǒng)運(yùn)維翁逞，負(fù)責(zé)系統(tǒng)的部署與維護(hù)肋杖；其次是組織管理人員，負(fù)責(zé)證書挖函、MSP權(quán)限管理状植、共識機(jī)制等；最后是業(yè)務(wù)開發(fā)人員怨喘，他們負(fù)責(zé)編寫chaincode津畸、創(chuàng)建維護(hù)channel、執(zhí)行transaction交易等必怜，如下面的圖所示洼畅。
我們的開發(fā)流程主要包括寫智能合約，以及通過SDK調(diào)用智能合約棚赔，及訂閱各類事件，如圖所示。
下面是fabric中各個包的大概內(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ū)動開發(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ā)平臺的一些腳本蒋川。主要包含了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算法秧廉。一個基于pull的gossip算法的實(shí)現(xiàn)。最終確保狀態(tài)一致拣帽。 該協(xié)議大致如下：
1）A發(fā)起者發(fā)送Hello（B唯一標(biāo)識疼电，nonce）消息到B遠(yuǎn)程節(jié)點(diǎn)（多個）。
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)的配置和腳本。主要包括各個鏡像的 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)中判耕，共識功能被抽取出來，作為單獨(dú)的 fabric-orderer 模塊來實(shí)現(xiàn)翘骂，完成核心的排序功能壁熄。最核心的功能是實(shí)現(xiàn)從客戶端過來的 broadcast 請求帚豪，和從 orderer 發(fā)送到 peer 節(jié)點(diǎn)的 deliver 接口。同時请毛，orderer 需要支持多 channel 的維護(hù)志鞍。主要包含Solo、kafka及bft三個方法方仿。
十四，peer ??
peer節(jié)點(diǎn)的相關(guān)主命令模塊统翩。作為服務(wù)端時候仙蚜，支持 node 子命令；作為命令行時候厂汗，支持 chaincode委粉、channel 等子命令。其中包含一些命令操作的實(shí)現(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來進(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 信息文件等忆绰。
測試網(wǎng)絡(luò)
重新打開一個命令行窗口浩峡，輸入：
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
然后類似于啟動指令：
./network_setup.sh down
