區塊鏈fabric協議

1. 初識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 傳輸協議以隨機的方式將信息散播到網路中，主要執行三個功能：

2. 區塊鏈之聯盟鏈（三） 認識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

3. 區塊鏈技術如何為實體產業賦能

現在國內已經有企業將區塊鏈技術落地到了實際的產業中，如旺鏈科技就將區塊鏈應用到金融服務，醫療健康，IP版權，物聯網，共享經濟，通信，教育，
社會管理，慈善公益，文化娛樂等領域

4. （三）如何使用cello在fabric上創建屬於自己的區塊鏈

進入cello之前讓我們來看一下當前的docker鏡像

如圖，如果您按照上一篇文章搭建好cello後，會看到這六個正在run的docer鏡像，一切長長，下面讓我們正式開始進入8080埠cello後台

注意如果提示創建失敗，說明我們的docker並未開放外網IP訪問，需要配置如下

修改

為

此操作是放開docker外網IP訪問，然後我們重置docker

此時再去填寫IP+埠2375即可

創建角色後我們登錄8081埠界面

5. 各區塊鏈架構的橫向比較

各區塊鏈架構的橫向比較
時常聽人們談起區塊鏈，從 2009 年比特幣誕生至今，各式各樣的區塊鏈系統或基於區塊鏈的應用不斷被開發出來，並被應用到大量的場景中，而區塊鏈技術本身也在不停地變化和改進。
區塊鏈又被稱為分布式賬本，與之對應的則是中心化賬本，比如銀行。與中心化賬本不同的是，分布式賬本依靠的是將賬本數據冗餘存儲在所有參與節點中，來保證賬本的安全性。簡單地說，區塊鏈會用到三種底層技術：點對點網路技術、密碼學技術和分布式一致性演算法。而通常，區塊鏈系統還會「免費附贈」一種被稱為智能合約的功能。智能合約雖然不是區塊鏈系統的必要組成部分，但由於區塊鏈天生所具備的去中心化特點，使它可以很好地為智能合約提供可信的計算環境。
為了適應不同場景的需求，區塊鏈系統在實際應用的過程中往往會需要進行各種改造，以滿足特定業務的要求，比如身份認證、共識機制、密鑰管理、交易頻次、響應時間、隱私保護、監管要求等。而實際應用區塊鏈系統的公司往往沒有進行這種改造的能力，於是市場上慢慢出現了一些用於定製專用區塊鏈系統的框架，採用這些框架就可以很方便地定製出適用於企業自身業務的區塊鏈系統。
本文將對目前市場上幾個典型的區塊鏈框架進行橫向對比，看看它們都有哪些特點，以及它們之間到底有哪些區別。為了保持對比的公正性，本文將只針對開源的區塊鏈框架進行討論。
各區塊鏈架構的簡單介紹
1、比特幣
比特幣(bitcoin)源自一名叫做中本聰(Satoshi Nakamoto)的人在 2008 年發表的一篇名為《比特幣：一種點對點的電子現金系統》(Bitcoin: A Peer-to-PeerElectronic Cash System)的論文，文中描述了一種被他稱為「比特幣」的電子貨幣及其演算法。在之後的幾年裡，比特幣不斷成長和成熟，而它的底層技術也逐漸被人們認識並抽象出來，這就是區塊鏈技術。比特幣作為區塊鏈的鼻祖，在區塊鏈的大家族中具有舉足輕重的地位，基於比特幣技術開發出的山寨幣(altcoins)的數量有如天上繁星，數不勝數。
從論文中可以得知，中本聰設計比特幣的目的，就是希望能夠實現一種完全基於點對點網路的電子現金系統，使得在線支付能夠直接由一方發起並支付給另外一方，中間不需要通過任何的中介機構。總結來說，他希望比特幣的設計能夠實現以下這些目標：
● 不需要中央機構就可以發行貨幣
● 不需要中介機構就可以支付
● 保持使用者的匿名性
● 交易無法被撤銷
從電子現金系統的角度來看，以上這些目標在比特幣中基本都得到了實現，但是依然有一些技術問題有待解決，比如延展性攻擊、區塊容量限制、區塊分叉、擴展性等。
在應用場景方面，目前大量的數字貨幣項目都是基於比特幣架構來設計的，此外還有一些比較實際的應用案例，比如彩色幣、t? 等。
彩色幣(coloredcoin)，通過仔細跟蹤一些特定比特幣的來龍去脈，可以將它們與其他的比特幣區分開來，這些特定的比特幣就叫作彩色幣。它們具有一些特殊的屬性，從而具有與比特幣面值無關的價值，利用彩色幣的這種特性，使得開發者可以在比特幣網路上創建其它的數字資產。彩色幣本身就是比特幣，存儲和轉移不需要第三方，可以利用已經存在的比特幣的基礎。
t? 是比特幣區塊鏈在金融領域的應用，是美國在線零售商 Overstock 推出的基於區塊鏈的私有和公有股權交易平台。
2、以太坊
以太坊(ethereum) 的目標是提供一個帶有圖靈完備語言的區塊鏈，用這種語言可以創建合約來編寫任意狀態轉換功能，用戶只要簡單地用幾行代碼來實現邏輯，就能夠創建一個基於區塊鏈的應用程序，並應用於貨幣以外的場景。
以太坊的設計思想是不直接「支持」任何應用，但圖靈完備的編程語言意味著理論上任意的合約邏輯和任何類型的應用都可以被創建出來。總結來說，以太坊在比特幣的設計目標之外，還需要實現以下幾個目標：
● 圖靈完備的合約語言
● 內置的持久化狀態存儲
目前基於以太坊的合約項目已達到數百個，比較有名的有 Augur、TheDAO、Digix、FirstBlood 等。
Augur 是一個去中心化的預測市場平台，基於以太坊區塊鏈技術。用戶可以用數字貨幣進行預測和下注，依靠群眾的智慧來預判事件的發展結果，可以有效地消除對手方風險和伺服器的中心化風險。
限於篇幅，基於以太坊智能合約平台的項目就不多介紹了。基於以太坊的代碼進行改造的區塊鏈項目也有不少，但幾乎都是閉源項目，只能依靠一些公開的特性來推斷，所以就不在本文展開討論了。
3、Fabric
Fabric 是由 IBM 和 DAH 主導開發的一個區塊鏈框架，是超級帳本的項目成員之一。它的功能與以太坊類似，也是一個分布式的智能合約平台。但與以太坊和比特幣不同的是，它從一開始就是一個框架，而不是一個公有鏈，也沒有內置的代幣(token)。
超級賬本(hyperledger)是 Linux 基金會於 2015 年發起的推進區塊鏈技術和標準的開源項目，加入成員包括：荷蘭銀行(ABN AMRO)、埃森哲(Accenture)等十幾個不同利益體，目標是讓成員共同合作，共建開放平台，滿足來自多個不同行業各種用戶案例，並簡化業務流程。
作為一個區塊鏈框架，Fabric 採用了松耦合的設計，將共識機制、身份驗證等組件模塊化，使之在應用過程中可以方便地替換成自定義的模塊。除此之外，Fabric 還採用了容器技術，將智能合約代碼(chaincode)放在 docker 中運行，從而使得智能合約可以用幾乎任意的高級語言來編寫。
以下是 Fabric 的一些設計目標：
● 模塊化設計，組件可替換
● 運行於 docker 的智能合約
目前已經有不少採用 Fabric 架構進行開發的概念驗證(POC)項目在實施過程中，其中不乏一些金融機構做出的嘗試，不過由於項目剛剛起步，還沒有比較成熟的落地應用。
4、DNA
DNA(Distributed Networks Architecture，分布式網路架構)，是由總部位於上海的區塊鏈創業公司「分布科技」開發的區塊鏈架構，可以同時支持公有鏈、聯盟鏈、私有鏈等不同應用類型和場景，並快速與業務系統集成。
與以太坊、Fabric不同的是，DNA 在系統底層實現了對多種數字資產的支持，用戶可以直接在鏈上創建自己的資產類型，並用智能合約來控制它的發行邏輯。對於絕大部分的區塊鏈應用場景，數字資產是必不可少的，而為每一種數字資產都開發一套基於智能合約的轉賬、發行邏輯是非常浪費且低效的。因此，由區塊鏈底層提供直接的數字資產功能是十分必要的。而對於那些完全不需要數字資產的應用場景，同樣可以基於 DNA 提供的智能合約架構來編寫任意的自定義邏輯來實現。
DNA 的設計目標主要有以下幾點：
● 多種數字資產的底層支持
● 圖靈完備的智能合約和狀態持久化
● 跨鏈互操作性
● 交易的最終性
目前已有不少金融機構採用 DNA 架構來進行區塊鏈概念驗證產品的開發。除此之外，還有一些已經落地的區塊鏈項目，如小蟻區塊鏈、法鏈等。
小蟻(antshares)是一個定位於資產數字化的公有鏈，將實體世界的資產和權益進行數字化，通過點對點網路進行登記發行、轉讓交易、清算交割等金融業務的去中心化網路協議。它採用社區化開發的模式，在架構上與 DNA 保持一致，從而可以與任何基於DNA 的區塊鏈系統發生跨鏈互操作。
法鏈是全球第一個大規模商用的法律存證區塊鏈，一個底層基於 DNA區塊鏈技術，並由多個機構參與建立和運營的證據記錄和保存系統。該系統沒有中心控制點，且數據一旦錄入，單個機構或節點無法篡改，從而滿足司法存證的要求。
5、Corda
Corda 是由一家總部位於紐約的區塊鏈創業公司 R3CEV 開發的，由其發起的 R3區塊鏈聯盟，至今已吸引了數十家巨頭銀行的參與，其中包括富國銀行、美國銀行、紐約梅隆銀行、花旗銀行、德國商業銀行、德意志銀行、匯豐銀行、三菱 UFJ 金融集團、摩根士丹利、澳大利亞國民銀行、加拿大皇家銀行、瑞典北歐斯安銀行（SEB）、法國興業銀行等。
從 R3 成員的組成上也可以看出，Corda 是一款專門用於銀行與銀行間業務的區塊鏈架構。盡管 R3 自己聲稱 Corda 不是區塊鏈，但從各項特徵來看，它具備區塊鏈的一些特性。
技術對比
1、數字資產
接下來，將對前文中提到的這些區塊鏈框架進行一系列的技術對比，並從多個維度展開介紹它們的區別與相似之處。

區塊鏈的內置代幣通常是一種經濟激勵模型和防止垃圾交易的手段。比特幣天生就有且只有一種內置代幣，所以在比特幣系統中所有的「交易」本質上都是轉賬行為，除非通過外部的協議層來給比特幣增加額外的數字資產。
以太坊和 DNA 具有內置代幣，它們的作用除了以上提到的經濟激勵和防止垃圾交易之外，還具有為系統內置功能提供一個收費的渠道。比如以太坊的智能合約運行需要消耗 GAS，而 DNA 的數字資產創建也需要消耗一定的代幣。
以太坊和 Fabric 沒有內置的多種數字資產支持，而是通過智能合約來實現相應的功能。這種方式的好處在於，系統設計可以做到非常簡潔，而且資產的行為可以任意指定，自由度極高。然而這樣的設計也會帶來一系列的負面影響，比如所有的資產創建者不得不自己編寫重復的業務邏輯，而用戶也沒有辦法通過統一的方式去操作自己的資產。
相比之下，DNA 和 Corda 採用了在底層支持多種數字資產的方式，讓資產創建者可以方便地創建自己的資產類型，而用戶也可以在同一個客戶端中管理所有的資產。對於邏輯更加復雜一點的業務場景來說，他們同樣可以利用智能合約來強化資產的功能，或者創建一種與資產無關的業務邏輯。
2、賬戶系統

UTXO(Unspent Transaction Output)是這樣一種機制：每一枚數字貨幣都會被登記在一個賬戶的所有權之下，一枚數字貨幣有兩種狀態，即要麼還沒有被花費，要麼已經被花費。當需要使用一枚數字貨幣的時候，就將它的狀態標記為已經花費，並創造一枚新的與之等額的數字貨幣，將它的所有權登記到新的賬戶之下。在這個過程中，被標記為已花費的數字貨幣就被稱為交易的輸入，而創造出來的新的數字貨幣被稱為交易的輸出，在一筆交易中，可以包含多個輸入和多個輸出，但是輸入之和與輸出之和必須相等。要計算一個賬戶的余額時，只要將所有登記在該賬戶下的數字貨幣的面額相加即可得出。
比特幣和 Corda 就採用了 UTXO 這樣一種賬戶機制，而以太坊則採用了更加直觀的余額機制：每個賬戶有一個狀態，狀態中直接記錄了賬戶當前的余額，轉賬的邏輯就是從一個賬戶中減去一部分余額，並在另一個賬戶中加上相應的余額，減去的部分和加上的部分必須相等。DNA 在賬戶機制上同時兼容這兩種模式。
那麼 UTXO 模式和余額模式，究竟有什麼優缺點呢？UTXO 最大的好處就是，基於 UTXO 的交易可以並行驗證且任意排序，因為所有的 UTXO 之間都是沒有關聯的，這對區塊鏈未來的伸縮性是有很大幫助的，而基於余額的設計就沒有這個優勢了；反過來，余額設計的優點是設計思想非常簡潔和直覺化，便於程序實現，特別是在智能合約中，要處理 UTXO 的狀態是非常困難的。這也是為什麼以智能合約為主要功能的以太坊選擇余額設計的原因，而比特幣、OnchainDNA、Corda 這些以數字資產為核心的架構則更傾向於 UTXO 設計。
關於身份認證，比特幣和以太坊基本沒有身份認證的設計，原因很簡單，因為這兩者的設計思想都是強調隱私和匿名，而反對監管和中心化，而身份認證就勢必要引入一些中心或者弱化的中心機構。Fabric、DNA 和 Corda 不約而同地選擇了採用數字證書來對用戶身份進行認證，原因在於這三者都有應用於現有金融系統的設計目標，而金融系統必然要考慮合規化並接受監管，此外現有的金融系統已經大范圍地採用數字證書方案，這樣便可以和區塊鏈系統快速集成。

6. 淺析 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

7. 區塊鏈 --- 共識演算法

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使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。

8. 超級賬本之——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頒發的證書，進行判斷。

9. 如何創建屬於自己的 fabric 區塊鏈

這個是需要藉助平台進行創建。
IBM中國研究院開發的超能雲（SuperVessel）平台提供了給區塊鏈愛好者、開發者的區塊鏈開發測試環境。通過該平台，用戶能夠免費、超快速創建基於Hyperledger Fabric的多節點區塊鏈、並在自己的鏈上花式玩轉智能合約。
當然，國外的去中心化內容分享平台DECENT也是可以創建的。