---
tags: 技術文章,BlockChain
GA: UA-79596126-4
title: Blockchain - Hyperledger Fabric
---
###### 作者: 史綽琳
###### 撰寫日期: 2020/10/21 ~ 2020/12/24
{%hackmd BJrTq20hE %}

# Blockchain - Hyperledger Fabric
這是我大概從2020/08研究跟實作到2020/12的筆記結果，以下內容都有在實際環境中進行部署與驗證，不論是在 docker 用 container 測試或是在 k8s 部署成一個 BaaS (Blockchain as a Service)均已成功上線並使用了 !

這邊主要先介紹 hyperledger fabric ，部署流程跟我使用的 yaml 檔就分成下一篇說明吧，不然光看這邊可能就要好久了~~
***
首先關於區塊鏈，大家先想到的叫做比特幣，然而比特幣不等於區塊鏈，他只是在區塊鏈上的一種應用，同時區塊鏈發展至今也慢慢區分很多了，在講 Hyperledger Fabric 之前，讓我們先聊聊所謂「公有鏈」與「私有鏈」

## 公有鏈
公有鏈就跟公有雲的概念很像，任何人都可以加入公有鏈的區塊鏈之中進行一些交易 (挖礦)，這也是大家最熟知的區塊鏈的概念。區塊鏈有兩大特色：**去中心化**與**不可竄改性**

### 去中心化
顧名思義就是不存在所謂的『中央』，舉例來說，當你想刷卡買一袋蘋果的時候，信用卡一刷下去便會連接到該銀行幫你做認證，確認這是你所發出來的「交易」，待審核通過後，這筆交易便會完成，同時該銀行也會記錄你在「xxxx年xx月xx日的xx點xx分買了一袋蘋果」，這就是傳統的交易。

而在區塊鏈的網路中，所謂的銀行機構直接被其他一般使用者所取代，簡單來說，當你想用信用卡買這袋蘋果時，你的「家人」會幫你確認「你真的要買這袋蘋果嗎?」、「你的錢購買這袋蘋果嗎?」等等訊息，當你的「家人」認為你有「足夠的錢」可以買這袋蘋果，並且買這袋蘋果也是「允許的」，所有的「家人」便會在自己的帳本上新增這筆交易，而越快新增完成這筆交易的人，便可以獲得一些獎勵，這就是所謂的『挖礦』。

### 不可竄改
在區塊鏈中，每一個區塊都會基於前一個區塊的標頭資訊進行 hash，因此若惡意攻擊者想對其中一個區塊進行竄改的話，他則需要連同前面的區塊一起改，否則不會成功，如圖所示

至於在公有鏈中，我們要如何判斷誰先完成這筆交易呢?
這必須仰賴共識演算法的機制，透過不同的共識演算法可以得到不同類型的效益 !

### 共識演算法
共識演算法在區塊鏈中也是核心之一，所有的節點都會依據共識演算法的規則去比較誰先誰後，比較有名的如：PoS、PoW、PBFT等等，這些演算法都有各自的優缺點，(( 挖礦這回事呢就是用PoW~~

算力證明 - PoW
優點：
1. 為最安全的公有鏈共識機制
2. 機制較簡單容易實行
3. 相對公平的挖礦機制(也就是加密貨幣的產生與分配)

缺點：
1. 消耗大量能源
2. 區塊地確認時間較難縮短
3. 可能產生分岔，需等待多個確認才能完成交易


權益證明 - PoS
優點：
1. 不須競爭算力，因此低耗能
2. 競爭寫入權的成員必定擁有貨幣
3. 相較於POW，同樣規格的硬體可保護更多的鏈上資產

缺點：
1. 擁有權益的成員未必希望餐與記帳
2. 有心人士若取得寫入權，則可以輕易改寫出另一條假鏈
3. 沒有懲罰機制
4. 運行POS需額外機制改善其狀況，故整體架構較POW複雜


實用拜占庭容錯算法 - PBFT
優點：
1. 系統在容錯範圍內無法被分岔
2. 系統在容錯範圍內可容忍任何類型的錯誤
3. 驗證與共識速度極快
4. 不須競爭算力，因此低耗能
5. 區塊具備終局性

缺點：
1. 若超過1/3的驗證節點故障時，則系統無法運作
2. 無防範駭客偽造大量驗證節點的能力

然而，區塊鏈也不是絕對的安全，最常見的區塊鏈攻擊就是『51%攻擊』
### 51%攻擊
所謂的51%攻擊，即是代表惡意攻擊者透過手段取得了整個區塊鏈網路51%的使用權限，因此不論我們使用哪種類型的共識演算法，在51%攻擊中都只是時間上的問題而已。

要提升區塊鏈的安全，即代表區塊鏈網路中的節點要越多越好，這也是為甚麼在挖礦的狀況中，很難被竊取你自己的帳本資料。

## 私有鏈
跟私有雲一樣，要加入這個類型的區塊鏈會變成所謂的「許可」制度，也就是說成為該區塊鏈節點的每一個人都是被這個區塊鏈集團所許可的，這種類型的區塊鏈仍然存在著去中心化以及不可竄改的特性，每一筆交易仍是透過在私有鏈的所有節點負責，並且每個新的區塊也都一樣會根據前一個區塊的標頭資訊去做 hash。

而在私有鏈中，最著名的莫過於由 IBM 所提出的 hyperledger 系列，其中 Fabric 更是 Hpyperledger 中最符合企業使用的私有鏈開源專案

### Hyperledger Fabric
Fabric 專案是 hyperledger 於 2015 最早的開發專案，此架構提供企業級所需的基本區塊鏈架構，在介紹運作原理之前，先看看他的基本架構
使用者或維護者可以透過CLI或是SDK等方式進入 hyperledger fabric 進行操作，這之中我們可以先分成三大部分進行解釋：
1. Blockchain Service
在講MSP之前，我們先來說說在 Hyperledger Fabric 中的基本元件有哪些
1. peer - peer 在 fabric 中是發起交易並儲存帳本的元件，可做為一般交易節點、背書政策節點、跨組織溝通節點等，後續說明運作原理時會提到何謂背書政策。
2. orderer - orderer 在 fabric 中是作為排序節點，主要負責處理交易的順序，以及驗證此筆交易是否合法，而 orderer 與 orderer 之間會透過不同的共識演算法進行排序管理。(2.0版之前支援 solo 與 kafka，2.0之後僅支援 raft)。
2. Membership (MSP)
MSP 是 Hyperledger Fabric 的身分資訊管理，主要控管節點權限、使用者登入權限、發放金鑰憑證等，節點權限如上述第一點說明，peer 與 orderer 的權限會不同。
3. Chaincode Service
Chaincode 則是在 fabric 中的智慧合約，可以將此合約定義為資產管理、生產履歷等用途，使用者必須遵照該 chaincode 規則新增交易。通常 chaincode 會透過 go 語言進行撰寫，官方說明支援 java 與 java script，但個人推薦透過 go 寫的應用較不會有什麼問題。
4. Event Stream
在 fabric 中我們可以將其理解為 channel，而在 fabric 中所謂的帳本便是存在於 channel 中，至於上述所提到的「peer 會儲存帳本」這回事呢，他其實是儲存 channel 上的副本，而非正本；也因為如此，當一個新的 peer 加入該 channel 時，並不需要一筆一筆的交易資料輸入至該 peer 節點，僅須從 channel 上將正本複製一分到 peer 中即可同步交易狀態。一個基本的 fabric 會存在兩種 channel：
1. system channel - 該 channel 主要用於 orderer 與 orderer 之間的溝通，所以想要新加入的 peer 節點或是 orderer 節點均須將其狀態寫入創世區塊，而所謂的創世區塊便是存在於 system channl 中，在此 channel 中不會存在任何的 chaincode，僅記錄整個 fabric 網路的所有交易流程與節點存在狀態。
2. application channel - 該 channel 主要則是會在上面運行 chaincode，一個 app channel 可以同時存在超過一個 chaincode，而每個 chaincode 均有獨立的帳本，這本帳本會寫在 channel 的區塊當中，每次我們要去得交易資料時，

講完基本架構之後，現在來看看它的細節，首先我們先來說說運作流程，請看下列流程圖

st=>start: 開始
e=>end: 結束
op=>operation: 所有參與peer均安裝欲使用的chaincode
op2=>operation: 一名使用者透過CLI/SDK發起一筆交易
並符合chaincode的規則
(此處舉例背書政策需要3個peer同意)
cond=>condition: 此筆交易是否
符合背書政策？
(有至少三個peer
認證簽名)
op3=>operation: 將此模擬完成的交易送至orderer進行排序
(此處透過共識演算法進行排序)
st->op->op2->cond
cond(yes)->op3
cond(no)->e
op4=>operation: 將排序完成的內容送回各個參與peer節點
cond2=>condition: 收到的peer驗證此內容
是否與原先模擬結果相同
op5=>operation: 更新帳本內容
cond2(yes)->op5
cond2(no)->e
op3->op4->cond2

這邊補充幾點對於上述流程的說明
* 當 peer 收到使用者發來的交易訊息時，會先針對這筆交易進行身分驗證以及模擬運行結果。模擬結果主要用以先驗證此筆交易是否符合 chaincode 規則，其次當 orderer 完成排序並驗證無誤後，便可以直接將模擬結果寫入帳本，無須再驗證是否符合 chaincode 規則，可以減少交易完成的時間。
* 背書政策顧名思義就是 peer 要為這筆交易進行負責，如同我們簽署一些文件會有需要有主管為我們背書此結果是可以被接受的，通常背書政策會在撰寫chaincode時進行定義，因此對於想提出chaincode服務的客戶必須對於自己想要的安全性進行時間成本考量 (背書需求節點越高，則所需花費的時間越多但相對安全，反之則花費較少時間但相對不安全。51%攻擊的概念)，而對於終端使用者而言只需發起的交易可以符合背書政策的要求即可 (包含交易格式等)。
* peer 模擬完成後，會將結果留在 peer 端，而將交易的標頭資訊經過 hash 後送至 orderer 進行排序，因此對於 orderer 而言它不需要知道交易的結果，只需要對交易的順序進行先來後到的排序即可。

接著就來好好解釋個個元件的說明，下圖為實際環境
1. Peer
Peer 是 Hyperledger Fabric 重要的核心之一，所有的交易以及使用者的命令均來自於此，其中 peer 可以看成三種狀態：
(1) Commit peer - 負責發起交易以及最後通過時的保存。
(2) Endorse peer - 進行背書政策時使用。
(3) Anchor peer - 不同組織互相溝通用。
一個 peer 不會侷限成只能成為 commit peer 或是 endorse peer 的狀態，只有 anchor peer 是在部署時便已經決定是由哪個 peer 擔任，雖然我們可以限定那些 peer 是可以給使用者連線使用的，但該 peer 同時仍能以 endorse peer 的身分協助驗證其他 peer 所發起的交易。
peer 對於使用者以及開發者而言，是進入 hyperledger fabric 的手段，因此登入 peer 的權限必須清楚地限定清楚，通常一個 peer 也會安裝不只一個 chaincode，因為在 BaaS 中不會只存在一個 channel ，因此每個 peer 會同時接任許多 channel 的一份子。
3. Orderer
Orderer 負責處理交易先來後到的排序問題，由於他不處理任何交易的內容，僅需選出誰先來誰後來即可，因此 orderer 的數量僅會影響交易速度，相對 peer 較不會影響整體網路的安全性。Orderer 之間會透過共識演算法進行計算，共識演算法的種類如上述公有鏈中的舉例，但在 hyperledger fabric 中我們所使用的演算法通常不太在乎身分驗證的問題，最主要是因為加入此 fabric 網路的節點，均是受到可信才可加入的，此為私有鏈的特色。
Fabric 網路所使用的共識演算法有三種：solo、kafka、raft，由於solo、kafka在2.0版以後已經不再更新或修補，因此這邊主要推薦使用raft ([raft 說明原理在此](http://thesecretlivesofdata.com/raft/))，由於 raft 演算法是用選舉投票的方式決定優先順序，因此建議部署 orderer 節點應為奇數個。
5. Channel
Channel 就是所有交易溝通的地方，這裡存在著各種不同類型的帳本，所有的 peer 的交易更新均會在 channel 中傳遞，而每當交易成立時，peer 便會同步自身的帳本並與 channel 上所有合作的 peer 進行同步。其中， channel 分成兩種類型：
(1) application channel：交易與溝通的場所，包含 peer 與 orderer、peer 與 peer 等，一個 channel 可以同時運行不只一本帳本，但為了區分不同帳本，通常一個 channel 還是只會運行一本帳本。
(2) system cahnnel：僅提供 orderer 溝通做為使用，一般使用者包含 peer 不會使用該通道。
7. Chaincode
這是編輯帳本格式、儲存內容等相關訊息的地方，通常開發者會自行設計一個規範，要求終端使用者發起的交易必須符合開發者所定義的 chaincode，同時可以進行交易的 peer 節點均需安裝此 chaincode，目前主要撰寫語言已 go 為主，但仍支援 java、java script等語言撰寫。
9. CLI / SDK
CLI (Command-line interface) 與 SDK (Software Development Kit) 都是協助開發者架設 fabric 的方式，SDK 提供 java、java script、go 的三種版本，並且透過 api 可以相對方便的將一個完整的 fabric 服務部署出來，但在2.x的 fabric 中 java 與 java script 的 SDK 出現不少 bug，因此這兩個版本我就沒有在實驗的環境中使用了。
CLI 這邊就不特別做解釋，會看這篇但不會用 connand-line 的人應該不存在，雖然我的部署都是透過 CLI 指令進行操作，但我相信用 SDK 的輔助應該還是比較方便，看個人摟!
11. CA server
說道許可制的區塊鏈，重點當然會是身分管理的套件，fabric 提供憑證與金鑰的簽發，可以透過兩種方式進行 fabric 的身分管理
(1) cryptogen：這是最快速也最簡單的憑證金鑰簽發套件(類似 openssl )，網路上許多 fabric 的範例程式中都會先透過該套件進行金鑰憑證管理。對於初學者來說，透過該套件就不需要考慮太多問題，包含金鑰演算法、domain name等問題，但實際部署不推薦這種方式，並竟不是第三方認證過的憑證，如何保證安全可靠性會成為很大的疑慮。
(2) fabric-ca-server/fabric-ca-client：利用 client and server 的概念，所有的憑證均透過 fabric-ca-client 向 fabric-ca-server 取得，並且可以將第三方認證的憑證放入 fabric-ca-server 中，也可以自行定義想要使用的 domain name、金鑰演算法、ldap管理、金鑰憑證儲存的 sql 等。
透過相關參數，也可以進行中繼憑證的設定，這之中便可以根據組織結構進行 ca-server 的架設，其結構可如下圖所示
透過fabric-ca-server 與 clinet 可以提升整個 fabric 網路的彈性與安全，因此在實際部署的環境中，便需要透過此種架構才可進行服務。

# 感想與幹話
講了這麼多，原理跟元件大概是這樣，實際部署的時候當然還會遇到一些有趣(?)的問題，我在這段期間實際操作的都是環境的部署、設計與規劃，這之中重新打掉重來太多次了，尤其 fabric 1.4.x ~ 2.x 這中間更新了很多東西，第一次體驗的時候，光是官方提供的 fabric-sample 就已經有差異了，所以想玩玩看的朋友建議直接從2.x開始體驗。

在操作 fabric-ca 的時候一定要很注意，這裡面的毛超多，請在部署之前想清楚你的架構到底要長甚麼樣子，哪把鑰匙發下來要給誰註冊，擁有這把鑰匙的人可以使用的權限是什麼(admin? peer? orderer? client?)，建議要先去官網把 fabric-ca 到底怎麼弄得看[清楚](https://hyperledger-fabric.readthedocs.io/en/release-2.2/membership/membership.html)，<font color="#D5DA18">不要網路上看到就直接部，你會哭</font>。

近期(執筆日期2020/12/24)應該會把部署流程放上來，會提供兩種不同的環境部署，一個是 docker、另一個則是在 k8s ，看心情跟狀況再更新 (只要那位郭董不要再雞巴應該就還好XD)。