HyperLedger Fabric 模塊入門
這篇博客作為最近一段時間對 hyperledger 官方文檔學習的一個總結(jié)黎茎，主要歸納一下 hyperledger 中一些重要組件的作用和重要功能的流程当悔。
Fabric概覽
一個 hyperldger 應用包含了這幾個模塊先鱼， 客戶端應用（applications），節(jié)點（peers）焙畔，組織（orgnizations）宏多，排序節(jié)點（orderer），成員關系服務提供者（MSP）肾请，渠道（channel）铛铁，賬本（ledger）却妨，智能合約（smart contract）等模塊。
一個 Hyperledger 應用的大致流程主要是以下幾個步驟 ：
- 應用（application ）發(fā)起一個請求（proposal）到 hyperledger 網(wǎng)絡中彪标，這個請求將被網(wǎng)絡中指定的節(jié)點（peer）所驗證并執(zhí)行對應的鏈代碼（chaincode）
- 網(wǎng)絡中的節(jié)點（peers）需要提前安裝（install）對應的鏈代碼（chaincode）捞烟，并在節(jié)點所屬的渠道（channel）中進行初始化（instantiate）才能為客戶端應用所調(diào)用。（應用是怎么確保請求數(shù)據(jù)為有權(quán)限的節(jié)點所接受并執(zhí)行相應的 chaincode 邏輯默辨？婴程？档叔？）
- 節(jié)點將根據(jù)請求數(shù)據(jù)作為輸入的參數(shù)桌粉，調(diào)用 chaincode 執(zhí)行相應的邏輯并封裝成一個請求響應（proposal response）返回給客戶端應用衙四。 此時執(zhí)行的邏輯并不會更改節(jié)點本地的賬本（ledger）的狀態(tài)
- 客戶端接收到多個節(jié)點（peers）返回的請求響應數(shù)據(jù)传蹈，并把這些數(shù)據(jù)封裝成一個交易對象（transaction），發(fā)送給網(wǎng)絡中的排序節(jié)點（orderer）
- 網(wǎng)絡中的排序節(jié)點（orderer）在接收到交易對象后挑格，將通過 MSP 等對交易信息進行驗證并排序沾歪，并將來自不同應用的交易對象進行排序灾搏，打包成塊（block），并將打包的塊分發(fā)（distribute）到渠道中的各個節(jié)點上進行驗證媳板。
- 當節(jié)點驗證塊中的交易數(shù)據(jù)后泉哈，將會更新自己本地維護的賬本（ledger）的副本數(shù)據(jù)丛晦，并通過響應的通知機制通知客戶端應用請求已被加入到賬本中
這是一個 hyperldger 應用中大致的交易流程。接下來回顧一下在這個過程中將涉及到的一些模塊組件采呐。
身份 （Identity）
身份信息決定了一個角色在 hyperledger 網(wǎng)絡中對網(wǎng)絡資源和信息的訪問權(quán)限斧吐。hyperledger 定義的原則（principle）煤率，即是身份和其附帶的屬性信息所構(gòu)成。
這涉及到的兩個知識點洋只，包括 PKI 和 MSP， 在官方文檔的例子中肢扯，PKI 就像提供了一張可用身份信息的列表蔚晨，而 MSP 則決定了在這個列表中肛循，有哪些身份信息是可以參與到網(wǎng)絡中指定的機構(gòu)中的。
PKI累舷，即 public key infrastructure被盈， 包含了
- 向機構(gòu)分發(fā)數(shù)字證書（digital certificate）的證書機構(gòu)（Certificate Authority）析蝴，機構(gòu)通過數(shù)字證書，來向其他機構(gòu)驗證自己在網(wǎng)絡中的身份信息尝盼。
- 一個 CRL 佑菩，certificate revocation list，廢除證書列表赴精，通過這個列表可以查詢到已經(jīng)不再使用的列表 （這個和證書過期是不太一樣的）蕾哟。
- 一個公鑰（public key）和私鑰（private key）的架構(gòu)莲蜘。
這里注意的是谭确，證書機構(gòu) （ca）逐哈，是可以分成根機構(gòu)（Root CA）和中間機構(gòu)（Intermediate CA）的昂秃。根機構(gòu)可以通過向中間機構(gòu)簽發(fā)證書的形式拓展下級中間機構(gòu)，下級中間機構(gòu)還可以繼續(xù)拓展自己的中間機構(gòu)從而形成一條證書機構(gòu)連肠骆。因此哗戈，一個證書機構(gòu)要么是一個根機構(gòu)郊艘，要么就是可以通過機構(gòu)鏈回溯到根機構(gòu)的中間機構(gòu)荷科。
鏈代碼（ChainCode）和賬本（Ledger）
ChainCode 和 Ledger 唯咬，構(gòu)成了 Hyperledger Fabric 網(wǎng)絡中的核心。
ChainCode 和合約 （Contract）的關系畏浆，可以理解為一個 ChainCode 包含了多個 Contract胆胰， Contract 包含了控制交易的邏輯，而 ChainCode 則負責打包 Contract 并將其部署到網(wǎng)絡節(jié)點上并為客戶端應用所調(diào)用刻获。
賬本包含了兩個獨立的模塊蜀涨，一個是區(qū)塊鏈（Blockchain），這個是存儲了整個不可被改變的交易歷史的數(shù)據(jù)結(jié)構(gòu)蝎毡，和一個全局狀態(tài)（world state）厚柳，保存了由歷史交易產(chǎn)生的狀態(tài)的當前的值，通過這個模塊沐兵，可以直接查詢到賬本中的當前狀態(tài)值而不同通過回溯整個賬本去計算碳想。
這里涉及到一個認證策略（endorsement policy）， 認證策略是關聯(lián)在每一個 chaincode 中誊涯，并應用到所有 chaincode 所包含的 contract 中的，其代表的是一個由該合約所產(chǎn)生的交易必須要經(jīng)過網(wǎng)絡中指定的機構(gòu)（ organization）的簽名才能被網(wǎng)絡標志位有效的交易巷嚣。
注意窘拯，所有的由排序節(jié)點分發(fā)的塊都會被拼接到網(wǎng)絡中的賬本（ledger）中暇番，不管是有效的還是無效的，只是增加了一個有效和無效的標志
排序服務（Ordering Service）
排序節(jié)點的引入是為了解決分布式區(qū)塊鏈中舆乔，例如以太坊或者比特幣這種沒有權(quán)限限制的網(wǎng)絡中，由于各個節(jié)點同時參與交易的排序和塊的打包颜武，最終可能導致分叉（fork）的情況。多個排序節(jié)點共同構(gòu)成一個排序服務篙议。
- 排序節(jié)點和通道配置
排序節(jié)點的另一個作用就是維護一個允許創(chuàng)建渠道（channel）的組織列表，這個列表即所說的聯(lián)盟（consortium）吩愧，這里列表是保存在排序系統(tǒng)渠道配置（orderer system channel 或
ordering system channel）中的同云。默認這個列表和列表依賴的配置星澳，只能被系統(tǒng)管理員修改禁偎。
排序節(jié)點也限制了對各個通道的讀笆檀，寫和配置的權(quán)限。修改一個通道的配置元素需要對應于創(chuàng)建時所對應的政策和管理員設置樱衷。一個配置事務（Configuration Transaction）需要經(jīng)過排序節(jié)點的驗證后封字，才能被分發(fā)到渠道中的節(jié)點中流妻，最終才能被渠道中的節(jié)點所驗證并執(zhí)行。
- 排序節(jié)點和身份驗證
與區(qū)塊鏈網(wǎng)絡交互的所有內(nèi)容（包括peer，application浑度，admin和排序節(jié)點）都會從其數(shù)字證書及其成員服務提供商（MSP）定義中獲取對應的組織身份。
和 peer 節(jié)點一樣先慷， 排序節(jié)點也屬于一個組織機構(gòu)
- 排序節(jié)點在交易流程中的作用
一個應用在需要對網(wǎng)絡中的賬本進行修改的時候摄狱，首先請求網(wǎng)絡中部署了智能合約的節(jié)點誉券，
獲取對應的請求響應（proposal response）踩验，在將這些返回的響應傳遞給排序節(jié)點進行驗證，打包和分發(fā)排序節(jié)點在接收到應用的請求數(shù)據(jù)時袭异，對來自各個應用的交易進行驗證御铃，并對其排序并打包到一個塊中羹膳，之后將打包的數(shù)據(jù)分發(fā)到通道中就珠。
排序節(jié)點所連接的 peer 節(jié)點醒颖，在接收到排序節(jié)點分發(fā)的塊之后蹂季，對其進行驗證涕滋，并最終更新到當前節(jié)點保存的通道中的賬本的副本中，并返回響應給請求的應用丰刊。
Fabric 提供了 solo秩仆， Raft 和 Kafka 模式的排序服務的實現(xiàn)齐莲。具體可查看官網(wǎng)解釋搀捷。
成員關系（Membership）
在 HyperLedger Fabric 中家厌，PKI 提供了一個可驗證的身份信息维蒙，這些身份信息可以用來驗證節(jié)點是否網(wǎng)絡中的被信任的成員。
而這就是MSP（Membership Service Provider）所做的事情钳榨。MSP驗證了哪個根證書機構(gòu)（Root CA）或者中間證書機構(gòu)（Intermediate CA）可以用來定義一個組織的成員關系赏陵。此外，MSP還定義了一個成員在一個網(wǎng)絡中所扮演的角色并設置在了網(wǎng)絡或者渠道中的訪問權(quán)限（例如：讀，寫）。
MSP的配置被廣播到所有MSP所代表的組織的成員所參與的通道中，這個稱為渠道MSP（Channel MSP）。與此同時，像節(jié)點和排序節(jié)點，也會維護一個MSP，用于驗證當前通道之外的成員信息，來定義對特定資源的訪問權(quán)限（例如：是否可以在節(jié)點上部署ChainCode）。
本地和渠道MSP之間的關鍵區(qū)別不在于它們?nèi)绾芜\作 - 都是將身份轉(zhuǎn)變?yōu)榻巧?- 而是他們的作用范圍。
MSP 大致分為四種：
- 網(wǎng)絡MSP ：定義了網(wǎng)絡中的成員
- 通道MSP ：定義了通道中的成員
- 節(jié)點MSP ：只用于定義該MSP的節(jié)點中，最常見的使用場景是 chaincode 在節(jié)點中的安裝
- 排序節(jié)點MSP ：只用于定義該MSP的節(jié)點中，用于列舉信任的節(jié)點和角色
成員關系的驗證，除了 CA 和 MSP 之外棚唆，還包括了其他的組件瞎惫。
功能描述參考官網(wǎng)對 Membership 的詳述
