Fabric-02Peer、Orderer以及CA

五、Peer

5.1Fabric Peer

特點

聯盟鍊中，peer節點代表各個企業群組織。

區塊鍊網絡主要是由一系列peer節點組成，peer節點是整個區塊鍊網絡的基礎，因為它是賬本和智能合約的載體，通過智能合約，賬本以不可篡改的方式記錄了交易的全過程；

• 每個節點可以加入一個或多個channel；
• 每個channel維護自己的一個或多個賬本，賬本之間是隔離的；
• 每個peer可以安裝不同的智能合約；
• 交易完成後，peer會發送event事件給client端；
• 每個channel都有local MSP，提供身份認證。

種類

Committing Peer

• 維護賬本和狀态
• 驗證和送出交易

Endorsing Peer

• 為接收到的交易進行背書，并給用戶端響應
• 持有智能合約

背書政策

每個鍊碼在部署的時候都會指定背書政策；

在背書節點中，當模拟執行完結果以後，會通過ESCC (Endorsement System ChainCode)對執行結果進行簽名；

在記賬節點中，會通過VSCC (Validation System ChainCode) 根據背書政策驗證交易是否正确。

背書政策是在執行個體化鍊碼時指定，如圖就是指：在mychannel上執行個體化鍊碼mycc，并指定背書政策為AND(‘Org1MSP.member’) ，就是說隻要org1中的成員簽名，就認為交易是合理的。

5.2Fabric Ledger and State DB

Fabric賬本是有序的，不可修改的曆史交易記錄，由兩部分組成：

區塊：維護channel的配置資訊、曆史交易記錄

世界狀态：維護賬本目前狀态，友善進行快速查詢

區塊

分為三個部分：

• 區塊頭
  • 區塊編号
  • 目前區塊hash
  • 前一區塊hash
• 區塊資料
  • 交易資料
    • 頭部：包含鍊碼名字、version等資訊
    • 簽名：Client端使用者的簽名，誰發起的請求就是誰的簽名
    • 交易：使用者端給背書節點的proposal，主要是input參數
    • 響應：智能合約執行的結果，執行前的資料和執行後的資料
    • 背書：每個背書節點傳回的結果，是個list
• 區塊中繼資料
  • 區塊寫入時間
  • 區塊寫入人
  • 簽名

狀态

維護賬本的目前資訊，k-v形式，如{key=balance，value=100} version=1。

賬本樣例：

5.3Smart Contract

Smart Contract & chaincode

• Smart Contract
  • 區塊鍊的核心
  • 定義不同組織之間的業務規則或規範
  • 産生交易transaction記錄在賬本ledger中
  • 打包到鍊碼Chaincode中，一個Chaincode可以包含多個智能合約Smart Contract
• Chaincode
  • 可以打包多個智能合約Smart Contract
  • 鍊碼Chaincode部署之後，智能合約Smart Contract就可以給使用者端使用

smart contract interact with the ledger

• 智能合約由開發人員根據業務邏輯進行開發，同時還會開發Client端
• 當用戶端發送請求時，可以通過智能合約調用API去操作World state。get操作直接傳回資料，不會在區塊鍊中增加新的交易；put、delete在修改World state同時還會在區塊鍊上增加新的交易記錄，增加新的區塊；qi中delete隻會删除World state中的資料，不會删除區塊中的賬本資料，會增加新的記錄
• Blockchain提供API可以讓用戶端去通路
• 交易完成時通過智能合約發送event事件給使用者端

Chaincode Lifecycle

Package --> Install --> Instantiate --> Running --> Upgrade

Package

• 生成ChaincodeDeploymentSpec (CDS)，包括源代碼、名字和鍊碼版本号
• 指定初始化政策，即由誰來進行初始化，表達式與背書政策相同
• 由擁有chaincode的實體進行簽名

peer chaincode package -n mycc -p github.com/hyperledger/fabric-samples/
chaincode/abstore/go -v 1.0 -s -S -i "AND('OrgA.admin')" ccpack.out

peer chaincode signpackage ccpack.out signedccpack.out
           

Install

• 安裝在peer節點上
• 一個peer節點可以安裝多個不同的chaincode
• 必須安裝在channel所有的背書節點上

peer chaincode install ccpack.out
           

Instantiate

• 在通道上執行個體化一個chaincode
• 執行個體化期間設定背書政策

Running

• Client端可以發送交易請求
• 智能合約處理交易、更新賬本、傳回響應
• Client端接收響應

peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}’ 
peer chaincode invoke -o order-url -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'
           

Upgrade

• 可随時更新更新
• 更新之前，最新版本的chaincode必須已經安裝在所有的背書節點上
• 和執行個體化類似，每次隻能影響一個channel

System Chaincode

在Fabric系統中有一些System Chaincode，它運作在peer程序上，而不是像我們開發的合約運作在一個單獨的容器中。它實作了一些系統的行為。

5.4Gossip Protocol

功能

• 維護管理channel中的peer成員以及peer節點的發現
• 不斷傳播賬本資料給channel中的所有節點
• 對新加入的peer，通過點對點(peer-to-peer)的狀态傳播來更新賬本資料

資料傳輸

• 線上的peer節點通過不斷向周圍廣播存活消息來證明它們的可用性
• peer通過收集他們的存活資訊維護channel成員
• 當leader節點從order服務拿到交易資訊後，會傳播給其他節點。當一個peer收到消息後，還會散發給其他peer
• 每個peer會不斷詢問周圍的peer兩者的狀态是否比對，如果不比對就會從其他節點拉取最新的區塊，通過P2P的方式使賬本資訊保持一緻
• 一個channel上的peer節點不能傳播資料給其他channel

Leader Peer & Anchor Peer

在Gossip中，根據不同的功能，可以分為Leader Peer和Anchor Peer 。

• Leader Peer
  • 與orderer節點聯系并拉取新的區塊
  • 把交易傳播給組織中其他記賬節點，其他記賬節點收到消息後還會繼續散播
  • 在一個組織中允許存在一個或者多個Leader Peer
  • Leader Peer 選舉
    • 靜态Static
      • 系統管理者在配置的時候手動進行指定目前節點成為leader peer

      peer: 
       # Gossip related configuration 
       gossip: useLeaderElection: false 
       orgLeader: true
                 

    • 動态Dynamic
      • peer節點通過執行leader選舉程式來選舉一個leader
      • 動态選舉的leader節點會不斷發送心跳給其他peer節點證明其存活，leaderAliveThreshold指定間隔時間

      peer: 
       # Gossip related configuration 
       gossip: 
       useLeaderElection: true 
       orgLeader: false 
       election: 
       leaderAliveThreshold: 10s
                 

• Anchor Peer
  • 使用Gossip協定，確定channel上不同組織的peer節點都是互相認識的。
  • 比如OrgA中的peer節點想要傳播資料到OrgB中的peer節點，但是兩者之間不認識，那麼OrgA的節點就要先聯系OrgA的Anchor Peer，OrgA的Anchor Peer聯系OrgB的Anchor Peer，OrgB的Anchor Peer聯系OrgB的節點，然後就可以互相通信，之後就可以直接聯系。

5.5Private Data

• 隐私資料存儲在每個授權的peer節點（authorized peer）上的隐私資料庫（private database）中
• 隐私資料集合政策（Private data collection policy ）會定義授權的peer節點
• 排序服務（Ordering service）不能看到隐私資料
• 隐私資料的傳播是通過Gossip協定

Tx flow with private data

隐私資料在交易流程中的傳遞：

• 使用者端送出的請求中包括隐私資料
• 背書節點模拟執行交易時，會存儲隐私資料在一個臨時資料庫中，同時向其他有權限的peer節點傳播
• 背書節點傳回背書結果給使用者端時，不會傳回隐私資料，隻有隐私資料k-v的hash值
• 記賬節點驗證時，會驗證隐私資料的hash值，并和臨時資料庫中的資料進行比較，看是否有被修改
• 驗證通過，記賬節點會把隐私資料從臨時資料庫正式移到隐私資料庫中

private data collection

[ 
    {
    	"name": "collectionMarbles",
    	"policy": "OR('Org1MSP.member', 'Org2MSP.member')", 
        "requiredPeerCount": 0, 
        "maxPeerCount": 3,
    	"blockToLive":1000000, 
        "memberOnlyRead": true
    },
	{
        "name": "collectionMarblePrivateDetails",
        "policy": "OR('Org1MSP.member')", 
        "requiredPeerCount": 0, 
        "maxPeerCount": 3,
        "blockToLive":3, 
        "memberOnlyRead": true
	} 
]
           

一份private data collection示例，包含兩個collection，分别是collectionMarbles、collectionMarblePrivateDetails。其中以collectionMarbles為例，policy指Org1MSP.member, Org2MSP.member可以通路隐私資料；requiredPeerCount指背書節點傳回執行結果之前，為了保證私有資料已經傳播給其他節點，必須傳播給幾個peer節點；maxPeerCount指最多傳播給幾個節點；blockToLive指隐私資料在在DB中儲存多久，超過時間自動銷毀。

六、Orderer

6.1Atomic Broadcast(Total Order)

Orderer節點在流程中的作用：Orderer作為一個叢集服務，會從各個Orderer節點接收transaction，并且把接收到的所有的transaction進行全排序，并根據一定的規則打包成區塊。

Fabric作為聯盟鍊，并不是所有的人都可以出塊，都可以參與排序過程，Orderer是由允許的幾個組織來進行排序工作。

• Identical：産生完全相同的塊，最終每一個Orderer産生的塊都必須一緻；
• Crash：CFT，當叢集中的節點挂掉了，剩下的節點依然可以完成排序功能，明确最多容錯幾個節點；
• Partition：當網絡隔離之後，隔離的節點應該有拒絕寫或者拒絕讀等措施；
• Strong Consistency：不同于某些公有鍊的最終一緻性（比如比特币的最長合法鍊，6個節點确認機制等），Fabric中需要有強一緻性，不能有臨時分叉，當一筆交易送出之後，是絕對不能被覆寫的；
• BFT：拜占庭容錯，即允許作惡節點存在。Orderer本身不是拜占庭容錯，而是CFT容錯（無論是Kafka還是Raft）。但是即使Orderer節點是CFT，并不代表這個Fabric是CFT，Fabric依然是BFT，因為Fabric中還有peer的背書和驗證環節。由于Orderer節點是CFT容錯，是以有些攻擊無法防範，比如惡意節點運作Orderer，會使得Orderer網絡本身拒絕出塊，這樣使用者送出的交易可能無法寫入到賬本中，但是這種攻擊是可探查的，而且不會造成資料的丢失和篡改，即可作惡的嚴重程度是有限的。

6.2Block Cutting

如果交易已經排序完成，之後需要對其生成區塊，那麼生成區塊的規則有以下幾種：

• BatchSize
  • MaxMessageCount：一個塊中最多有多少個交易
  • AbsoluteMaxBytes：一個塊最大的絕對大小
  • PreferredMaxBytes：期待一個塊的大小是多大

  規則就是，當交易大小的總和達到了PreferredMaxBytes，或者交易個數達到了MaxMessageCount，就會打包一個區塊。

  但是要注意的是，塊的大小不可能永遠小于PreferredMaxBytes，比如PreferredMaxBytes是800，前9個交易大小是700，第10個交易就是200，那麼加一起大于800，這種情況下第10個交易也會随着前9個一起打包到區塊中。

  AbsoluteMaxBytes相當于限制了單個交易transaction的大小，超過這個的交易會被拒絕。

• BatchTimeout
  • Timeout：即使區塊沒有足夠的交易，在一定時間後也會把已有的交易打包到塊中

6.3Channel

Fabric中有System Channel，是系統預設的channel，作用就是管理使用者的channel。

Orderer啟動需要有Genises Block，該區塊規定了所有關于System Channel的配置，那麼所有的Orderer都必須用同樣的Genises Block來啟動。啟動之後系統會預設存在一個System Channel，當建立一個使用者channel的時候，其實是向System Channel發送了一個建立的交易transaction，交易中包括channel名字，配置資訊，包括哪幾個組織等屬性。System Channel拿到交易後，發現是建立channel的請求，就會建立一個channel，并把交易中包括的新channel的配置資訊，作為使用者channel的Genises Block放在系統中，這樣一個channel就建立完成。

當要修改channel的配置時，就是向channel發送一個配置的交易，配置交易是不遵循出塊規則的，永遠是自己一個塊，因為配置資訊需要盡快生效，那麼當去修改一個channel的屬性時，也是需要共識的，共識之後送出到orderer的賬本中，完成屬性更新。

6.4Consensus

Solo

Kafka

Raft

七、MSP_CA

7.1CA

CA 是 Hyperledger Fabric 的證書頒發機構（CA），是Hyperledger Fabric内一個可選的 MemberService 元件，對網絡内各個實體的身份證書進行管理，主要實作：

• 負責 Fabric 網絡内所有實體（Identity）身份的注冊。
• 負責對數字證書的簽發，包括 ECerts（身份證書）、TCerts（交易證書）。
• 證書的續簽或吊銷。

Fabric CA 在Fabric網絡中的作用：

通路 Fabric CA 伺服器可以通過 Hyperledger Fabric CA 用戶端或通過其中一個 Fabric SDK 來實作，與 Hyperledger Fabric CA 伺服器的所有通信都是通過API 進行。

Hyperledger Fabric CA 用戶端或 SDK 可以連接配接到 Hyperledger Fabric CA 伺服器叢集，叢集由 HA Proxy 等實作負載均衡。伺服器可能包含多個CA，每個CA都是根CA或中間CA，每個中間CA都有一個父CA。

Hyperledger Fabric CA 的身份資訊儲存在資料庫或LDAP中。目前 Fabric CA 支援的資料庫有 MySQL、PostgreSQL、SQLite；預設使用 SQLite 資料庫。如果配置了 LDAP，則身份資訊将保留在 LDAP 而不是資料庫中。

Fabric CA Server

配置設定：

• 指令行
• 環境變量
• 配置檔案

Fabric CA Server 參數：

• start
• init
• params
  • -b (bootstrap identity)
  • -n (ca name)
  • -u (intermediate CA)
  • -d (debug)
  • -H (home directory)
  • …
• version
• …

初始化：

fabric-ca-server init 會對CA進行初始化，生成Fabric CA Server目錄，目錄中大概包含：

• ca-cert.pem
• ca-chain.pem
• tls-cert.pem
• fabric-ca-server.db：資料庫
• fabric-ca-server-config.yaml：預設配置檔案
• IssuerPublicKey
• IssuerRevocati
• onPublicKey
• MSP

Intermedia CA：

• 避免root CA暴露，降低風險
• 為跨更多的組織提供更大的靈活性
• Intermedia CA需要通過root CA簽發證書之後才能使用
• Certificate Chain在root CA和一系列Intermedia CA之間信任

Fabric CA Client

Fabric CA Client參數：

7.2PKI

PKI（Public Key Infrastructure）：公鑰基礎結構。由向各方（如服務的使用者，服務提供商）釋出數字證書的證書頒發機構組成，然後他們使用它們在與其環境交換的消息中對自己進行身份驗證。

• Digital Certificates：數字證書，包含與證書持有者相關的一組屬性的文檔
• Public and Private keys：公鑰和私鑰
• Certificate Authorities： 證書頒發機構，證書頒發機構向不同的參與者分發證書，這些證書由CA進行數字簽名。CA是為組織的參與者提供可驗證的數字身份的基礎
• Certificate Revocation List： 證書撤銷清單，某種原因而被撤銷的證書的引用清單

7.3MSP

八、Fabric network

• Configure & Start Ordering Service

首先啟動Ordering Service

$ docker-compose [-f orderer.yml] ...
           

• Configure & Start Peer Nodes

Ordering Service啟動之後，需要配置各個節點。定義好聯盟鍊中有哪些組織，每個組織有多少個節點，其中多少個背書節點，多少個記賬節點（通常會把背書和記賬放在一個節點上）

$ peer node start ...
           

• Install Chaincode

在每個背書節點上安裝chaincode

$ peer chaincode install ...
           

• Create Channels

根據業務需求，來建立不同的channe

$ peer channel create –o [orderer] ...
           

• Join Channels

判定哪些peer加入哪些channel

$ peer channel join ...
           

• Instantiate Chaincode

對chaincode進行執行個體化，同時指定背書政策

$ peer chaincode instantiate ... –P ‘policy’
           

包含多個組織、通道的網絡示例：

示例中包含：

4個organization，每個organization都有自己的CA

org4提供orderer節點，其他org提供peer節點

channel1包含peer1、peer2、orderer4節點，安裝的chaincode是cc1，安裝的Smart Contract是s5，維護的賬本是L1

channel2包含peer2、peer3、orderer4節點，安裝的chaincode是cc2，安裝的Smart Contract是s6，維護的賬本是L2

peer2節點安裝了兩個不同的chaincode，維護兩套不同的賬本

A是用戶端，其中A1和A2都可以通路channel1，A2和A3都可以通路channel2