五、Peer

5.1Fabric Peer

特點(diǎn)

聯(lián)盟鏈中，peer節(jié)點(diǎn)代表各個(gè)企業(yè)和組織。

區(qū)塊鏈網(wǎng)絡(luò)主要是由一系列peer節(jié)點(diǎn)組成，peer節(jié)點(diǎn)是整個(gè)區(qū)塊鏈網(wǎng)絡(luò)的基礎(chǔ)，因?yàn)樗琴~本和智能合約的載體，通過智能合約，賬本以不可篡改的方式記錄了交易的全過程；

• 每個(gè)節(jié)點(diǎn)可以加入一個(gè)或多個(gè)channel；
• 每個(gè)channel維護(hù)自己的一個(gè)或多個(gè)賬本，賬本之間是隔離的；
• 每個(gè)peer可以安裝不同的智能合約；
• 交易完成后，peer會(huì)發(fā)送event事件給client端；
• 每個(gè)channel都有l(wèi)ocal MSP，提供身份認(rèn)證。

種類

Committing Peer

• 維護(hù)賬本和狀態(tài)
• 驗(yàn)證和提交交易

Endorsing Peer

• 為接收到的交易進(jìn)行背書，并給客戶端響應(yīng)
• 持有智能合約

背書策略

每個(gè)鏈碼在部署的時(shí)候都會(huì)指定背書策略；

在背書節(jié)點(diǎn)中，當(dāng)模擬執(zhí)行完結(jié)果以后，會(huì)通過ESCC (Endorsement System ChainCode)對執(zhí)行結(jié)果進(jìn)行簽名；

在記賬節(jié)點(diǎn)中，會(huì)通過VSCC (Validation System ChainCode) 根據(jù)背書策略驗(yàn)證交易是否正確。

背書策略是在實(shí)例化鏈碼時(shí)指定，如圖就是指：在mychannel上實(shí)例化鏈碼mycc，并指定背書策略為AND(‘Org1MSP.member’) ，就是說只要org1中的成員簽名，就認(rèn)為交易是合理的。

5.2Fabric Ledger and State DB

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

區(qū)塊：維護(hù)channel的配置信息、歷史交易記錄

世界狀態(tài)：維護(hù)賬本當(dāng)前狀態(tài)，方便進(jìn)行快速查詢

區(qū)塊

分為三個(gè)部分：

• 區(qū)塊頭
  • 區(qū)塊編號(hào)
  • 當(dāng)前區(qū)塊hash
  • 前一區(qū)塊hash
• 區(qū)塊數(shù)據(jù)
  • 交易數(shù)據(jù)
    • 頭部：包含鏈碼名字、version等信息
    • 簽名：Client端用戶的簽名，誰發(fā)起的請求就是誰的簽名
    • 交易：用戶端給背書節(jié)點(diǎn)的proposal，主要是input參數(shù)
    • 響應(yīng)：智能合約執(zhí)行的結(jié)果，執(zhí)行前的數(shù)據(jù)和執(zhí)行后的數(shù)據(jù)
    • 背書：每個(gè)背書節(jié)點(diǎn)返回的結(jié)果，是個(gè)list
• 區(qū)塊元數(shù)據(jù)
  • 區(qū)塊寫入時(shí)間
  • 區(qū)塊寫入人
  • 簽名

狀態(tài)

維護(hù)賬本的當(dāng)前信息，k-v形式，如{key=balance，value=100} version=1。

賬本樣例：

5.3Smart Contract

Smart Contract & chaincode

• Smart Contract
  • 區(qū)塊鏈的核心
  • 定義不同組織之間的業(yè)務(wù)規(guī)則或規(guī)范
  • 產(chǎn)生交易transaction記錄在賬本ledger中
  • 打包到鏈碼Chaincode中，一個(gè)Chaincode可以包含多個(gè)智能合約Smart Contract
• Chaincode
  • 可以打包多個(gè)智能合約Smart Contract
  • 鏈碼Chaincode部署之后，智能合約Smart Contract就可以給用戶端使用

smart contract interact with the ledger

• 智能合約由開發(fā)人員根據(jù)業(yè)務(wù)邏輯進(jìn)行開發(fā)，同時(shí)還會(huì)開發(fā)Client端
• 當(dāng)客戶端發(fā)送請求時(shí)，可以通過智能合約調(diào)用API去操作World state。get操作直接返回?cái)?shù)據(jù)，不會(huì)在區(qū)塊鏈中增加新的交易；put、delete在修改World state同時(shí)還會(huì)在區(qū)塊鏈上增加新的交易記錄，增加新的區(qū)塊；qi中delete只會(huì)刪除World state中的數(shù)據(jù)，不會(huì)刪除區(qū)塊中的賬本數(shù)據(jù)，會(huì)增加新的記錄
• Blockchain提供API可以讓客戶端去訪問
• 交易完成時(shí)通過智能合約發(fā)送event事件給用戶端

Chaincode Lifecycle

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

Package

• 生成ChaincodeDeploymentSpec (CDS)，包括源代碼、名字和鏈碼版本號(hào)
• 指定初始化策略，即由誰來進(jìn)行初始化，表達(dá)式與背書策略相同
• 由擁有chaincode的實(shí)體進(jìn)行簽名

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

Install

• 安裝在peer節(jié)點(diǎn)上
• 一個(gè)peer節(jié)點(diǎn)可以安裝多個(gè)不同的chaincode
• 必須安裝在channel所有的背書節(jié)點(diǎn)上

peer chaincode install ccpack.out

Instantiate

• 在通道上實(shí)例化一個(gè)chaincode
• 實(shí)例化期間設(shè)置背書策略

peer chaincode instantiate -n mycc -v 1.0 -c '{"Args":[“a”,“100”, “b”, “200”]}' -P "AND ('Org1.member','Org2.member')"

Running

• Client端可以發(fā)送交易請求
• 智能合約處理交易、更新賬本、返回響應(yīng)
• Client端接收響應(yīng)

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

• 可隨時(shí)更新升級(jí)
• 更新之前，最新版本的chaincode必須已經(jīng)安裝在所有的背書節(jié)點(diǎn)上
• 和實(shí)例化類似，每次只能影響一個(gè)channel

peer chaincode upgrade -C mychannel -n mycc -v 1.0 -c '{"Args":["a","100","b","200"]}'

System Chaincode

在Fabric系統(tǒng)中有一些System Chaincode，它運(yùn)行在peer進(jìn)程上，而不是像我們開發(fā)的合約運(yùn)行在一個(gè)單獨(dú)的容器中。它實(shí)現(xiàn)了一些系統(tǒng)的行為。

5.4Gossip Protocol

功能

• 維護(hù)管理channel中的peer成員以及peer節(jié)點(diǎn)的發(fā)現(xiàn)
• 不斷傳播賬本數(shù)據(jù)給channel中的所有節(jié)點(diǎn)
• 對新加入的peer，通過點(diǎn)對點(diǎn)(peer-to-peer)的狀態(tài)傳播來更新賬本數(shù)據(jù)

數(shù)據(jù)傳輸

• 線上的peer節(jié)點(diǎn)通過不斷向周圍廣播存活消息來證明它們的可用性
• peer通過收集他們的存活信息維護(hù)channel成員
• 當(dāng)leader節(jié)點(diǎn)從order服務(wù)拿到交易信息后，會(huì)傳播給其他節(jié)點(diǎn)。當(dāng)一個(gè)peer收到消息后，還會(huì)散發(fā)給其他peer
• 每個(gè)peer會(huì)不斷詢問周圍的peer兩者的狀態(tài)是否匹配，如果不匹配就會(huì)從其他節(jié)點(diǎn)拉取最新的區(qū)塊，通過P2P的方式使賬本信息保持一致
• 一個(gè)channel上的peer節(jié)點(diǎn)不能傳播數(shù)據(jù)給其他channel

Leader Peer & Anchor Peer

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

• Leader Peer

  • 與orderer節(jié)點(diǎn)聯(lián)系并拉取新的區(qū)塊

  • 把交易傳播給組織中其他記賬節(jié)點(diǎn)，其他記賬節(jié)點(diǎn)收到消息后還會(huì)繼續(xù)散播

  • 在一個(gè)組織中允許存在一個(gè)或者多個(gè)Leader Peer

  • Leader Peer 選舉

    • 靜態(tài)Static

      • 系統(tǒng)管理員在配置的時(shí)候手動(dòng)進(jìn)行指定當(dāng)前節(jié)點(diǎn)成為leader peer
      peer: # Gossip related configuration gossip: useLeaderElection: false orgLeader: true

    • 動(dòng)態(tài)Dynamic

      • peer節(jié)點(diǎn)通過執(zhí)行l(wèi)eader選舉程序來選舉一個(gè)leader
      • 動(dòng)態(tài)選舉的leader節(jié)點(diǎn)會(huì)不斷發(fā)送心跳給其他peer節(jié)點(diǎn)證明其存活，leaderAliveThreshold指定間隔時(shí)間
      peer: # Gossip related configuration gossip: useLeaderElection: true orgLeader: false election: leaderAliveThreshold: 10s

• Anchor Peer

  • 使用Gossip協(xié)議，確保channel上不同組織的peer節(jié)點(diǎn)都是互相認(rèn)識(shí)的。
  • 比如OrgA中的peer節(jié)點(diǎn)想要傳播數(shù)據(jù)到OrgB中的peer節(jié)點(diǎn)，但是兩者之間不認(rèn)識(shí)，那么OrgA的節(jié)點(diǎn)就要先聯(lián)系OrgA的Anchor Peer，OrgA的Anchor Peer聯(lián)系OrgB的Anchor Peer，OrgB的Anchor Peer聯(lián)系OrgB的節(jié)點(diǎn)，然后就可以相互通信，之后就可以直接聯(lián)系。

5.5Private Data

• 隱私數(shù)據(jù)存儲(chǔ)在每個(gè)授權(quán)的peer節(jié)點(diǎn)（authorized peer）上的隱私數(shù)據(jù)庫（private database）中
• 隱私數(shù)據(jù)集合策略（Private data collection policy ）會(huì)定義授權(quán)的peer節(jié)點(diǎn)
• 排序服務(wù)（Ordering service）不能看到隱私數(shù)據(jù)
• 隱私數(shù)據(jù)的傳播是通過Gossip協(xié)議

Tx flow with private data

隱私數(shù)據(jù)在交易流程中的傳遞：

• 用戶端提交的請求中包括隱私數(shù)據(jù)

• 背書節(jié)點(diǎn)模擬執(zhí)行交易時(shí)，會(huì)存儲(chǔ)隱私數(shù)據(jù)在一個(gè)臨時(shí)數(shù)據(jù)庫中，同時(shí)向其他有權(quán)限的peer節(jié)點(diǎn)傳播

• 背書節(jié)點(diǎn)返回背書結(jié)果給用戶端時(shí)，不會(huì)返回隱私數(shù)據(jù)，只有隱私數(shù)據(jù)k-v的hash值

• 記賬節(jié)點(diǎn)驗(yàn)證時(shí)，會(huì)驗(yàn)證隱私數(shù)據(jù)的hash值，并和臨時(shí)數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行比較，看是否有被修改

• 驗(yàn)證通過，記賬節(jié)點(diǎn)會(huì)把隱私數(shù)據(jù)從臨時(shí)數(shù)據(jù)庫正式移到隱私數(shù)據(jù)庫中

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示例，包含兩個(gè)collection，分別是collectionMarbles、collectionMarblePrivateDetails。其中以collectionMarbles為例，policy指Org1MSP.member, Org2MSP.member可以訪問隱私數(shù)據(jù)；requiredPeerCount指背書節(jié)點(diǎn)返回執(zhí)行結(jié)果之前，為了保證私有數(shù)據(jù)已經(jīng)傳播給其他節(jié)點(diǎn)，必須傳播給幾個(gè)peer節(jié)點(diǎn)；maxPeerCount指最多傳播給幾個(gè)節(jié)點(diǎn)；blockToLive指隱私數(shù)據(jù)在在DB中保存多久，超過時(shí)間自動(dòng)銷毀。

六、Orderer

6.1Atomic Broadcast(Total Order)

Orderer節(jié)點(diǎn)在流程中的作用：Orderer作為一個(gè)集群服務(wù)，會(huì)從各個(gè)Orderer節(jié)點(diǎn)接收transaction，并且把接收到的所有的transaction進(jìn)行全排序，并根據(jù)一定的規(guī)則打包成區(qū)塊。

Fabric作為聯(lián)盟鏈，并不是所有的人都可以出塊，都可以參與排序過程，Orderer是由允許的幾個(gè)組織來進(jìn)行排序工作。

• Identical：產(chǎn)生完全相同的塊，最終每一個(gè)Orderer產(chǎn)生的塊都必須一致；
• Crash：CFT，當(dāng)集群中的節(jié)點(diǎn)掛掉了，剩下的節(jié)點(diǎn)依然可以完成排序功能，明確最多容錯(cuò)幾個(gè)節(jié)點(diǎn)；
• Partition：當(dāng)網(wǎng)絡(luò)隔離之后，隔離的節(jié)點(diǎn)應(yīng)該有拒絕寫或者拒絕讀等措施；
• Strong Consistency：不同于某些公有鏈的最終一致性（比如比特幣的最長合法鏈，6個(gè)節(jié)點(diǎn)確認(rèn)機(jī)制等），Fabric中需要有強(qiáng)一致性，不能有臨時(shí)分叉，當(dāng)一筆交易提交之后，是絕對不能被覆寫的；
• BFT：拜占庭容錯(cuò)，即允許作惡節(jié)點(diǎn)存在。Orderer本身不是拜占庭容錯(cuò)，而是CFT容錯(cuò)（無論是Kafka還是Raft）。但是即使Orderer節(jié)點(diǎn)是CFT，并不代表這個(gè)Fabric是CFT，Fabric依然是BFT，因?yàn)镕abric中還有peer的背書和驗(yàn)證環(huán)節(jié)。由于Orderer節(jié)點(diǎn)是CFT容錯(cuò)，所以有些攻擊無法防范，比如惡意節(jié)點(diǎn)運(yùn)行Orderer，會(huì)使得Orderer網(wǎng)絡(luò)本身拒絕出塊，這樣用戶提交的交易可能無法寫入到賬本中，但是這種攻擊是可探查的，而且不會(huì)造成數(shù)據(jù)的丟失和篡改，即可作惡的嚴(yán)重程度是有限的。

6.2Block Cutting

如果交易已經(jīng)排序完成，之后需要對其生成區(qū)塊，那么生成區(qū)塊的規(guī)則有以下幾種：

• BatchSize

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

  規(guī)則就是，當(dāng)交易大小的總和達(dá)到了PreferredMaxBytes，或者交易個(gè)數(shù)達(dá)到了MaxMessageCount，就會(huì)打包一個(gè)區(qū)塊。

  但是要注意的是，塊的大小不可能永遠(yuǎn)小于PreferredMaxBytes，比如PreferredMaxBytes是800，前9個(gè)交易大小是700，第10個(gè)交易就是200，那么加一起大于800，這種情況下第10個(gè)交易也會(huì)隨著前9個(gè)一起打包到區(qū)塊中。

  AbsoluteMaxBytes相當(dāng)于限制了單個(gè)交易transaction的大小，超過這個(gè)的交易會(huì)被拒絕。

• BatchTimeout

  • Timeout：即使區(qū)塊沒有足夠的交易，在一定時(shí)間后也會(huì)把已有的交易打包到塊中

6.3Channel

Fabric中有System Channel，是系統(tǒng)默認(rèn)的channel，作用就是管理用戶的channel。

Orderer啟動(dòng)需要有Genises Block，該區(qū)塊規(guī)定了所有關(guān)于System Channel的配置，那么所有的Orderer都必須用同樣的Genises Block來啟動(dòng)。啟動(dòng)之后系統(tǒng)會(huì)默認(rèn)存在一個(gè)System Channel，當(dāng)創(chuàng)建一個(gè)用戶channel的時(shí)候，其實(shí)是向System Channel發(fā)送了一個(gè)創(chuàng)建的交易transaction，交易中包括channel名字，配置信息，包括哪幾個(gè)組織等屬性。System Channel拿到交易后，發(fā)現(xiàn)是創(chuàng)建channel的請求，就會(huì)創(chuàng)建一個(gè)channel，并把交易中包括的新channel的配置信息，作為用戶channel的Genises Block放在系統(tǒng)中，這樣一個(gè)channel就創(chuàng)建完成。

當(dāng)要修改channel的配置時(shí)，就是向channel發(fā)送一個(gè)配置的交易，配置交易是不遵循出塊規(guī)則的，永遠(yuǎn)是自己一個(gè)塊，因?yàn)榕渲眯畔⑿枰M快生效，那么當(dāng)去修改一個(gè)channel的屬性時(shí)，也是需要共識(shí)的，共識(shí)之后提交到orderer的賬本中，完成屬性更新。

6.4Consensus

Solo

Kafka

Raft

七、MSP_CA

7.1CA

CA 是 Hyperledger Fabric 的證書頒發(fā)機(jī)構(gòu)（CA），是Hyperledger Fabric內(nèi)一個(gè)可選的 MemberService 組件，對網(wǎng)絡(luò)內(nèi)各個(gè)實(shí)體的身份證書進(jìn)行管理，主要實(shí)現(xiàn)：

• 負(fù)責(zé) Fabric 網(wǎng)絡(luò)內(nèi)所有實(shí)體（Identity）身份的注冊。
• 負(fù)責(zé)對數(shù)字證書的簽發(fā)，包括 ECerts（身份證書）、TCerts（交易證書）。
• 證書的續(xù)簽或吊銷。

Fabric CA 在Fabric網(wǎng)絡(luò)中的作用：

訪問 Fabric CA 服務(wù)器可以通過 Hyperledger Fabric CA 客戶端或通過其中一個(gè) Fabric SDK 來實(shí)現(xiàn)，與 Hyperledger Fabric CA 服務(wù)器的所有通信都是通過API 進(jìn)行。

Hyperledger Fabric CA 客戶端或 SDK 可以連接到 Hyperledger Fabric CA 服務(wù)器集群，集群由 HA Proxy 等實(shí)現(xiàn)負(fù)載均衡。服務(wù)器可能包含多個(gè)CA，每個(gè)CA都是根CA或中間CA，每個(gè)中間CA都有一個(gè)父CA。

Hyperledger Fabric CA 的身份信息保存在數(shù)據(jù)庫或LDAP中。目前 Fabric CA 支持的數(shù)據(jù)庫有 MySQL、PostgreSQL、SQLite；默認(rèn)使用 SQLite 數(shù)據(jù)庫。如果配置了 LDAP，則身份信息將保留在 LDAP 而不是數(shù)據(jù)庫中。

Fabric CA Server

配置設(shè)置：

• 命令行
• 環(huán)境變量
• 配置文件

Fabric CA Server 參數(shù)：

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

初始化：

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

• ca-cert.pem
• ca-chain.pem
• tls-cert.pem
• fabric-ca-server.db：數(shù)據(jù)庫
• fabric-ca-server-config.yaml：默認(rèn)配置文件
• IssuerPublicKey
• IssuerRevocati
• onPublicKey
• MSP

Intermedia CA：

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

Fabric CA Client

Fabric CA Client參數(shù)：

7.2PKI

PKI（Public Key Infrastructure）：公鑰基礎(chǔ)結(jié)構(gòu)。由向各方（如服務(wù)的用戶，服務(wù)提供商）發(fā)布數(shù)字證書的證書頒發(fā)機(jī)構(gòu)組成，然后他們使用它們在與其環(huán)境交換的消息中對自己進(jìn)行身份驗(yàn)證。

• Digital Certificates：數(shù)字證書，包含與證書持有者相關(guān)的一組屬性的文檔
• Public and Private keys：公鑰和私鑰
• Certificate Authorities： 證書頒發(fā)機(jī)構(gòu)，證書頒發(fā)機(jī)構(gòu)向不同的參與者分發(fā)證書，這些證書由CA進(jìn)行數(shù)字簽名。CA是為組織的參與者提供可驗(yàn)證的數(shù)字身份的基礎(chǔ)
• Certificate Revocation List： 證書撤銷列表，某種原因而被撤銷的證書的引用列表

7.3MSP

八、Fabric network

• Configure & Start Ordering Service

首先啟動(dòng)Ordering Service

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

• Configure & Start Peer Nodes

Ordering Service啟動(dòng)之后，需要配置各個(gè)節(jié)點(diǎn)。定義好聯(lián)盟鏈中有哪些組織，每個(gè)組織有多少個(gè)節(jié)點(diǎn)，其中多少個(gè)背書節(jié)點(diǎn)，多少個(gè)記賬節(jié)點(diǎn)（通常會(huì)把背書和記賬放在一個(gè)節(jié)點(diǎn)上）

$ peer node start ...

• Install Chaincode

在每個(gè)背書節(jié)點(diǎn)上安裝chaincode

$ peer chaincode install ...

• Create Channels

根據(jù)業(yè)務(wù)需求，來創(chuàng)建不同的channe

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

• Join Channels

判定哪些peer加入哪些channel

$ peer channel join ...

• Instantiate Chaincode

對chaincode進(jìn)行實(shí)例化，同時(shí)指定背書策略

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

包含多個(gè)組織、通道的網(wǎng)絡(luò)示例：

示例中包含：

4個(gè)organization，每個(gè)organization都有自己的CA

org4提供orderer節(jié)點(diǎn)，其他org提供peer節(jié)點(diǎn)

channel1包含peer1、peer2、orderer4節(jié)點(diǎn)，安裝的chaincode是cc1，安裝的Smart Contract是s5，維護(hù)的賬本是L1

channel2包含peer2、peer3、orderer4節(jié)點(diǎn)，安裝的chaincode是cc2，安裝的Smart Contract是s6，維護(hù)的賬本是L2

peer2節(jié)點(diǎn)安裝了兩個(gè)不同的chaincode，維護(hù)兩套不同的賬本

A是客戶端，其中A1和A2都可以訪問channel1，A2和A3都可以訪問channel2

總結(jié)

以上是生活随笔為你收集整理的Fabric-02Peer、Orderer以及CA的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。