Hyperledger Fabric入門實戰（三）——Fabric基礎知識

1. Fabric基本概念

1.1 邏輯架構

Fabric架構的核心包括三部分：

• Identity - 身份管理
• Smart Contact - 智能合約
• Ledger及Transactions - 賬本和交易

1. Identity

Identity，也就是身份管理，Fabric是目前爲止在設計上最貼近聯盟鏈思想的區塊鏈。聯盟鏈考慮到商業應用對安全、隱私、監管、審計、性能的需求，提高准入門檻，成員必須被許可才能加入網絡。Fabric成員管理服務爲整個區塊鏈網絡提供身份管理、隱私、保密和可審計的服務。成員管理服務通過公鑰基礎設施PKI和去中心化共識機制使得非許可的區塊鏈變成許可制的區塊鏈。

2. Smart Contract

Fabric的智能合約smart contract稱爲鏈碼chaincode，是一段代碼，它處理網絡成員所同意的業務邏輯。和以太坊相比，Fabric鏈碼和底層賬本是分開的，升級鏈碼時並不需要遷移賬本數據到新鏈碼當中，真正實現了邏輯與數據的分離。

鏈碼可採用Go、Java、Node.js語言編寫。鏈碼被編譯成一個獨立的應用程序，fabric用Docker容器來運行chaincode，裏面的base鏡像都是經過簽名驗證的安全鏡像，包括OS層和開發chaincode的語言、runtime和SDK層。一旦chaincode容器被啓動，它就會通過gRPC與啓動這個chaincode的Peer節點連接。

3. Ledger | Transactions

Fabric使用建立在HTTP/2上的P2P協議來管理分佈式賬本。採取可插拔的方式來根據具體需求來設置共識協議，比如PBFT，Raft，PoW和PoS等。

• Ledger

  賬本Ledger主要包含兩塊：blockchain和state。blockchain就是一系列連在一起的block，用來記錄歷史交易。state對應賬本的當前最新狀態，它是一個key-value數據庫，Fabric默認採用Level DB, 可以替換成其他的Key-value數據庫，如Couch DB。舉個例子。我們採用區塊鏈實現一個彈珠交易的系統。我們開發了一個Chaincode, 每個彈珠有以下幾個屬性：Name, owner, color, size. 可以定義一個JSON對象，用name做KEY, JSON對象做Value，存儲在Level DB或者CouchDB中。

• Transactions

  Fabric上的transction交易分兩種，部署交易和調用交易。

  • 部署交易

    把Chaincode部署到peer節點上並準備好被調用，當一個部署交易成功執行時，Chaincode就被部署到各個peer節點上。好比把一個web service或者EJB部署到應用服務器上的不同實例上。

  • 調用交易

    客戶端應用程序通過Fabric提供的API調用先前已部署好的某個chaincode的某個函數執行交易，並相應地讀取和寫入K-V數據庫，返回是否成功或者失敗。

APIs,Events,SDKs

站在程序猿的角度Fabric開發主要包括客戶端和服務器端應用程序的編寫

• 服務器端

  Fabric提供API方便應用開發，對服務端的ChainCode，目前支持用Go、Java或者Node.js開發。

• 客戶端

  對客戶端應用，Fabric目前提供Node.js和Java SDK, Go SDK。未來計劃提供Python，Fabric還提供RESTAPI。

對於開發者，還可以通過CLI快速去測試chaincode，或者去查詢交易狀態。在區塊鏈網絡裏，節點和chaincode會發送events來觸發一些監聽動作，方便與其他外部系統的集成。

Fabric 應用開發流程

如下圖所示，開發者創建客戶端應用和智能合約（chaincode），Chaincode被部署到區塊鏈網絡的Peer節點上面。通過chaincode來操作賬本，當你調用一個交易transaction時，你實際上是在調用Chaincode中的一個函數方法，它實現業務邏輯，並對賬本進行get, put, delete操作。客戶端應用提供用戶交互界面，並提交交易到區塊鏈網絡上。

• 成員管理（MemberShip）
  • 會員註冊
    • 註冊成功一個賬號得到的不是用戶名密碼
    • 使用證書作用身份認證的標誌
  • 身份保護
  • 交易審計
  • 內容保密
    • 可以多條區塊鏈, 通過通道來區分的
• 賬本管理
  • 區塊鏈
    • 保存所有的交易記錄
  • 世界狀態
    • 數據的最新狀態
    • 數據存儲在當前節點的數據庫中
      • 自帶的默認數據庫: levelDB, 也可以使用couchdb
        • 以鍵值對的方式進行存儲 的
• 交易管理
  • 部署交易
    • 部署的是鏈碼, 就是給節點安裝鏈碼 - chaincode
  • 調用交易
    • invoke
• 智能合約
  • 一段代碼， 處理網絡成員所同意的業務邏輯
  • 真正實現了鏈碼和賬本的分離（邏輯和數據分離）

1.2 基礎概念

• 組織

  是指這樣一個社會實體，它具有明確的目標導向和精心設計的結構與有意識協調的活動系統，同時又同外部環境保持密切的聯繫

  在Fabric中一個組織裏邊都有什麼?

  • 有用戶
  • 有進行數據處理 的節點 -> peer
    • put -> 寫數據到區塊鏈中
    • get -> 數據查詢

• 節點

  • client

    進行交易管理(cli , node sdk, java sdk)

    • cli -> 通過linux的命令行進行通過, 使用的是shell命令對象數據進行提交和查詢
    • node.js -> 通過node.js api 實現一個客戶端
    • java -> 通過java api 實現一個客戶端
    • go也可以

  • peer

    存儲和同步賬本數據

    • 用戶通過客戶端工具對數據進行put操作, 數據寫入到一個節點裏邊
    • 數據同步是fabric框架實現的

  • orderer

    排序和分發交易

    • 爲什麼要排序?

      • 解決雙花問題
      • 沒發起一般交易都會在orderer節點進行排序

    • 交易數據需要先進行打包, 然後寫入到區塊中

• 通道 -> channel

  通道是有共識服務（ordering）提供的一種通訊機制，將peer和orderer連接在一起，形成一個個具有保密性的通訊鏈路（虛擬），實現了業務隔離的要求；通道也與賬本（ledger）-狀態（worldstate）緊密相關

consensus Server : orderer節點

三條不同顏色的線, 代表三個通道

一個peer節點是可以同時加入到不同的通道中的

peer節點每加入到一個新的通道, 存儲數據的區塊鏈就需要添加一條, 只要加入到通道中就可以擁有這個通道中的數據, 每個通道對應一個區塊鏈.

• 交易流程

要完成交易, 這筆交易必須要有背書策略的, 假設:

• 組織A中的成員必須同意
• 組織B中的成員也必須同意

1. Application/SDK : 充當的是客戶端的角色
   • 寫數據
2. 客戶端發起一個提案, 給到peer節點
   • 會發送給組織A和組織B中的節點
3. peer節點將交易進行預演, 會得到一個結果
4. peer節點將交易結果發送給客戶端
   • 如果模擬交易失敗, 整個交易流程終止
   • 成功, 繼續
5. 客戶端將交易提交給排序節點
6. 排序節點對交易打包
7. orderer節點將打包數據發送給peer, peer節點將數據寫入區塊中
   1. 打包數據的發送, 這不是時時的
   2. 有設定條件, 在配置文件中

背書策略:

• 要完成一筆交易, 這筆交易的完成過程叫背書

• 賬本