Hyperledger Fabric週週記：起源

本着「以教帶學，Learning by Doing」的想法，我於上週加入了Bob組織的HiBlock區塊鏈技術佈道羣。這個羣可不太好混，羣規要求每一個成員必需每週有輸出，連續兩次交白卷就要被踢出羣。

在這樣的壓力之下，我決定開一個新坑：區塊鏈週週記，記錄下每週區塊鏈的學習成果和爬坑經驗。做爲系列的新篇章，我選擇從超級帳本的Fabric開始。

爲何選擇超級帳本做爲起點？

我在以前的文章中曾說過會從超級帳本入手開始區塊鏈的學習和實踐，同時也給出了我的的理由。但做爲一篇佈道類文章，單單我的喜愛是沒有說服力的。

在Fabric的文檔中，它強調了本身面向企業應用而生的理由：

• 企業但願跟身份肯定的人作生意，而非像公鏈那樣徹底匿名的對手方
• 並不是人人均可加入的商業網絡
• 交易的私密性，好比，對於不一樣的渠道或經銷商，他們各自拿到的折扣不同，這些信息必須是私密的，相互隔離。
• 性能和交易確認的時延

能夠看得出，相比起公鏈激進的作法，以Fabric爲表明的聯盟鏈要溫和的多，而且也容易爲企業所接受。加上其給出的若干限制，技術上的落地也相對容易不少。

Fabric中的主要組件

關於區塊鏈自己的理論和介紹，目前已經爛大街了，在此也就是再也不贅述。在本節，讓咱們來看看Fabric是如何經過主要組件完成技術落地的。

從大的方面講，Fabric的主要組件大體可劃分紅這幾個部分：

• 分佈式帳本，解決數據共享問題，讓全部參與方擁有共同的交易歷史。
• 智能合約，解決應用與帳本的交互問題，包括查詢和更新。
• 共識機制，解決數據同步問題，基於Endorsement Policy實現交易的傳播。
• 成員服務，解決參與方身份問題，只有可信成員之間才能完成交易。

分佈式帳本

Fabric的分佈式帳本狀態由兩部分組成：世界狀態（World State）和區塊鏈。前者表明帳本的當前狀態，變動和查詢頻繁，每每以數據庫形式實現；後者則用來捕獲前者的每次變動，做爲交易的變動記錄，沒法修改且極少查詢，經常實現爲文件形式。

對於世界狀態的DB載體，當前版本有兩個選擇：內置的LevelDB和外置的CouchDB，若是想要得到更靈活的查詢能力，選擇後者。由此你們應該能夠猜出：世界狀態中保存的數據是以KV對的形式存在。

對於區塊鏈來說，它以Block的hash鏈組成，每一個Block包含一組有序的交易。這個順序是交易順序，很是關鍵。

除了這兩個組件，Fabric還引入了一個獨特的設計：Channel，用來解決不一樣組織間的帳本共享問題。假如組織A同時與組織B和組織C作生意，而且組織B和組織C是競爭對手，那麼經過創建不一樣的Channel能夠實現A和B，A和C分別共享各自的帳本。利用Channel，很好地解決了常見的B2B場景。

Channel抽象出了業務參與方的溝通，可視爲業務網絡的子網，實現了交易的相互隔離和業務私密性。

智能合約

Fabric的智能合約以「鏈碼（Chaincode）」的形式存在，外部客戶端利用它來完成對世界狀態的更改。與以太坊不一樣，鏈碼支持使用通用編程語言來書寫，當前版本支持Go和Node.js，但從Fabric Java SDK的源碼中能夠看出，離支持Java應該也不遠了：

public enum Type {
    JAVA,
    GO_LANG,
    NODE
}

對於初學者須要注意的是：鏈碼 != Fabric SDK。前者運行於Fabric環境，執行業務邏輯。後者則由被客戶端程序用來與鏈碼完成交互。打個相似的比方：

• 將Fabric環境視爲Tomcat這樣的容器。
• 鏈碼則可視爲運行於其中的Servlet。
• Fabric SDK則相似HttpClient這樣的類庫被Java客戶端利用發起請求，實現於Servlet的交互。

由此可知，鏈碼自己其實是一個應用，其生命週期可分爲：package、install、instantiate、upgrade。一樣，鏈碼能夠綁定任意任意數量的Channel，並獨立運行。

關於鏈碼的教程，文檔已經給出了詳細的說明，在此就再也不囉嗦。

共識機制

Fabric中有三類節點：

• Client，表明最終用戶向endorser提交事務調用（Transaction Invocation），向ordering service廣播事務提議（Transaction Proposal）。
• Peer，提交事務，維護世界狀態和帳本副本（區塊鏈）。其中，有一類特殊的Peer是Endorser。
• Orderer，提供節點間的通訊服務，保證消息的交付和順序，典型如Kafka隊列。

整個事務流程在文檔中有介紹：

1. client發起事務提議。
2. endorser peer驗證並執行。
3. client檢查事務提議的響應。
4. 若endorsement policy知足，client將endorsement打包進事務，提交給ordering service。消息包括：endorser簽名、讀寫集和channel id。
5. 事務被orderer提交給channel上全部的peer，它們會檢查並提交事務。
6. 帳本更新。

從上面的流程能夠看出，Fabric的共識機制創建在endorsement policy之上，它能夠經過命令行參數進行配置，並不須要Channel的全部Peer參與。

成員服務

成員服務負責參與方的身份許可和驗證，它創建於數字證書和信任鏈基礎之上。所謂成員，既能夠是組織（Org），也能夠是組織部門（OU）。Fabric的成員服務配置能夠出如今兩處：Local（節點）和Channel（Channel級）。

從開發角度來說，引入成員服務帶來的做用就是：若是應用（Client和Chaincode）要參與到區塊鏈網絡中，則須要相應簽名和證書。

Fabric的開發套路

老實講，從上面的簡單介紹已經看出，Fabric的開發並不簡單，它至少涉及：

• Client，提供UI、鏈碼交互以及其餘輔助功能。
• 鏈碼，負責執行業務邏輯。
• 業務網絡，定義參與方、Channel和Endorsement Policy。
• 成員管理，定義組織及其成員映射，這涉及到一系列證書的發放。
• 應用部署，將上面的各部分部署到Fabric環境。

這還不算完，如何測試也是一個大麻煩，相比起簡單的CRUD應用，光搭建Fabric的環境就讓人生畏。假如你對本身的要求更高點，想要實現一個持續集成環境，該怎麼辦？

此外，開發以後的運維成本也不會低，除了Fabric自己的基礎設施，鏈碼的平滑升級也對開發和運維提出了高標準。

鑑於這些麻煩的事情，假如你沒有辦法說服業務合做方也一樣部署一套Fabric，我以爲徹底沒有必要去基於它來開發應用。單組織內的區塊鏈應用，我我的認爲是一個僞命題，沒有存在的價值。

關於示例教程，Fabric的文檔已經給出了範例，各位能夠仔細閱讀。

爲了下降區塊鏈應用的開發難度，超級帳本項目又引入了Composer。其目的在於加速應用的開發和部署，目前已經支持Fabric，當前處於孵化階段。它創建在諸多框架和工具之上：

• node.js + angular，幫助開發者完成全棧區塊鏈解決方案的開發。
• yeoman，利用其模板功能快速搭建應用框架。
• 一套開發環境，實現應用的打包部署以及暴露成Restful Service。

看起來很不錯！

寫在最後

對於一個初學者來說，寫這篇文章真不容易！如文章存在錯誤，不要客氣，只管指出，:)。關於下一週的週記，我會去寫一個實際的Fabric應用的例子，同時給出Composer的例子，請保持關注。

附註：在寫此文的過程當中，我還找到了一篇吐槽Fabric的文章，這裏一併給出連接，方便你們客觀評定。