概述

在 Hyperledger Fabric 中，鏈碼（Chaincode）又稱為智能合約（下文中我們統(tǒng)一稱為鏈碼），是用Go，node.js或Java編寫的程序，主要用于操作賬本上的數(shù)據(jù)。用戶的應用程序通過鏈碼與 Fabric 賬本數(shù)據(jù)進行交互。

一個完整的 Fabric 區(qū)塊鏈應用包含用戶的應用程序和用戶編寫的鏈碼兩部分。用戶的應用程序通過區(qū)塊鏈網(wǎng)絡中部署的 Peer 節(jié)點調用鏈碼，用戶鏈碼通過區(qū)塊鏈網(wǎng)絡的 Peer 節(jié)點來操作賬本數(shù)據(jù)。如下圖所示：

Fabric 中的 Peer 節(jié)點提供了調用鏈碼相關服務的接口。用戶的應用程序可以通過調用相關接口和 Fabric Peer 進行交互， Peer 節(jié)點通過與鏈碼容器進行交互，完成應用程序和鏈碼之間的交互。

用戶的應用程序可以通過以下兩種方式與 Fabric Peer 進行交互：

• 利用 Fabric 提供的 SDK 與 Fabric Peer 進行交互，具體參看 Fabric SDK。

• 利用阿里云BaaS提供的 API 接口 與 Fabric Peer 進行交互。

生命周期

鏈碼開發(fā)編寫完成后，并不能直接使用，需要經(jīng)過一系列的操作之后才能應用在 Hyperledger Fabric 網(wǎng)絡中進而處理客戶端提交的交易。這一系列的操作是由鏈碼的生命周期來負責管理。

Fabric 1.x 中管理 Chaincode 的生命周期主要有如下幾個命令：

1. package： 對指定的鏈碼進行打包的操作。

2. install： 將已編寫完成的鏈碼安裝在網(wǎng)絡節(jié)點中。

3. instantiate： 對已安裝的鏈碼進行實例化。

4. upgrade： 對已有鏈碼進行升級。鏈代碼可以在安裝后根據(jù)具體需求的變化進行升級。

Fabric 2.x 中管理 Chaincode 的生周期主要有如下幾個命令：

1. package： 對指定的鏈碼進行打包的操作。

2. approveformyorg： 在網(wǎng)絡提議某個已編寫完成的鏈碼。

3. commit： 在網(wǎng)絡中正式提交已編寫完成的鏈碼，默認超過半數(shù)成員通過提議后才能生效。

鏈碼類型

在 Hyperledger Fabric 中，鏈碼一般分為：

• 系統(tǒng)鏈碼

• 用戶鏈碼

系統(tǒng)鏈碼

系統(tǒng)鏈碼負責 Fabric 節(jié)點自身的處理邏輯，包括系統(tǒng)配置、背書、校驗等工作。系統(tǒng)鏈碼僅支持 Go 語言，在 Peer 節(jié)點啟動時會自動完成注冊和部署，所以安裝，實例化和升級不適用于系統(tǒng)鏈碼。

系統(tǒng)鏈碼主要包括以下幾種：

• 生命周期系統(tǒng)鏈碼(LSCC)：Lifecycle System Chaincode，負責對用戶鏈碼的生命周期進行管理。

• 配置系統(tǒng)鏈碼(CSCC)：Configuration System Chaincode，負責處理 Peer 端的 Channel 配置。

• 查詢系統(tǒng)鏈碼(QSCC)：Query System Chaincode，提供賬本查詢 API，如獲取區(qū)塊和交易等信息。

用戶鏈碼

用戶鏈碼是由應用程序開發(fā)人員根據(jù)業(yè)務場景需求使用 Golang、node.js 或 Java 語言編寫的操作區(qū)塊鏈分布式賬本的狀態(tài)的業(yè)務處理邏輯代碼，用戶鏈碼運行在鏈碼容器中，通過 Fabric 提供的接口與賬本狀態(tài)進行交互。

用戶鏈碼在區(qū)塊鏈應用上處于非常關鍵的一環(huán)，它直接接受用戶業(yè)務邏輯的調用，并對區(qū)塊鏈分布式賬本數(shù)據(jù)進行操作。

背書策略

每個智能合約都有與之相關的背書策略。該背書策略可確定哪些組織必須批準智能合約生成的交易，然后才能將其確認為有效交易。在上傳鏈碼及實例化鏈碼時，需要為其指定對應的背書策略。

背書策略舉例：

• OR ('Org1MSP.peer','Org2MSP.peer') 表示此通道中的兩個組織任何一方背書即可；

• AND (‘Org1MSP.peer’,’Org2MSP.peer’) 表示需要此通道中的兩個組織背書。

更多參考：Fabric設計->背書策略

交易執(zhí)行流程

在 Hyperledger Fabric上，一筆交易的執(zhí)行需要 Peer節(jié)點、orderer節(jié)點、CA節(jié)點及client端共同參與。

• Peer節(jié)點：該節(jié)點是參與交易的主體，可以說是代表每個參與到鏈上的成員，它負責儲存完整的賬本數(shù)據(jù)即區(qū)塊鏈數(shù)據(jù)，負責共識環(huán)節(jié)中的執(zhí)行智能合約，驗證區(qū)塊和交易并將合法交易提交（commit）到賬本中。

• Orderer節(jié)點：該節(jié)點接受包含背書簽名的交易請求進行排序并打包生產(chǎn)新的區(qū)塊，主體功能便是對交易排序從而保證各Peer節(jié)點上的數(shù)據(jù)一致性。

• CA節(jié)點：該節(jié)點負責對加入鏈內(nèi)的所有節(jié)點進行授權認證，包括上層的client端，每一個節(jié)點都有其頒發(fā)的證書用于交易流程中的身份識別。

• client：Fabric對于client端提供了SDK讓開發(fā)人員可以更容易的對接到區(qū)塊鏈內(nèi)的交易環(huán)節(jié)，交易的發(fā)起便是通過SDK進行。

交易的執(zhí)行流程主要包含如下4大步驟：

1. 由client端發(fā)起一個交易請求，client會根據(jù)鏈碼的背書策略決定把該筆交易發(fā)往哪些背書的peer節(jié)點，由peer節(jié)點進行投票，client匯總各背書節(jié)點的結果。上圖中的背書策略要求Peer1、Peer2及Peer3參與交易，所以client將請求分別發(fā)給 Pee1、Peer2 和 Peer3。

2. 三個 Peer 節(jié)點接收到交易請求后執(zhí)行對應的鏈碼并對結果進行簽名然后分別將輸出結果返回給client。

3. client將收到所有的執(zhí)行結果后連同各peer的背書（包括其投票結果以及背書簽名）后打包發(fā)送給 Orderer節(jié)點。

4. Orderer 將接收到的該次交易在交易池里進行排序并組合打包生成一個新的區(qū)塊，并將新的區(qū)塊發(fā)送給所有的Peer節(jié)點，每個Peer節(jié)點接收到新區(qū)塊后，對其中的每一筆交易結果的簽名進行驗證是否符合背書策略，以及比對讀寫集合與本地的版本是否相同，如滿足所有條件則將新的區(qū)塊寫入本地賬本內(nèi)完成交易。

更多參考：Fabric設計->交易流程

注意事項

跨通道的鏈碼間調用

如果被調用鏈碼與調用鏈碼位于不同的通道，則僅允許讀取查詢。 也就是說，在另一個通道上的被調用鏈碼僅僅是一個查詢，它不參與后續(xù)提交階段的狀態(tài)驗證檢查。

相同通道下的鏈碼間調用

如果被調用鏈碼與調用鏈碼位于相同通道，則其被調用鏈碼生成的讀寫集會被加入調用鏈碼對應的交易，即共用同一筆交易而不會產(chǎn)生不同的交易。

鏈碼shim包依賴

鏈碼中需要依賴shim包（ChainCodeStub）來與Peer節(jié)點通信，部分語言shim包也提供了擴展接口（例如處理調用者身份）。在鏈碼實例化編譯時Peer節(jié)點默認提供了與節(jié)點版本一致的shim包，如果您的鏈碼依賴其他兼容版本（v1.4.x）的shim包，請一并打包在鏈碼文件中。

• 2020年4月29日之前創(chuàng)建的節(jié)點版本為v1.4.2，之后創(chuàng)建的節(jié)點版本為v1.4.5

• Golang 依賴：

  • 老版本：github.com/hyperledger/fabric/core/chaincode/shim、github.com/hyperledger/fabric/protos/peer

  • 新版本：github.com/hyperledger/fabric-chaincode-go/shim、github.com/hyperledger/fabric-protos-go/peer

• Java 依賴：fabric-chaincode-shim-1.4.x.jar、fabric-chaincode-protos-1.4.x.jar