A. 淺析 Fabric Peer 節點
Hyperledger Fabric，也稱之為超級賬本，是由 IBM 發起，後成為 Linux 基金會 Hyperledger 中的區塊鏈項目之一。
Fabric 是一個提供分布式賬本解決方案的平台，底層的賬本數據存儲使用了區塊鏈。區塊鏈平台通常可以分為公有鏈、聯盟鏈和私有鏈。公有鏈典型的代表是比特幣這些公開的區塊鏈網路，誰都可以加入到這個網路中。聯盟鏈則有準入機制，無法隨意加入到網路中，聯盟鏈的典型例子就是 Fabric。
Fabric 不需要發幣來激勵參與方，也不需要挖礦來防止有人作惡，所以 Fabric 有著更好的性能。在Fabric 網路中，也有著諸多不同類型的節點來組成網路。其中 Peer 節點承載著賬本和智能合約，是整個區塊鏈網路的基礎。在這篇文章中，會詳細分析 Peer 的結構及其運行方式。
在本文中，假設讀者已經了解區塊鏈、智能合約等概念。
本文基於 Fabric1.4 LTS。
區塊鏈網路是一個分布式的網路，Fabric 也是如此，由於 Fabric 是聯盟鏈，需要准入機制，所以在網路結構上會復雜很多，下面是一個簡化的 Fabric 網路：
各個元素的含義如下：
對於 Fabric 網路，外部的用戶需要通過客戶端應用，也就是圖中的 A1、A2 或者 A3 來訪問網路，客戶端應用需要通過 CA 證書表明自己的身份，這樣才能訪問到 Fabric 網路中有許可權訪問的部分。
在上面的網路中，共有四個組織，R1、R2、R3 和 R4。其中 R4 是整個 Fabric 網路的創建者，網路是根據 NC4 配置的。
在 Fabric 網路中，不同的組織可以組成聯盟，不同的聯盟之間數據通過 Channel 來隔離。Channel 中的數據只有該聯盟中的組織才能訪問，每一個新的 Channel 都可以認為是一條新的鏈。與其他的區塊鏈網路中通常只有一條鏈不一樣，Fabric 可以通過 Channel 在網路中快速的搭建出一個新的區塊鏈。
上面 R1 和 R2 組成了一個聯盟，在 C1 上交易。R2 同時又和 R3 組成了另外一個聯盟，在 C2 上交易。R1 和 R2 在 C1 上交易時，對 R3 是不可見的，R2 和 R3 在 C2 上交易時，對 R1 是不可見的。Channel 機制提供了很好的隱私保護能力。
Orderer 節點是整個 Fabric 網路共有的，用來為所有的交易排序、打包。比如上面網路中 O4 節點。本文不會對 Orderer 節點進行詳細說明，可以把這個功能理解為比特幣網路中的挖礦過程。
Peer 節點表示網路中的節點，通常一個 Peer 就表示一個組織，Peer 是整個區塊鏈網路的基礎，是智能合約和賬本的載體，Peer 也是本文討論的重點。
一個 Peer 節點可以承載多套賬本和智能合約，比如 P2 節點，既維護了 C1 的賬本和智能合約，也維護了 C2 的賬本和智能合約。
為了可以更深入了解 Peer 節點的作用，先了解一下 Fabric 整體的交易流程。整體的交易流程圖如下：
Peer 節點按照功能來分可以分為 背書節點 和 記賬節點 。
客戶端會提交交易請求到背書節點，背書節點開始模擬執行交易，在模擬執行之後，背書節點並不會去更新賬本數據，而是把這個交易進行加密和簽名，然後返回給客戶端。
客戶端收到這個響應之後就會把響應提交到 Orderer 節點，Orderer 節點會對這些交易進行排序，並打包成區塊，然後分發到記賬節點，記賬節點就會對交易進行驗證，驗證結束之後，就會把交易記錄到賬本裡面。
一筆交易是否能成功是根據背書策略來指定的，每一個智能合約都會指定一個背書策略。
Peer 節點代表著聯盟鏈中的各個組織，區塊鏈網路也是由 Peer 節點來組成的，而且也是賬本和智能合約的載體。
通過對上面交易過程的了解可以知道，Peer 節點是主要的參與方。如果用戶想要訪問賬本資源，都必須要和 peer 節點進行交互。在一個 Peer 節點中，可以同時維護多個賬本，這些賬本屬於不同的 Channel 。每個 Peer 節點都會維護一套冗餘賬本，這樣就避免了單點故障。
Peer 節點根據在交易中的不同角色，可以分成背書節點（Endorser）和記賬節點（Committer），背書節點會對交易進行模擬執行，記賬節點才會真正將數據存儲到賬本中。
賬本可以分成兩個部分，一部分是區塊鏈，另一部分是 Current State，也被稱之為 World State。
區塊鏈上只能追加，不能對過去的數據進行修改，鏈上也包含兩部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的記錄。每一個區塊記錄前一個區塊的信息，然後連成鏈，如下圖所示：
第一個區塊被稱之為 genesis block，其中不存儲交易信息。每個區塊可以被分為 區塊頭 、 區塊數據 和 區塊元數據 。區塊頭中存儲著當前區塊的區塊號、當前區塊的 hash 值和上一個區塊的 hash 值，這樣才能把所有的區塊連接起來。區塊數據中包含了交易數據。區塊元數據中則包括了區塊寫入的時間、寫入人及簽名。
其中每一筆交易的結構如下，在 Header 中，包含了 ChainCode 的名稱、版本信息。Signature 就是交易發起用戶的簽名。Proposal 中主要是一些參數。Response 中是智能合約執行的結果。Endorsements 中是背書結果返回的結果。
WorldState中維護了賬本的當前狀態，數據以 Key-Value 的形式存儲，可以快速查詢和修改，每一次對 WorldState 的修改都會被記錄到區塊鏈中。WorldState 中的數據需要依賴外部的存儲，通常使用 LevelDB 或者 CouchDB。
區塊鏈和 WorldState 組成了一個完整的賬本，World State 保證的業務數據的靈活變化，而區塊鏈則保證了所有的修改是可追溯和不可篡改的。
在交易完成之後，數據已經寫入賬本，就需要將這些數據同步到其他的 Peer，Fabric 中使用的是 Gossip 協議。Gossip 也是 Channel 隔離的，只會在 Channel 中的 Peer 中廣播和同步賬本數據。
智能合約需要安裝到 Peer 節點上，智能合約是訪問賬本的唯一方式。智能合約可以通過 Go、Java 等變成語言進行編寫。
智能合約編寫完成之後，需要打包到 ChainCode 中，每個 ChainCode 中可以包含多個智能合約。ChainCode 需要安裝，ChainCode 需要安裝到 Peer 節點上。安裝好了之後，ChainCode 需要在 Channel 上實例化，實例化的時候需要指定背書策略。
智能合約在實例化之後就可以用來與賬本進行交互了，流程圖如下：
用戶編寫並部署實例化智能合約之後，就可以通過客戶端應用程序來向智能合約提交請求，智能合約會對 WorldState 中數據進行 get、put 或者 delete。其中 get 操作直接從 WorldState 中讀取交易對象當前的狀態信息，不會去區塊鏈上寫入信息，但 put 和 delete 操作除了修改 WorldState，還會去區塊鏈中寫入一條交易信息，且交易信息不能修改。
區塊鏈上的信息可以通過智能合約訪問，也可以在客戶端應用通過 API 直接訪問。
Event 是客戶端應用和 Fabric 網路交互的一種方式，客戶端應用可以訂閱 Event，當 Event 發生時，客戶端應用就會接受到消息。
事件源可以兩類，一類是智能合約發出的 Event，另一類是賬本變更觸發的 Event。用戶可以從 Event 中獲取到交易的信息，比如區塊高度等信息。
在這篇文章中，首先介紹了 Fabric 整體的網路架構，通過對 Fabric 交易流程的分析，討論了 peer 節點在交易中的作用，然後詳細分析了 peer 節點所維護的賬本和智能合約，並分析了 peer 節點維護賬本以及 peer 節點執行智能合約的流程。
文 / Rayjun
[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html
[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/
[3] https://en.wikipedia.org/wiki/Gossip_protocol
B. 區塊鏈應用開發實例有哪些
政府管理
一些國家對去中心化數據管理框架來存儲公共數據的區塊鏈技術表示出了極大興趣，就如Essentia公司正在與芬蘭農業生產者和林主聯合會（Central Union of Agricultural Procers and Forest Owners）試點開發一個電子政務項目，該項目將應用區塊鏈技術使芬蘭各地的城鄉居民能查詢各種記錄，充分滿足居民和僱主需求，提高就業率。另外，利用該技術，還能提高政府運轉效率，讓居民能方便地查詢教育、公共記錄和投票等各種信息。
廢物回收
例如，中國的某智能廢物管理系統就採用了Waltonchain公司的RFID技術，利用Waltonchain的這種區塊鏈應用，能夠有效監督廢物水平，以提高管理運營效率和資源優化。
身份識別
素有 「加密谷」 之稱的瑞士城市楚格已經和合作公司Uport利用區塊鏈技術開發了一套身份認證系統，通過該身份認證系統，公民能很好地參與在線投票和進行居住證明。
邊境管制
EssenTIa公司一直在與荷蘭政府接洽，希望利用自己的區塊鏈技術為荷蘭政府建立一套邊境查驗系統，來審查往返阿姆斯特丹和倫敦的乘客。目前，兩國間歐洲之星高鐵乘客需要在多個地點接受邊境管制檢查。EssenTIa正在研究一種基於區塊鏈的解決方案，該解決方案將安全地存儲乘客數據，使得荷蘭方面的查驗記錄也能夠被英國的邊境機構審查到。區塊鏈技術將確保數據沒有被篡改，並且是可核實的准確數據。
健康醫療
眾所周知，醫療記錄非常分散而且容易出錯，不一致的數據處理流程會讓醫院和診所經常被迫處理一些不正確或不完整的患者記錄。而像美國麻省理工大學研發的區塊鏈電子病歷系統MedRec，就是使用區塊鏈技術來促進數據共享，同時，它也能提供認證和保密服務。
企業管理
作為微軟Azure應用的企業客戶，他們可以利用區塊鏈即服務（BaaS），這將使企業能夠在安全的託管環境中訪問智能合約和區塊鏈應用。另據媒體報道，Google也在開發一個專有的區塊鏈項目，用它來支持其基於雲的業務。而谷歌的母公司Alphabet正在開發一個分布式記帳項目，第三方將能夠使用項目來存儲谷歌雲服務的相關數據。
醫學數據
將病人記錄數字化的醫療中心不會在多個設備之間存儲數據，通常都是將數據統一保存在集中的伺服器上，而這就成了黑客的主要攻擊目標，英國國家醫療中心NHS醫院遭受的Wannacry攻擊就證明了這一點。但除此這外，即使忽略了安全風險，仍然存在碎片化的問題。目前，在全球不同城市的醫院，有50多種不同的電子醫療記錄系統（eHR）在運轉，通常在同一個城市中也會存在數十種不同的醫療應用系統。這些相互獨立的系統不能執行互操作調取，病人在各個醫院的數據最終只能分散在不同的數據存儲中心。
在病人生死攸關情形下，可靠醫療數據的對比缺乏和緩慢的運行效率將會是致命的，EssenTIa公司的應用框架通過使用基於區塊鏈的系統來解決所有這些問題，該系統將會存儲病人臨床相關的所有數據，無論地理邊界如何，都可以立即訪問獲取到這些數據。在該系統中，患者的病歷隱私也能得到保護，只有經過醫學授權的人才可以在特定時間段進行訪問。
音樂製作
區塊鏈技術的主要好處之一就是它消除了不必要的中間商或中間人，音樂行業就是一個典型的例子，在這個行業中，如果藝術家的效率低下就會直接導致他們獲得的報酬很低。此時，一些基於區塊鏈的項目就涌現出來，致力為音樂創作者尋求更公平的交易和商業環境，像前槍炮玫瑰樂隊鼓手馬特·索倫擔任總監的Artbit公司。
碳補償
作為一個高度工業化的國家，中國的環境改變是巨大的。2017年3月，IBM與能源區塊鏈實驗室（Energy-Blockchain Labs）聯合推出了Hyperledger Fabric區塊鏈項目，用它來對中國的碳資產進行發現，這不僅為跟蹤碳排放創建了一個可衡量和可審計的系統，也為尋求抵消能源消耗同時激勵綠色工業實踐的公司提供了一個可交易的市場。
供應鏈管理
供應鏈管理被認為是應用區塊鏈獲益較好的案例之一，因為它非常適合於這種貨物從發貨到收貨之間的快遞運送或製造商到商店的整個過程。IBM和沃爾瑪聯手在中國發起了區塊鏈食品安全聯盟，該項目還與京東公司共同合作運行，目的旨在改善食品的運送跟蹤和安全性保障，從而更容易對食品安全問題進行回溯。
事實證明，中國是區塊鏈項目的成熟試驗基地，另外它也是世界上第一個農產品（5.180， -0.25， -4.60%）區塊鏈的所在地。世界知名食品貿易商路易·德雷福斯公司（Louis Dreyfus Co）與荷蘭和法國銀行合作建立了一個區塊鏈技術項目，利用該項目技術，在向中國出售大豆的過程中，交易結算比傳統方法更快。
鑽石行業
世界上最著名的鑽石公司德比爾斯集團（De Beers Group）擁有自己的區塊鏈公司並已開始運營，其目的在於 「為平台上注冊的每一顆鑽石建立一個數字記錄」。考慮到人們對鑽石的來源、原產地道德標准，以及鑽石質量的風險，區塊鏈技術自然是一個很好的選擇，因為它的每一個記錄都是不可磨滅的，它將確保每一塊鑽石的自身電子數據和它本身一樣長存。
不動產交易
目前來說，烏克蘭是第一個利用區塊鏈技術促進財產交易的國家。著名科技網站TechCrunch創始人兼加密貨幣玩家邁克爾·阿林頓就是通過以太坊區塊鏈的智能合約，遠程來對其基輔的一處房產進行購入轉賣的，這項交易是由專業從事區塊鏈房地產交易的初創公司Propy完成的。
漁業
區塊鏈技術現在正被用來支持可持續漁業的發展。非法捕魚是這個行業的一個普遍問題，區塊鏈的分布式賬本技術提供了一種對捕獲來源、加工和出售方式的證明。這種「從漁網到餐桌」的供應鏈條允許檢查員確定所捕獲的魚是否來自侵犯人權的地區，或是受經濟制裁影響的國家。
藝術畫作
與鑽石交易類似，藝術品行業依賴於藝術品的出處和真實性，雖然區塊鏈無法鑒定一幅畫是原作還是贗品，但它可以用來證明這幅畫的之前擁有人身份。此外，區塊鏈技術現在也被用作一種藝術品獲取的手段，它能使有形的物品便捷地在世界任何地方進行交易和交換，而不需從安全的存儲地進行物理轉移。
公共設施
在澳大利亞的弗里曼特爾市，一個致力於分布式能源和水系統管理的項目正在使用區塊鏈技術，太陽能（3.340， -0.06， -1.76%）電池板正被用於陽光充足的地區，以獲取電能，然後用於加熱水和提供電力，所有這些能源轉化和使用信息都會被記錄在區塊鏈數據中。
而在智利，其國家能源委員會已經開始使用區塊鏈技術作為該國能源使用數據的驗證，一些敏感數據將存儲在區塊鏈中，這種技術應用，算是這個南美國家電力基礎設施現代化和安全運營的一種手段。
同性戀權利（LGBT Rights）
區塊鏈有助於建設 「粉紅經濟」，也有助於LGBT社區在不透露人們身份的情況下爭取屬於他們自己的權利，這是一個極其重要的問題，因為社會對同性戀群體的歧視犯罪經常出現，尤其是在那些以侵犯人權而臭名昭著的國家，同性戀是違法的，或者至少是不被允許的。
巨災債券（Catastrophe Bonds）
巨災債券可能是地震、海嘯和其他自然災害受害者的唯一希望。區塊鏈允許各方之間快速透明的和解，並能確保系統在無人操作下也能正常繼續運行，區塊鏈現在已經成功地用於巨災債券的結算機制中。
旅遊業
夏威夷當地機構正在研究如何利用區塊鏈技術來改善經濟，例如開通比特幣和其他貨幣支付手段，方便遊客對當地商品和服務費用的交易。利用這種方式，夏威夷政府希望大力吸引遊客，特別是來自亞洲的遊客，來當地花更多的錢，提升夏威夷的經濟發展。
國土安全
2016年，美國國土安全部（ DHS ）宣布了一個項目，該項目將利用區塊鏈技術作為安全存儲和捕獲數據傳輸的手段。DHS採用Factom公司的區塊鏈技術，加密存儲安全攝像頭和其他感測器捕獲的數據，這種區塊鏈技術的應用，將大大降低數據泄露的風險。目前，該項目仍在進行中。
航海運輸
區塊鏈用於記錄船舶運輸數據的好處不言而喻，目前，一些地方的船運項目已經了採用分布式賬本技術，在海運物流行業中，區塊鏈技術可以讓國際貿易中那些不可避免的繁瑣管理程序更加透明有序。全球最大的海運商之一 Maersk 是利用區塊鏈的先驅，如今，以星國際航運公司 ZIM 也已對區塊鏈技術進行跟進利用。
C. 超級賬本之——Fabric
目前超級賬本下面有5個並行的項目，Fabric屬於其中較為成熟的一個。這個項目由，來自28個不同組織的159名工程師參與開發。
在Fabric的區塊鏈網路中，有四類節點：MSP，Ordering Node，Endorsing Peer，Commtting Peer
MSP(Membership Service Provider), 這類節點主管區塊鏈網路中其他的節點的授權，准入，踢除。通過給不同節點頒發證書的方式，授予不同類型的節點相應的許可權。
中文可以稱作排序節點。通常在一個網路中至少有一個或多個排序節點，這類節點負責 按照指定的演算法，將交易進行排序，並返回給Committing Peer。其並不關心具體的交易細節。
這類節點的主要負責接收交易請求，驗證這筆交易之後，並做一些預處理之後，並將簽名後的數據傳回給客戶端。
這類節點做是區塊鏈網路中的全節點，它們需要記錄完整的區塊信息，並且驗證每筆交易的正確性，是最終將交易打包進區塊鏈的節點。
結合下面這種圖，看看一筆交易的上鏈過程：
1，首先從客戶端發起一筆交易提交到Endorsing Peer，進行預處理。
2，預處理通過之後，將簽名數據，傳回給客戶端。
3，客戶端發起請求，將收到的簽名數據傳給Ordering Node。
4，Ordering Node對交易進行排序，然後傳給Committing Peer。
5，Committing Peer這里將排序好的交易進行驗證，並打包，通過指定的共識演算法達成一致，形成新的區塊。
6，最後將交易結果返回給客戶端。
6，中間過程的每一步，都伴隨著許可權的驗證。會根據MSP頒發的證書，進行判斷。
D. 如何創建屬於自己的 fabric 區塊鏈
這個是需要藉助平台進行創建。
IBM中國研究院開發的超能雲（SuperVessel）平台提供了給區塊鏈愛好者、開發者的區塊鏈開發測試環境。通過該平台，用戶能夠免費、超快速創建基於Hyperledger Fabric的多節點區塊鏈、並在自己的鏈上花式玩轉智能合約。
當然，國外的去中心化內容分享平台DECENT也是可以創建的。
E. 區塊鏈 --- 共識演算法
PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算，並且其運算結果能被其他節點快速驗算，以耗用時間、能源做擔保，以確保服務與資源被真正的需求所使用。
PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r)，若原始數據為r（raw），則運算結果為R（Result）。
R = Hash(r)
哈希函數Hash()的特性是，對於任意輸入值r，得出結果R，並且無法從R反推回r。當輸入的原始數據r變動1比特時，其結果R值完全改變。在比特幣的PoW演算法中，引入演算法難度d和隨機值n，得到以下公式：
Rd = Hash(r+n)
該公式要求在填入隨機值n的情況下，計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性，每個礦工都要做大量運算之後，才能得出正確結果，而算出結果廣播給全網之後，其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源，而校驗僅需一次。
PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格，並且區域鏈系統在選定打包節點時使用隨機的方式，當節點質押的資金越多時，其被選定打包區塊的概率越大。
POS模式下，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000。這個時候，如果你驗證了一個POS區塊，你的幣齡就會被清空為0，同時從區塊中獲得相對應的數字貨幣利息。
節點通過PoS演算法出塊的過程如下：普通的節點要成為出塊節點，首先要進行資產的質押，當輪到自己出塊時，打包區塊，然後向全網廣播，其他驗證節點將會校驗區塊的合法性。
DPoS演算法和PoS演算法相似，也採用股份和權益質押。
但不同的是，DPoS演算法採用委託質押的方式，類似於用全民選舉代表的方式選出N個超級節點記賬出塊。
選民把自己的選票投給某個節點，如果某個節點當選記賬節點，那麼該記賬節點往往在獲取出塊獎勵後，可以採用任意方式來回報自己的選民。
這N個記賬節點將輪流出塊，並且節點之間相互監督，如果其作惡，那麼會被扣除質押金。
通過信任少量的誠信節點，可以去除區塊簽名過程中不必要的步驟，提高了交易的速度。
拜占庭問題：
拜占庭是古代東羅馬帝國的首都，為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊，將軍之間只能靠信差傳遞消息。在戰爭時，所有將軍必須達成共識，決定是否共同開戰。
但是，在軍隊內可能有叛徒，這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下，剩餘的將軍如何達成一致決策的問題。
BFT：
BFT即拜占庭容錯，拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因，計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為，並滿足所要解決的問題的規范要求。
拜占庭容錯系統 ：
發生故障的節點被稱為 拜占庭節點 ，而正常的節點即為 非拜占庭節點 。
假設分布式系統擁有n台節點，並假設整個系統拜占庭節點不超過m台（n ≥ 3m + 1），拜占庭容錯系統需要滿足如下兩個條件：
另外，拜占庭容錯系統需要達成如下兩個指標：
PBFT即實用拜占庭容錯演算法，解決了原始拜占庭容錯演算法效率不高的問題，演算法的時間復雜度是O(n^2)，使得在實際系統應用中可以解決拜占庭容錯問題
PBFT是一種狀態機副本復制演算法，所有的副本在一個視圖（view）輪換的過程中操作，主節點通過視圖編號以及節點數集合來確定，即：主節點 p = v mod |R|。v：視圖編號，|R|節點個數，p：主節點編號。
PBFT演算法的共識過程如下：客戶端（Client）發起消息請求（request），並廣播轉發至每一個副本節點（Replica），由其中一個主節點（Leader）發起提案消息pre-prepare，並廣播。其他節點獲取原始消息，在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息，即認為已經准備完畢，並發送commit消息。當節點收到2f+1個commit消息，客戶端收到f+1個相同的reply消息時，說明客戶端發起的請求已經達成全網共識。
具體流程如下 ：
客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。
主節點收到客戶端的請求，需要進行以下交驗：
a. 客戶端請求消息簽名是否正確。
非法請求丟棄。正確請求，分配一個編號n，編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d客戶端消息摘要，m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見 垃圾回收 章節。
副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：
a. 主節點PRE-PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n，但是簽名不同的PRE-PREPARE信息。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用於View Change過程中恢復未完成的請求操作。
主節點和副本節點收到PREPARE消息，需要進行以下交驗：
a. 副本節點PREPARE消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. n是否在區間[h, H]內。
d. d是否和當前已收到PRE-PPREPARE中的d相同
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中，用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。
主節點和副本節點收到COMMIT消息，需要進行以下交驗：
a. 副本節點COMMIT消息簽名是否正確。
b. 當前副本節點是否已經收到了同一視圖v下的n。
c. d與m的摘要是否一致。
d. n是否在區間[h, H]內。
非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網路中的大部分節點已經達成共識，運行客戶端的請求操作o，並返回<REPLY, v, t, c, i, r>給客戶端，r：是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。
如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。
View Change協議 ：
副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號， C 是 2f+1驗證過的CheckPoint消息集合， P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。
當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後，向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：
副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，並且開始 O 中的PRE-PREPARE消息處理流程。
在上述演算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求後副本節點需要把之前該請求的記錄消息清除掉。
最簡單的做法是在Reply消息後，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。
副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最後一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日誌中的消息，並以n作為當前一個stable checkpoint。
這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息後，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint並未形成stable。
為了防止i的處理請求過快，設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等於checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。
在區塊鏈場景中，一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
Raft基於領導者驅動的共識模型，其中將選舉一位傑出的領導者(Leader)，而該Leader將完全負責管理集群，Leader負責管理Raft集群的所有節點之間的復制日誌。
下圖中，將在啟動過程中選擇集群的Leader（S1），並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌（復制日誌）以存儲和提交由客戶端發出的命令（日誌條目）。 Leader接受來自客戶端的日誌條目，並在Raft集群中的所有關注者（S2，S3，S4，S5）之間復制它們。
在Raft集群中，需要滿足最少數量的節點才能提供預期的級別共識保證， 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ，其中N是組中成員總數，即 投票至少超過一半 ，這也就是為什麼集群節點通常為奇數的原因。 因此，在上面的示例中，我們至少需要3個節點才能具有共識保證。
如果法定仲裁節點由於任何原因不可用，也就是投票沒有超過半數，則此次協商沒有達成一致，並且無法提交新日誌。
數據存儲：Tidb/TiKV
日誌：阿里巴巴的 DLedger
服務發現：Consul& etcd
集群調度：HashiCorp Nomad
只能容納故障節點(CFT)，不容納作惡節點
順序投票，只能串列apply，因此高並發場景下性能差
Raft通過解決圍繞Leader選舉的三個主要子問題，管理分布式日誌和演算法的安全性功能來解決分布式共識問題。
當我們啟動一個新的Raft集群或某個領導者不可用時，將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此，在給定的實例中，Raft集群的節點可以處於以下任何狀態: 追隨者(Follower)，候選人(Candidate)或領導者(Leader)。
系統剛開始啟動的時候，所有節點都是follower，在一段時間內如果它們沒有收到Leader的心跳信號，follower就會轉化為Candidate；
如果某個Candidate節點收到大多數節點的票，則這個Candidate就可以轉化為Leader，其餘的Candidate節點都會回到Follower狀態；
一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term)，它就會轉換為Follower。
Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間， Leader 會定期向所有可用的 Follower 發送心跳消息（實際中可能把日誌和心跳一起發過去）。 因此，其他節點以 Follower 狀態啟動，只要它從當前 Leader 那裡收到周期性的心跳，就一直保持在 Follower 狀態。
當 Follower 達到其超時時間時，它將通過以下方式啟動選舉程序：
根據 Candidate 從集群中其他節點收到的響應，可以得出選舉的三個結果。
共識演算法的實現一般是基於復制狀態機（Replicated state machines），何為 復制狀態機 ：
簡單來說： 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入，而不要引入一下不確定的值，比如本地時間等。使用replicated log是一個很不錯的注意，log具有持久化、保序的特點，是大多數分布式系統的基石。
有了Leader之後，客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌（狀態）序列，以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower，保持整個系統的全局一致性。注意並不是強一致性，而是 最終一致性 。
日誌由有序編號（log index）的日誌條目組成。每個日誌條目包含它被創建時的任期號（term），和日誌中包含的數據組成，日誌包含的數據可以為任何類型，從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示，其中term表示任期， index表示索引號，data表示日誌數據。
Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功，則將命令提交給集群，並將響應發送回客戶端。類似兩階段提交(2PC)，不過與2PC的區別在於，leader只需要超過一半節點同意（處於工作狀態）即可。
leader 、 follower 都可能crash，那麼 follower 維護的日誌與 leader 相比可能出現以下情況
當出現了leader與follower不一致的情況，leader強制follower復制自己的log， Leader會從後往前試 ，每次AppendEntries失敗後嘗試前一個日誌條目（遞減nextIndex值）， 直到成功找到每個Follower的日誌一致位置點（基於上述的兩條保證），然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
要求候選人的日誌至少與其他節點一樣最新。如果不是，則跟隨者節點將不投票給候選者。
意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新，則它將保存所有已提交的條目，避免了日誌回滾事件的發生。
即任一任期內最多一個leader被選出。這一點非常重要，在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader，被稱之為腦裂（brain split），這是非常嚴重的問題，會導致數據的覆蓋丟失。在raft中，兩點保證了這個屬性：
因此， 某一任期內一定只有一個leader 。
當集群中節點的狀態發生變化（集群配置發生變化）時，系統容易受到系統故障。 因此，為防止這種情況，Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。
F. 區塊鏈之聯盟鏈（三） 認識Fabric
Fabric 是超級賬本聯盟推出的核心區塊鏈框架，它適合在復雜的企業內和企業間搭建聯盟鏈。根據超級賬本聯盟的目標， Fabric 被建設為一個模塊化的、支持可插拔組件的基礎聯盟鏈框架。；
與以太坊系的Quorum不同，Fabric從一開始就只考慮企業間的應用。其獨有的channel概念，將企業根據業務目的不同以不同的子網連接起來， 每一個子網對應一個channel，而每個channel有自己獨立的區塊鏈。而Quorum很顯然是只有一個公網（所有企業節點都加入進去），企業與企業間的私有業務是通過Private Manager 完成的。
理解channel的最簡單方法就是，將它類比為一個消息服務提供的Topic，實際上Fabic最早就是基於Kafka 的分布式消息服務來實現。
在Fabric網路中，一個企業可以有一個或多個節點加入整個聯盟鏈；一個企業可以加入1個或者多個Channel（子網）； 一個節點可以加入1個或者多個channel。每個channel構成一個子網，所以Fabric 是 一種由子網組成的網路。
那麼Fabric是怎麼實現智能合約的執行和完成業務上鏈（將事務結果記錄在區塊鏈里）的呢？
與其它框架不同， Fabric 將整個過程分成了三個階段：
業務背書階段 ： 客戶的請求發送的背書節點，通過智能合約完成業務的計算（但不更新狀態），並完成背書；將背書結果返回個客戶端。
業務的排序階段 ： 客戶端將背書結果通過Channel被發送到排序節點（orderer），在排序節點完成事務的排序，並打包到block里，最後下發給所有連接到channel的節點。
業務驗證並寫入賬本階段 : 通過Gossip 網路，所有Channel的節點都會接收到新的block，節點會驗證block中的每一個事務，確定是否有效：有效地將會跟新world state，無效的將會標志為「無效」，不會更新World state，但整個block會被完整的加入到帳本中（包括無效的事務）。
根據以上的描述，Fabric 節點實際可以分為 ，普通節點和Order節點：
Peer, 普通節點, 完成背書（包括只能合約的執行）和驗證.
orderer, 排序節點，完成排序。
加入orderer節點的Fabric網路可以被描述如下：
每一個Channel，都定義了所有屬於channel的節點，但是並不需要所有節點都連接到Orderer 節點（節點間可以通過gossip 協議通訊來傳播私有數據或事務）.
在區塊鏈中，共識是區塊鏈的基礎。與公有鏈不同，聯盟鏈的共識要求所有加入賬本的事務是確定的、最終的，也就是不可以有分叉，區塊與區塊間的順序是一定的，只存在唯一條鏈。在Fabric 中，這個客觀需求正是由排序實現的，所有的事務將被提交給orderer節點獲得確定的順序，並最終打包成block進入帳本。 Fabric 從1.4.1開始支持基於Raft實現排序服務, 可以認為基於Raft實現共識。
基於RAFT的排序服務相對於早期的Kafka 具有更好的分布性，配置更加簡單，是聯盟鏈里常用的一個常用的達成共識的演算法，Quorum就 默認使用RAFT作為共識層。簡單的說，RAFT是一個leader和follower的模式， 所有加入RAFT網路的節點，任意時候都有一個leader, 只有這個leader有權決定事務的順序，並打包成Block，其它節點只能作為follower提交事務和同步block。
基於FAFT網路，每個企業可以有一個或多個節點參與到Orderer中去。在Frabric中企業間的網路連接可以變化成如下形式：
區塊鏈的使用用戶在乙太網中被稱作EOA（External of Account）, EOA的載體是錢包。我們沿用這個概念，來看看Fabric是如何實現用戶和發起事務的。Fabric中EOA是一個CA中心發布的certificate（x.509），一個Certificate代表一個Identity（這與以太坊還是有很大區別的， 以太坊中一個EOA其實是一個hash地址），EOA能夠參與的channel以及被授權的操作是有channel的MSP（ Membership Service Provider）決定的（如下圖）。
註：certificate 是一種密碼學上驗證身份的通用做法； certificate包含了個人的信息，公鑰以及發布這個certificate的CA的簽名。驗證方只需要擁有這個CA的證書（包含CA的公鑰），就可以驗證這個簽名是否正確，certificate的內容是否有篡改。簡單的說，通過CA和Certificate，我們可以獲得一個可驗證的的身份和信任鏈。
如上圖，fabric中通要使用Wallet作為EOA的載體，一個Wallet中可以包含多個Identity（x.509 certificate）。 Identity 通過 CA提供的信任鏈來驗證正確性。
驗證了身份之後， Fabric 通過MSP在區塊鏈網路中解決該身份是否代表組織的成員和在組織內具有什麼角色。例如，channel首先會驗證當前用戶Identity是否是有效地身份，然後通過MSP查看其所處的企業和具有的角色，最終確定該用戶是否有權執行操作。
可以說，Fabric的訪問控制是通過MSP來完成的。在每一個需要訪問控制的地方都需要定義一個MSP。 例如，每個channel都定義一個MSP，這個MSP規定了在channel范圍內資源的訪問許可權。 MSP 是Fabric里一個晦澀難懂的概念，也是其賦予企業間安全訪問的基礎。
前文提到， Fabric 將業務處理和上網分成了三個部分， 背書，排序，驗證後加入賬本。
其中背書是Fabric執行智能合約的階段。以太坊中，智能合約是在EVM中執行的，有多種語言支持。 在Fabric，智能合約被稱為chaincode： 一個chaincode 可以理解為是智能合約的容器，可以包含一個或多個智能合約， 不用於EVM, chaincode是在 JVM 或NodeJS中執行。
客戶應用程序通過智能合約來訪問賬本，每一個可訪問的智能合約都被安裝在客戶端可以訪問的節點上，並被定義在channel里。（有隻能合約的節點被稱為背書節點，沒有隻能合約的節點被稱未提交節點，提交節點只維護賬本）
客戶應用提交一個交易請求， 請求到達背書節點， 背書節點首先會驗證客戶的簽名，確保客戶的身份有權執行本次交易，接著執行交易提及的智能合約（chaincode），並生成一個背書響應（或者叫做交易提案，tran-proposal）。這個背書響應中通常包含World state 的讀集合，寫集合， 以及節點對本次交易的簽名。這里與以太坊系聯盟鏈最主要的不同是： 背書階段只模擬交易，並不真正更新交易結果。 而真正更新交易在第三階段完成。背書節點最後將生成的背書響應fanhui給客戶端， 智能合約部分的執行就結束了。
通常一個交易的執行需要多方的簽名，所以客戶端需要將一個交易發送給多個背書節點，這些背書節點的選擇需要滿足背書策略的要求。
下圖是一個包含有客戶、背書節點，提交節點的網路示意圖。
根據Fabric官方的參考文檔，客戶交易的正果過程可使用下圖描述。
如上圖，從1到3，為背書階段，4為排序階段，4.1,4,2, 5為驗證提交階段。 參考 Frabic的節點 概念，可以了解更多在交易細節的概念。
總的來看， Fabric 更專注於企業間，通過上文，可以讓大家對Fabric的基本構成與概念有一個總的了解。 Fabric本身並不神秘，都是使用的現有的企業間的技術。要更好的了解，建議參考閱讀分布式消息系統和企業的安全基礎設施（CA相關）的支持。與以太坊系聯盟鏈實現比較， Fabric 的子網更概念對於復雜企業間應用適應更強，但是其復雜的安全考量，使得運營成本很高，另外，Fabric 使用Certificate做為用戶身份，有很大的局限性，在新的2.0里，Fabric對於此處將有所改變。
下一篇，我們將來看看Sawtooth , 由Inter 提供的區塊鏈框架。
區塊鏈之聯盟鏈(一) 認識以太坊
區塊鏈之聯盟鏈(二) 認識Quotum
區塊鏈之聯盟鏈(三) 認識Fabric
區塊鏈之聯盟鏈(四) 認識Sawtooth
G. （三）如何使用cello在fabric上創建屬於自己的區塊鏈
進入cello之前讓我們來看一下當前的docker鏡像
如圖，如果您按照上一篇文章搭建好cello後，會看到這六個正在run的docer鏡像，一切長長，下面讓我們正式開始進入8080埠cello後台
注意如果提示創建失敗，說明我們的docker並未開放外網IP訪問，需要配置如下
修改
為
此操作是放開docker外網IP訪問，然後我們重置docker
此時再去填寫IP+埠2375即可
創建角色後我們登錄8081埠界面
H. 主流區塊鏈技術有哪些
本文試圖對區塊鏈有關技術流派和主流平台進行一個概覽，作為學習區塊鏈技術體系的導覽，意在拋磚引玉，促進區塊鏈開發社區的討論與共識。區塊鏈技術的流派未戰先謀局，你想投入區塊鏈開發這個領域，至少先要搞清楚現在有哪些玩家，各自的主張和實力如何。劃分區塊鏈技術流派並無一定之規，據我所見，或可有以下四種方式：第一是按照節點准入規則，劃分為公有鏈、私有鏈和聯盟鏈。公有鏈的代表自然是比特幣和以太坊，私有鏈則以R3 Corda聲名最盛，聯盟鏈的代表作品是Hyperledger名下的Fabric。公有鏈注重匿名性與去中心化，而私有鏈及聯盟鏈注重高效率，而且還往往設置了准入門檻。公有鏈、私有鏈與聯盟鏈之間的這些不同都在技術中有所體現，比如私有鏈和聯盟鏈假設節點數目不大，可以採用PBFT演算法來形成共識。而公有鏈假設有大量且不斷動態變化的節點網路，用PBFT效率太低，只能採用類似抽彩票的演算法來確定意見領袖。這就意味著，私有鏈與聯盟鏈很難變成公有鏈，而用公有鏈來作聯盟鏈或私有鏈雖然容易，卻也並非即插即用。此種差異，學者不可不察。第二是按照共享目標，劃分為共享賬本和共享狀態機兩派。比特幣是典型的共享賬本，而Chain和BigchainDB也應屬此類，這幾個區塊鏈系統在各個節點之間共享一本總賬，因此對接金融應用比較方便。另一大類區塊鏈系統中，各個節點所共享的是可完成圖靈完備計算的狀態機，如以太坊、Fabric，它們都通過執行智能合約而改變共享狀態機狀態，進而達成種種復雜功能。第三是按照梅蘭妮· 斯旺所描述的代際演進，將區塊鏈系統分為1.0、2.0和3.0三代。其中1.0支撐去中心化交易和支付系統，2.0通過智能合約支撐行業應用，3.0支撐去中心化的社會體系。比特幣和Chain應屬於區塊鏈1.0系統，而以太坊和Fabric是區塊鏈2.0系統，目前尚無成功的區塊鏈3.0系統出現，不成功的嘗試倒是有那麼一個，就是著名的The DAO。第四是按照核心數據結構，分為區塊鏈和分布式總賬兩派。區塊鏈這一派在系統中真的實現了一個區塊的鏈作為核心數據結構，而分布式總賬這一派，只是吸取了區塊鏈的精神，並沒有真用一條區塊鏈作為核心數據結構，或者雖然暫時用了，但聲明說吾項庄舞區塊鏈，意在分布式總賬耳，若假以時日，因緣際會，未嘗不可取而代之也。主流區塊鏈技術平台了解流派劃分，仍是只能用來指點江山，吹牛論道，要動手，總要有個切入點。區塊鏈貨幣據說已經有上千個了，但值得關注的技術平台大概只有數十個，而如果要進入區塊鏈開發領域，打下一個好基礎，練出一身好功夫，撈到幾個好offer，則值得深入研究學習的平台，屈指可數。首先當然是比特幣。比特幣作為區塊鏈的第一個也是目前為止最成功、最重要的樣板工程，已經上線運行了八年多，本身沒有發生任何嚴重的安全和運維事故，其穩定與強悍堪稱當代軟體系統典範。比特幣Bitcoin Core是一個代碼質量高、文檔良好的開源軟體，從學習區塊鏈原理、掌握核心技術的角度來說，Bitcoin Core是最佳切入點，能夠學到原汁原味的區塊鏈技術。當然，Bitcoin Core是用C++寫的，而且用了一些C++11和Boost庫的機制，對學習者的C++水平提出了較高的要求。學習比特幣平台開發還有一個優勢，就是可以對接繁榮的比特幣技術社區。目前圍繞比特幣進行改進和提升的人很多，人多力量就大，諸如隔離驗證、閃電網路、側鏈等比較新的想法和技術，都率先在比特幣社區里落地。比如側鏈技術的主要領導者Blockstream是由密碼學貨幣元老Adam Back領銜的，而Blockstream是Bitcoin Core最大的貢獻者之一，所以一些有關側鏈的技術在比特幣社區里討論最充分。但比特幣作為一個典型的區塊鏈1.0系統，是不是支撐其他類型區塊鏈應用的最佳技術平台，存在很大的爭議。另外，也不是所有人都有能力和必要精通區塊鏈底層技術。所以對那些急於沖到區塊鏈領域里做（quān）事（qián）的人來說，可能更直截了當的學習目標是以太坊和Hyperledger Fabric。在以太坊上面用Solidity進行的智能合約開發是切入區塊鏈開發最簡單的方式，沒有之一。以太坊的理想非常宏大，由於配備了強大的圖靈完備的智能合約虛擬機，因此可以成為一切區塊鏈項目的母平台，是馱住整個區塊鏈世界的大烏龜。在以太坊上開發一個類似比特幣的加密貨幣，是一個不折不扣的小目標。一般有經驗的開發者在文檔指導下，半天到一天即可入門。問題在於，入門以後又如何？靠寫Solidity是否就可以包打天下？這是大大存疑的。我們也可以反過來說，如果以太坊+Solidity是區塊鏈的終極解決方案，那麼怎麼還會出現那麼多區塊鏈技術門派呢？特別是，以太坊似乎並沒有給現實世界中巨型的中心化組織們留下一條活路，這種徹底不妥協的革命態度有可能也成為以太坊推廣的障礙。當前以太坊項目的開發進展並不順利。一個比較突出的問題是項目過多，力量分散，導致項目質量參差不齊。但盡管如此，跟其他區塊鏈2.0平台相比，以太坊提供的開發環境是最簡單最完善的。初學區塊鏈的人絕對有必要學習以太坊，從而對區塊鏈和智能合約建立起一個最「正宗」的認識。主流區塊鏈技術平台的第三支就是Fabric，它是Hyperledger的第一個也是最知名的孵化項目。 Fabric最早來自IBM的Open Blockchain項目，到2015年11月，IBM將當時已經開發完成的44,000行Go語言代碼交給Linux基金會，並入Hyperledger項目之中。在2016年3月一次黑客馬拉松中，Blockstream和DAH兩家公司將各自的代碼並入Open Blockchain，隨後改名為Fabric。到目前為止，Fabric與Intel提供的Sawtooth Lake並列為Hyperledger的一級孵化項目，但前者得到的關注遠超後者。從技術角度來說，Fabric思路不錯，重點是滿足企業商用的需求，比如解決交易量問題。眾所周知，比特幣最大的短板是它每秒鍾7個交易的上限，完全無法滿足現實需要。而Fabric目標是實現每秒鍾10萬交易，這個量接近剛剛過去的雙十一交易量瞬時峰值，完全可以滿足正常條件下的行業級應用。Fabric用Go語言開發，也提供多種語言的API。特別值得一提的是，Fabric比較充分地運用了容器技術，比如其智能合約就運行在容器當中。這也是Go語言帶給Fabric的一項福利，因為Go語言靜態編譯部署的特徵很適合開發容器中的程序。Fabric還有一些特點，比如其membership服務可以設置節點准入審查，這是典型的聯盟鏈特徵。再比如其共識演算法是可定製的。Fabric的短板是體系較為復雜，雖有文檔，但缺少經驗的開發者學習起來障礙比較大。然而由於其定位清楚，迎合了不少企業的心態，所以已經有多家機構在基於Fabric秘密研發行業內的聯盟鏈項目。
I. 初識Hyperledger Fabric
Fabric是聯盟鏈，Peer代表一系列組織，Peers是整個區塊鏈網路的基礎，因為它是賬本和智能合約的載體。通過智能合約，賬本通過不可篡改的方式記錄了交易的全過程。
對於不能的公司來說，是有不同的業務的，不同的業務又與不同的公司相關聯，需要創建多個聯盟鏈，因此就需要創建多個channel，channel是多個特定成員之間以機密交易為目的建立的私網，一個peer可以加入多個channel，每個channel維護自己的賬本，賬本和賬本之間是隔離的，每個channel可以維護一個或多個賬本。所以為了滿足復雜的交易需求，每個peer上可以安裝不同的智能合約，當peer交易完成時，會發送事件通知Client。peer上還有一個Local MSP（成員服務提供器）服務，提供身份認證和加密簽名等功能。
WorldState 以key-value的形式，維護著當前賬本的當前信息。
智能合約（Smart Contract）是區塊鏈的核心，定義了各個不同組織間的業務規范，創建交易並記錄在賬本里。多個智能合約可以打包到一個鏈碼中。只有鏈碼（Chaincode）部署之後，智能合約才能被應用使用。
不同於一般的鏈碼運行在一個獨立的容器，系統鏈碼運行在peer進程上，實現了一些系統行為。
Fabric為了優化網路性能，提高安全性和可擴展性，將每個交易分到 Endorsing Peer 、 Ording-Service 和 Committting Peer 三個部分，這就需要一種安全的，可信的和可擴展的數據傳輸協議——Gossip Protocol。 Gossip 傳輸協議以隨機的方式將信息散播到網路中，主要執行三個功能：