HyperLedger Fabric開發實戰：快速掌握區塊鏈技術（簡體書）

本書系統地介紹了超級賬本HyperLedger Fabric v1.1架構的設計和應用方法，包括環境及源碼部署、Solo單機多節點部署、Kafka多節點集群具體應用、智能合約編寫等。同時，針對第三方可插拔式插件CouchDB實戰應用，JAVASDK的應用、編寫方案和具體接口執行策略也進行了詳細講解。另外，本書以搭建一個反欺詐區塊鏈平臺項目為例進行了實戰演練，讀者可以快速掌握區塊鏈技術。

前言
HyperLedger Fabric最初是由Digital Asset和IBM公司貢獻的、由Linux基金會主辦的一個超級賬本項目，它是一個目前非常流行並廣為人知的區塊鏈網絡框架的實現方案。作為一種基於模塊化架構開發應用程序或解決方案的基礎，HyperLedger Fabric支持如共識和會員服務等即插即用的組件。HyperLedger Fabric利用容器技術來運行稱為“chaincode”的智能合約，該合約包含了系統的應用程序邏輯。

為什麼寫作本書
區塊鏈由於去中心化、開放性、自治性、信息不可篡改及匿名性等特徵而受到廣泛關注，且目前正處在上升勢態。拋開炒作的代幣項目，應用於行業聯盟鏈或直接搭建私鏈的項目，採用HyperLedger Fabric作為底層平臺無疑是最好的選擇之一。
本人從接觸HyperLedger Fabric項目以來，經歷了其0.6版本到1.1版本的數次迭代。因為早期中文資料稀缺，並且0.6版本到1.0版本是一個跨度非常大的迭代，導致早期的大部分部署和應用經驗失去作用，不得已再次從1.0版本開始從頭學習。當時中文資料極為有限，且大多數都是單篇翻譯或純粹的概念講解，導致我一直沒有找到入門的頭緒，只能不斷地從官方文檔中汲取知識，並成功搭建了基於Kafka類型的集群網絡。
有了集群的經驗，加深了自己對HyperLedger Fabric整個網絡事務流程的理解，並以此為基礎順利搭建了基於Fabric-SDK-Java的客戶端項目。也就在這個時候，開始有了寫相關博客的想法，並在博客園上發佈了第一篇博客，也是從零開始系列文章的第一篇，開始介紹自己的開發歷程和部署經驗，希望能通過這樣的方式幫助更多的開發夥伴加入HyperLedger Fabric大家庭。再後來又建立了“區塊鏈學習分享”的微信訂閱號，也通過微信號建立了一個純技術討論分享的HyperLedger Fabric等區塊鏈相關交流群，並在這樣的機緣下結識了電子工業出版社宋亞東老師，並正式開始編寫本書。
在寫書之前我一直在梳理博客的內容，為了真實地還原生產場景，還自費租賃了15台服務器用於測試。有已有博文的基礎外加後來編寫的新文檔，我比較順利地完成了本書的編寫工作，且書中的項目都依託於所租賃服務器來完成演練，每一步都基於真實情況和場景中的操作。在此過程中，自己對HyperLedger Fabric也有了新的認識和理解。
本書主要以HyperLedger Fabric案例為引，層層深入，從單機單節點到Solo多機組網再到Kafka集群部署，其中穿插文檔講解加深讀者的理解。與一些偏概念性質的區塊鏈教程類書籍不同，我希望能通過本書幫助讀者實現基於HyperLedger Fabric的區塊鏈實踐落地。

本書主要內容
本書以乾貨為主，文檔為輔，基於HyperLedger Fabric v1.1版本進行講解。總計10章，每章主要內容介紹如下：
第1章是基本環境部署，包括內網和外網的不同方案，以及內核處理等。
第2章是HyperLedger Fabric及環境部署，先是用文檔講述了Fabric相關的介紹和主要功能點，接著分析了源碼部署和鏡像處理方面的問題。
第3章帶著讀者一步步跑通官方的e2e_cli案例，並在隨後對該案例進行了分析。
第4章開始，手動部署一次單機多節點網絡。
第5章跟隨前章的腳步，手動部署一次Solo多機網絡環境。
第6章繼續深入，搭建基於Kafka的集群網絡。
第7章以文檔為主，著重講解如何編寫智能合約及有關智能合約的用法。
第8章詳細介紹CouchDB的使用，並推薦使用CouchDB。
第9章講解在Fabric發佈1.0版之後的對外客戶端調用方式、客戶端對SDK的使用和相關源碼。
第10章以一個簡單的案例做演練，在數據鏈上用到了智能合約，對數據提取則提供了另一種思路。

讀者對象
這是一本基礎講解類的書，寫本書是為了幫助更多的新人入門。所以，本書適合正在尋求HyperLedger Fabric入門的新人，也適合這方面的中、高級開發人員用作工具書。
在閱讀本書之前，讀者需要具備以下基礎知識：
? 具有一定的Linux操作系統基本命令的常識。
? 有Java/Go等面向對象語言的基礎，其中智能合約用Go語言編寫，SDK則用到了Java。如果有這方面的基礎，則有助於閱讀本書。

致謝
在入門及編寫本書的時候，有許多人給予了我鼓勵和支持。
首先感謝我的妻子，我在開始學習HyperLedger Fabric時遇到了很多困難，經常熬夜加班，她始終體諒我，鼓勵並支持我。在我寫書的時候她不遺餘力地幫我查閱相關資料以便我能夠更順利地完成書稿。
我還要感謝我的領導，也是我的好友王海林，正是他給了我研究學習HyperLedger Fabric的機會，並在我遇到困難時幫我逐條分析，厘清思路。他也給予了我在公司最大限度的研發條件和時間，讓我在最短的時間裡完成了一次自我蛻變。
我還要感謝電子工業出版社的宋亞東老師，感謝他一直以來對我的支持和鼓勵，感謝在我早期編寫書稿的過程中對內容的編排和規範給予了很多幫助。也感謝電子工業出版社所有參與本書出版工作的老師，是你們的辛勤付出讓本書成功出版。
最後，我要感謝我博客的讀者及微信群裡的朋友們，正是與你們一次次地溝通和探討，讓我不斷提升自我，也鞭策我不斷前行。
由於我水平有限，書中不足及錯誤之處在所難免，敬請專家和讀者給予批評指正。
楊毅
2018年5月

第1章 基本環境部署 1
1.1 環境整理 1
1.2 Docker安裝 2
1.2.1 卸載舊版本 3
1.2.2 在線安裝Docker CE 3
1.2.3 離線安裝Docker CE 5
1.2.4 Docker啟動及常用命令 5
1.3 Docker-Compose安裝 6
1.3.1 在線安裝Docker-Compose 6
1.3.2 離線安裝Docker-Compose 7
1.4 Go語言環境安裝 8
1.4.1 下載Go語言包 8
1.4.2 配置Go語言環境變量 9
1.5 本章小結 9

第2章 Fabric及環境部署 10
2.1 Fabric介紹 10
2.1.1 什麼是區塊鏈 10
2.1.2 區塊鏈的作用 12
2.1.3 超級賬本是什麼 14
2.2 Fabric功能匯總 16
2.3 Fabric組成模型 17
2.3.1 資產 18
2.3.2 智能合約 18
2.3.3 賬本特徵 18
2.3.4 隱私頻道 19
2.3.5 成員安全性 20
2.3.6 共識機制 20
2.4 Fabric環境部署 20
2.4.1 Fabric源碼安裝 20
2.4.2 下載Fabric鏡像 22
2.4.3 鏡像備份和遷移 26
2.5 本章小結 28

第3章 End-2-End案例 29
3.1 平臺特定文件 29
3.2 運行e2e_cli 31
3.3 e2e_cli案例分析 38
3.3.1 容器服務腳本 38
3.3.2 容器啟動配置文件 52
3.3.3 Fabric網絡解析 55
3.4 本章小結 62

第4章 部署單機多節點網絡 64
4.1 生成證書文件 65
4.2 部署Orderer節點 69
4.3 部署peer0.org1節點 70
4.4 搭建Fabric網絡 75
4.5 初步接觸智能合約 78
4.6 部署peer0.org2節點 84
4.7 本章小結 88

第5章 Solo多機部署 89
5.1 網絡拓撲 89
5.2 部署Orderer節點 91
5.3 部署peer0.org1節點 92
5.4 部署peer1.org1節點 97
5.5 部署peer0.org2節點 101
5.6 本章小結 107

第6章 Kafka集群部署 108
6.1 Fabric賬本 108
6.2 事務處理流程 110
6.2.1 客戶端發起事務 111
6.2.2 驗證簽名並執行事務 112
6.2.3 檢查返回協議 112
6.2.4 客戶端將背書合併到交易中 113
6.2.5 提交並驗證事務 113
6.2.6 賬本更新 114
6.3 讀寫集規則 114
6.4 Kafka集群配置 116
6.4.1 crypto-config.yaml配置 119
6.4.2 configtx配置 121
6.4.3 Zookeeper配置 125
6.4.4 Kafka配置 127
6.4.5 Orderer配置 132
6.5 啟動集群 138
6.5.1 啟動Zookeeper集群 138
6.5.2 啟動Kafka集群 140
6.5.3 啟動Orderer集群 144
6.6 集群環境測試 146
6.7 本章小結 158

第7章 智能合約 159
7.1 智能合約概述 159
7.2 背書策略 160
7.3 使用智能合約 161
7.3.1 智能合約是什麼？ 161
7.3.2 智能合約的生命週期 161
7.3.3 Packaging（包） 162
7.3.4 創建package（包） 162
7.3.5 包簽名（Package signing） 163
7.3.6 安裝智能合約 164
7.3.7 智能合約實例化 164
7.3.8 升級智能合約 165
7.3.9 停止及啟動智能合約 166
7.3.10 CLI（客戶端） 166
7.3.11 系統智能合約 168
7.4 編寫智能合約 168
7.4.1 開發人員眼中的智能合約 168
7.4.2 智能合約接口 169
7.4.3 一個簡單的資產智能合約 169
7.5 加密智能合約 178
7.6 系統合約插件 180
7.7 智能合約API 182
7.8 Peer節點與合智能約 184
7.8.1 安裝智能合約 185
7.8.2 實例化智能合約 187
7.8.3 調用智能合約 188
7.8.4 列出智能合約 190
7.8.5 打包智能合約 191
7.8.6 查詢智能合約 192
7.8.7 簽名智能合約包 193
7.8.8 升級智能合約 194
7.9 本章小結 196

第8章 CouchDB 197
8.1 CouchDB介紹 197
8.2 啟動部署 201
8.3 索引應用 206
8.4 查詢應用 216
8.5 選擇器語法 218
8.5.1 基本語法 218
8.5.2 嵌套對象 219
8.5.3 運算符 219
8.5.4 隱式運算符 220
8.5.5 顯示運算符 222
8.6 本章小結 226

第9章 J -SDK客戶端 227
9.1 SDK項目前置條件 227
9.2 SDK代碼使用 232
9.2.1 Orderers對象 233
9.2.2 Peers對象 235
9.2.3 Chaincode對象 238
9.2.4 FabricUser 240
9.2.5 FabricStore 245
9.2.6 FabricOrg 250
9.2.7 FabricConfig 256
9.2.8 ChaincodeManager 257
9.3 SDK使用方法 264
9.4 本章小結 269

第10章 項目演練 270
10.1 反欺詐系統 271
10.1.1 需求分析 271
10.1.2 編寫合約 272
10.1.3 線上驗證 278
10.3 本章小結 283

根據前面章節的介紹，知道了Fabric組網過程的第一步是需要生成證書等文件，而這些默認配置信息的生成依賴於configtx.yaml及crypto-config.yaml配置文件。
同樣，在採用Kafka作為啟動類型的Fabric網絡中，configtx.yaml及crypto-config.yaml配置文件依然有著重要地位，且其中的配置樣本與先前的內容都會有些不同。
本章是以Kafka集群部署為案例開始講述，在此之前，請先閱讀前面的章節。
在閱讀本章的時候會涉及一些概念性問題，這些概念性問題從第3章開始就屢次提及，但第3、4、5章中的目的主要是跑通一個最小單元的Fabric網絡，需要讀者首先對HyperLedger Fabric的網絡進行一次基本的理解，要知曉HyperLedger Fabric網絡在實際生產過程中可能應用到哪些場景中。
而本章將開啟基於Kafka集群的部署，其中重要的概念是對前三章的總結，也是對本章及後續章節關於智能合約及CouchDB的鋪墊。
6.1 Fabric賬本
1．賬本（Ledger）
即所有的狀態變更（state transitions）是有序且不可篡改的。狀態變更是由參與方提交的chaincode（智能合約）調用事務（transactions）的結果。每個事務都將產生一組資產鍵-值對，這些鍵-值對用於創建、更新或刪除而提交給賬本。
賬本由BlockChain（區塊鏈）（“chain”）組成，區塊則用來存儲有序且不可篡改的記錄，以及保存當前狀態的狀態數據庫（state database）。在每一個Channel中都會存在一個賬本。每一個Peer都會維護它作為其中成員的每一個Channel中的本地複製的賬本。
2．鏈（chain）
鏈是一個事務日誌，是一個由Hash鏈接各個區塊的結構，其中每個區塊都包含了N個事務的序列。
區塊header包含了該區塊的事務的Hash，以及上一個區塊頭的Hash。這樣，所有在賬本上的交易都是按順序排列的，並以密碼方式鏈接在一起。換句話說，在不破壞Hash鏈接的情況下篡改賬本數據是不可能的。最近的區塊Hash代表了以前的每個事務，從而確保所有的Peers都處於一致和可信的狀態。
鏈存儲在Peer文件系統（本地或附加存儲）上，有效地支持BlockChain工作負載的應用程序的特性。
3．狀態數據庫
該賬本的當前狀態數據表示鏈事務日誌中包含的所有鍵的最新值。
由於當前狀態表示Channel所知道的全部最新鍵值，因此有時也稱為“World State（世界狀態）”。
在Chaincode調用對當前狀態數據執行操作的事務時，為了使這些Chaincode交互非常有效，所有鍵的最新值都存儲在一個狀態數據庫中。狀態數據庫只是一個索引視圖到鏈的事務日誌，因此可以在任何時候從鏈中重新生成它。在事務被接受之前，狀態數據庫將自動恢復（或在需要時生成）。
狀態數據庫包括LevelDB和CouchDB。LevelDB是嵌入在Peer進程中的默認狀態數據庫，並將Chaincode數據存儲為鍵-值對。CouchDB是一個可選的外部狀態數據庫，當所寫的Chaincode數據被建模為JSON時，它提供了額外的查詢支持，允許對JSON內容進行豐富的查詢。
4．事務流（transaction flow）
在高層業務邏輯處理上，事務流是由應用程序客戶端發送的事務協議，該協議最終發送到指定的背書節點。
背書節點會驗證客戶端的簽名，並執行一個Chaincode函數來模擬事務。最終返回給客戶端的是Chaincode結果，即一組在Chaincode讀集中讀取的鍵-值版本，以及在Chaincode寫集中寫入的鍵-值集合，返回該Peer執行Chaincode後模擬出來的讀寫集結果，同時還會附帶一個背書簽名。
客戶端將背書組合成一個事務payload，並將其廣播至一個ordering service（排序服務節點），ordering service為當前Channel上的所有Peers提供排序服務並生成區塊。
實際上，客戶端在將事務廣播到排序服務之前，先將本次請求提交到Peer，由Peer驗證事務。
首先，Peer將檢查背書策略，以確保指定的Peer的正確分配已經簽署了結果，並且將根據事務payload對簽名進行身份驗證。
其次，Peer將對事務讀取集進行版本控制，以確保數據完整性，並防止諸如重複開銷之類的問題。Hyperledger Fabric具有併發控制，即事務允許並行執行（通過背書）來增加吞吐量，並且在提交（所有Peer）的情況下，每個事務都經過驗證，以確保沒有其他事務修改它已經讀取的數據。換句話說，它確保了在執行（批准）時間之後讀取的數據沒有發生變化，因此執行結果仍然有效，並且可以提交到賬本狀態數據庫。如果讀取的數據被另一個事務更改，則該區塊中的相同事務被標記為無效，並且不應用於賬本狀態數據庫。客戶端應用程序被警告，並且可以在適當的情況下處理錯誤或重試。