區塊鏈筆記：掌握超級帳本開發後，我總結出7條學習心得

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

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

1

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

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

在Fabric（http://hyperledger-fabric.readthedocs.io/en/latest/whatis.html）的文檔中，它強調了本身面向企業應用而生的理由：

• 企業但願跟身份肯定的人作生意，而非像公鏈那樣徹底匿名的對手方

• 並不是人人均可加入的商業網絡

• 交易的私密性，好比，對於不一樣的渠道或經銷商，他們各自拿到的折扣不同，這些信息必須是私密的，相互隔離。

• 性能和交易確認的時延

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

2

Fabric中的主要組件

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

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

• 分佈式帳本，解決數據共享問題，讓全部參與方擁有共同的交易歷史。

• 智能合約，解決應用與帳本的交互問題，包括查詢和更新。

• 共識機制，解決數據同步問題，基於Endorsement Policy實現交易的傳播。

• 成員服務，解決參與方身份問題，只有可信成員之間才能完成交易。

3

分佈式帳本

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抽象出了業務參與方的溝通，可視爲業務網絡的子網，實現了交易的相互隔離和業務私密性。

4

智能合約

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

https://github.com/hyperledger/fabric-sdk-java/blob/master/src/main/java/org/hyperledger/fabric/sdk/TransactionRequest.java）的源碼中能夠看出，離支持Java應該也不遠了：

public enum Type {
   JAVA,
   GO_LANG,
   NODE
}

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

• 將Fabric環境視爲Tomcat這樣的容器。

• 鏈碼則可視爲運行於其中的Servlet。

• Fabric SDK則相似HttpClient這樣的類庫被Java客戶端利用發起請求，實現於Servlet的交互。

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

關於鏈碼的教程，文檔已經給出了詳細的說明（地址：http://hyperledger-fabric.readthedocs.io/en/latest/chaincode.html），在此就再也不囉嗦。

5

共識機制

Fabric中有三類節點：

• Client，表明最終用戶向endorser提交事務調用（Transaction Invocation），向ordering service廣播事務提議（Transaction Proposal）。

• Peer，提交事務，維護世界狀態和帳本副本（區塊鏈）。其中，有一類特殊的Peer是Endorser。

• Orderer，提供節點間的通訊服務，保證消息的交付和順序，典型如Kafka隊列。

整個事務流程（地址：http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html）在文檔中有介紹：

• client發起事務提議。

• endorser peer驗證並執行。

• client檢查事務提議的響應。

• 若endorsement policy知足，client將endorsement打包進事務，提交給ordering service。消息包括：endorser簽名、讀寫集和channel id。

• 事務被orderer提交給channel上全部的peer，它們會檢查並提交事務。

• 帳本更新。

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

6

成員服務

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

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

7

Fabric的開發套路

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

• Client，提供UI、鏈碼交互以及其餘輔助功能。

• 鏈碼，負責執行業務邏輯。

• 業務網絡，定義參與方、Channel和Endorsement Policy。

• 成員管理，定義組織及其成員映射，這涉及到一系列證書的發放。

• 應用部署，將上面的各部分部署到Fabric環境。

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

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

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

關於示例教程，Fabric的文檔已經給出了範例（地址：http://hyperledger-fabric.readthedocs.io/en/latest/tutorials.html），各位能夠仔細閱讀。

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

• node.js + angular，幫助開發者完成全棧區塊鏈解決方案的開發。

• yeoman，利用其模板功能快速搭建應用框架。

• 一套開發環境，實現應用的打包部署以及暴露成Restful Service。

看起來很不錯！對於一個初學者來說，寫這篇文章真不容易！如文章存在錯誤，不要客氣，只管指出，:)。接下來給出一個Composer的例子。

8

Fabric應用-Composer框架

按照最開始的寫做計劃，我打算講講兩種開發模式：直接使用Fabric API和利用Composer框架（地址：https://hyperledger.github.io/composer/latest/index.html）。可在通讀完Composer的文檔（地址：https://hyperledger.github.io/composer/latest/introduction/introduction.html）以後，我當即取消了原定計劃，直接介紹Composer。

選擇工具A而不是B通常狀況下理由都很直接：簡單易上手。以我我的爲例，在翻完Fabric的文檔以後，雖然對於Fabric的架構和組件瞭然於胸，但對於如何開發，其實仍是很模糊的。

爲何會這樣？有兩個緣由：

• 文檔自己給出的開發範例（fabric-samples）缺少一個系統性的介紹。所謂系統性，說白了就是教科書性質的介紹，由一個簡單的例子開始，層層遞進，最終讓讀者全盤掌握。就當前的文檔來講，這一任務顯然沒有達到。

• 缺少聚焦，正如這篇Composer幻燈片（第四頁）（地址：https://www.slideshare.net/SimonStone8/introduction-to-hyperledger-composer）介紹的，有太多東西要操心了，對於真正須要關心的東西（業務邏輯）反而沒有突出。

Composer剛好很是好的彌補了Fabric文檔中這兩個缺陷，從其文檔構成能夠很明顯的看出來：

• 給出Composer的總體性介紹

• 手把手教會你們如何完成安裝

• 給出一個Hello World級別的例子

• 如何進行單元測試

• 如何部署到真實的Fabric環境

這種方式是我最喜歡的，對於開發者來說，他能很快創建起總體印象，而且樹立起信心。

固然，文檔好並不足以吸引開發者成爲粉絲。讓其成爲開發首選的理由只有一個：對開發者友好。

Composer的開發者友好性表如今如下幾個方面。

1. 良好的抽象

Chaincode是Fabric開發的核心，但看過了例子（地址：https://hyperledger-fabric.readthedocs.io/en/release-1.1/chaincode4ade.html）以後，說真的，很容易讓開發者打退堂鼓。由於太底層了！讓人有一種回到用Servlet開發Java Web應用的感受。

Composer在這一點上作得很好，它的Runtime內置了通用的Chaincode。使用它開發根本不會感到Chaincode的存在。並且整個過程幾乎跟你開發一個普通的CRUD Web應用無異！在開發者看來，他就是在寫普通的JavaScript函數。

這篇文章（地址：https://blog.selman.org/2017/07/08/getting-started-with-blockchain-development/）給出了兩種方式（Chaincode和Composer）的開發範例，在結尾處提到二者的代碼行差別：

This ±10x reduction in the number of lines of code when Go and Composer solutions are compared is fairly consistent across several samples.

2. 統一的工程化體驗

實際的開發不是書上的簡單例子，並且涉及多人，若是沒有良好的開發規範，很難產生好的結果。從Fabric文檔中，你沒法看出一個區塊鏈應用的項目工程應該是什麼樣子，只能看到一個個零散的代碼文件。顯然沒法知足工程上的要求。

就一個Fabric區塊鏈項目來說，它包含：

• 存儲於帳本上的Asset

• 操做Asset的Chaincode

• 訪問Chaincode的Client App

• 應用相關的權限和成員

Composer很是完美地給出瞭解決方案，將整個開發過程分紅3部分，每一部分都有對應的命令行工具，提供統一的開發體驗：

Business Network，業務邏輯，其中包括如下組件：

• asset model，存儲於帳本上的Asset，其過程跟設計數據庫的表沒什麼兩樣。

• transaction function，對應Chaincode中的各個方法，但對於開發者來說徹底透明。

• acl文件，權限定義。

• query，命名查詢，供transaction function調用。

Rest Server

• 將發佈到Fabric的Business Network暴露成Restful API，供外部調用，徹底語言中立。

Client App

• 嚴格來說，這一步並不是必要，由於既然上面已經有了語言中立的API，理論上能夠用任何框架來開發相應的Client APP。但Composer提供了一個基於Angular的模板幫助加速這一過程。

怎麼樣，這個過程是否是很是眼熟？經過開發框架固化的開發過程可讓開發人員更快的上手，而且統一在相同的「big picture」之下。而且，上述的各個組件對於有經驗的開發者並不陌生，有助於快速理解。

你們能夠在文檔中的這個例子（地址：https://hyperledger.github.io/composer/latest/tutorials/developer-tutorial）中看到完整的過程。

3. 內建測試的支持

即使是水平再爛的開發，他也但願能驗證一下本身寫的東西纔好意思交出去。然而，對於Fabric應用來說，這可不是件容易的事情，由於部署太繁瑣了。

Composer再次拯救了開發！

Composer內置的runtime爲測試提供了良好的支持，因爲良好的抽象，這個runtime既能夠是實際的Fabric，也能夠是一個內置的Node.js進程。然後者則是爲測試而生的。更好的是，這一切徹底對開發者透明，開發的上層代碼徹底不須要改動。

對於上進心更強，想要實現自動化測試的同窗，這裏有一個例子（地址：https://github.com/hyperledger/composer-sample-networks/blob/master/packages/bond-network/test/Bond.js）能夠參考。

4. 便捷的CLI工具

相比起Fabric零散的命令集合，Composer提供了便捷的CLI，統一了開發、管理和運營任務。開發者能夠利用它方便的實現：

• 應用打包和部署

• 應用腳手架生成

• 環境管理

讓開發更加聚焦於手頭的任務，而不是爲了準備工做而分散太多精力。

前面說了Composer的那麼多好處，接下來講說Composer的侷限性。就目前的文檔來看，我沒有看到如何用它來開發System Chaincode的例子。並且，我懷疑當前的版本並不支持。所以，假如你像要開發的System Chaincode，Composer可能並不能知足你的須要。而這一任務應該算不上一個大衆型任務。

或許你會奇怪，爲何我沒有展現一個實際的例子來證實我說的這些好處。這隻能怪Composer的文檔寫得太好了，基本是傻瓜式教程，按照它的步驟，基本不會出現什麼問題。既然是這樣，幹嗎還要花時間在這個上面呢？

說到底，本文的目的只有一個：用Composer來開發將來的Fabric應用，不要再自虐了！同時，最新一期的Thoughtworks雷達（地址：https://assets.thoughtworks.com/assets/technology-radar-vol-18-cn.pdf）也將其列爲「TRIAL」並給出了下面的評語：

... However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure.

最後，請你們記住：即便Composer下降了開發的門檻，但仍是要記得認真學習Fabric文檔喲！

本文做者：HiBlock區塊鏈技術佈道羣-胡鍵

原文發佈於簡書

如下是咱們的社區介紹，歡迎各類合做、交流、學習：）