HyperLeger Fabric開發(fā)（六）——HyperLeger Fabric智能合約（鏈碼）

HyperLeger Fabric開發(fā)（六）——HyperLeger Fabric智能合約（ChainCode）

一、鏈碼（Chaincode）簡介

1、鏈碼簡介

在Fabric中，智能合約也稱為鏈碼（chaincode），分為用戶鏈碼和系統(tǒng)鏈碼。系統(tǒng)鏈碼用來實現(xiàn)系統(tǒng)層面的功能，包括系統(tǒng)的配置，用戶鏈碼的部署、升級，用戶交易的簽名和驗證策略等；用戶鏈碼用于實現(xiàn)用戶的應(yīng)用功能，開發(fā)者編寫鏈碼應(yīng)用程序并將其部署到區(qū)塊鏈網(wǎng)絡(luò)上，終端用戶通過與網(wǎng)絡(luò)節(jié)點交互的客戶端應(yīng)用程序調(diào)用鏈碼。
鏈碼被編譯成一個獨立的應(yīng)用程序，運行于隔離的Docker容器中，在鏈碼部署的時候會自動生成鏈碼的Docker鏡像。
鏈碼是訪問賬本的基本方法，一般是用Go等高級語言編寫的、實現(xiàn)規(guī)定接口的代碼。上層應(yīng)用可以通過調(diào)用鏈碼來初始化和管理賬本的狀態(tài)。只要有適當?shù)臋?quán)限，鏈碼之間也可以互相調(diào)用。
鏈碼（Chaincode）是一段由Go語言編寫（支持其它編程語言，如Java，NodeJS）并能實現(xiàn)預(yù)定義接口的程序。鏈碼運行在一個受保護的Docker容器當中，與背書節(jié)點的運行互相隔離。鏈碼可通過客戶端提交的交易對賬本狀態(tài)初始化并進行管理。
鏈碼通常處理由網(wǎng)絡(luò)中的成員一致認可的業(yè)務(wù)邏輯。鏈碼創(chuàng)建的（賬本）狀態(tài)是與其它鏈碼互相隔離的，因而不能被其它鏈碼直接訪問。如果在相同的Fabric網(wǎng)絡(luò)中，鏈碼在獲取相應(yīng)許可后可以調(diào)用其它鏈碼來訪問它的賬本。
鏈碼被部署在Fabric網(wǎng)絡(luò)節(jié)點上，運行在Docker容器中，并通過gRPC協(xié)議與相應(yīng)的Peer節(jié)點進行交互，以操作分布式賬本中的數(shù)據(jù)。

2、鏈碼的背書策略

背書策略是背書節(jié)點如何決策交易是否合法的條件。鏈碼實例化時可指定背書策略，當記賬節(jié)點接收到交易時，會獲知相關(guān)鏈碼信息，然后檢查鏈碼的背書策略，判斷交易是否滿足背書策略，若滿足則標注交易為合法。
背書策略可分為主體Principal(P)和閾值Threshold(T)兩部分，具體如下：
A、Principal指定由哪些成員進行背書。
B、Threshold接受兩個輸入，分別為閾值T和若干個P的集合n，只要交易中包含了n中t個成員的背書則認為交易合法。
背書策略可以指定某幾個組織內(nèi)的任意成員身份進行背書，或者要求至少有一個管理員身份進行背書等等。
T(1, ‘A’, ‘B’) 則需要A，B中任意成員背書。
T(1, ‘A’, T(2, ‘B’, ‘C’))則需要A成員背書或B，C成員同時背書。
目前客戶端已經(jīng)實現(xiàn)對背書策略的支持，可以通過-P來指定背書策略，結(jié)合AND、OR來組合成員，完成成員身份（admin、member）的集合。
-P OR ( 'Org1.admin' , AND ('Org2.member' , 'Org3.member') )
上述背書策略指定要么Org1的admin進行背書，或者Org2和Org3的成員同時進行背書，才滿足背書策略。

3、系統(tǒng)鏈碼

系統(tǒng)鏈碼與用戶鏈碼有相同的編程模型，但系統(tǒng)鏈碼運行在Peer節(jié)點，用戶鏈碼則在隔離的容器中運行。因此，系統(tǒng)鏈碼內(nèi)置為Peer節(jié)點的可執(zhí)行文件中，不遵循用戶鏈碼的生命周期，安裝、實例化、升級不適用于系統(tǒng)鏈碼。
系統(tǒng)鏈碼用于減少Peer節(jié)點與用戶鏈碼進行g(shù)RPC通信的開銷，同時權(quán)衡管理的靈活性。系統(tǒng)鏈碼只能通過Peer節(jié)點的二進制文件升級，必須通過一組固定的參數(shù)進行注冊，但不具有背書策略。
?Hyperledger Fabric系統(tǒng)鏈碼實現(xiàn)了一系列系統(tǒng)功能，以便系統(tǒng)集成人員能夠根據(jù)需求對其進行修改與替換。
常見系統(tǒng)鏈碼如下：
生命周期系統(tǒng)鏈碼（LSCC?）：處理生命周期管理。
配置系統(tǒng)鏈碼（CSCC）：處理在Peer節(jié)點上的通道配置。
查詢系統(tǒng)鏈碼（QSCC）：提供賬本的查詢API，例如獲取區(qū)塊以及交易。
背書系統(tǒng)鏈碼（ESCC）：通過對交易提案響應(yīng)進行簽名來處理背書過程。
驗證系統(tǒng)鏈碼（VSCC）：處理交易驗證，包括檢查背書策略以及多進程并發(fā)控制。
在修改或者替換系統(tǒng)鏈碼（LSCC、ESCC、VSCC）時必須注意，因為系統(tǒng)鏈碼在主交易執(zhí)行的路徑中。VSCC在將區(qū)塊提交至賬本前，所有在通道的Peer節(jié)點會計算相同的驗證以避免賬本分歧（不確定性）。如果VSCC被改變或者替換，需要特別小心。

二、鏈碼功能

Peer節(jié)點主要功能是調(diào)用鏈碼執(zhí)行交易和記賬，其中交易執(zhí)行由背書節(jié)點的鏈碼負責(zé)，記賬功能由記賬節(jié)點負責(zé)。

鏈碼與Peer節(jié)點的交互過程如下：
A、鏈碼通過gRPC與Peer節(jié)點交互，當Peer節(jié)點收到客戶端的交易提案請求后，會發(fā)送一個鏈碼消息對象（包含交易提案信息、調(diào)用者信息）給對應(yīng)的鏈碼。
B、鏈碼調(diào)用Invoke方法，通過發(fā)送獲取數(shù)據(jù)（GetState）和寫入數(shù)據(jù)（PutState）消息，向Peer節(jié)點獲取賬本狀態(tài)信息和發(fā)送預(yù)提交狀態(tài)。
C、鏈碼發(fā)送模擬執(zhí)行結(jié)果給Peer節(jié)點，Peer節(jié)點對交易提案和模擬執(zhí)行結(jié)果進行背書簽名。

三、鏈碼管理

1、鏈碼生命周期

Fabric提供了 package，install，instantiate和upgrade 4個命令管理鏈碼生命周期。

通過install安裝鏈碼，通過instantiate實例化鏈碼，然后可以通過invoke、query調(diào)用鏈碼和查詢鏈碼。
如果需要升級鏈碼，則需要先install安裝新版本的鏈碼，通過upgrade升級鏈碼。
在install安裝鏈碼前，可以通過package打包并簽名生成打包文件，然后在通過install安裝。
鏈碼在成功install以及instantiate后，鏈碼處于運行狀態(tài)，能夠通過Invoke方法來處理交易，后續(xù)能夠?qū)︽湸a進行升級。
Hyperledger Fabric API允許與區(qū)塊鏈網(wǎng)絡(luò)中的各個節(jié)點（Peer，Order，MSP）進行交互，同時也允許在背書節(jié)點上package、install、instantiate以及upgrade鏈碼。CLI可以直接訪問Hyperledger Fabric API。
Hyperledger Fabric SDK抽象了Hyperledger Fabric API的細節(jié)，以輔助應(yīng)用程序開發(fā)，當然也能用于管理鏈碼生命周期。

2、打包鏈碼

鏈碼包由三個部分組成：
A、由ChaincodeDeploymentSpec（CDS）格式定義的鏈碼。CDS根據(jù)代碼及其它屬性（如名稱與版本）定義鏈碼包；
B、一個可選的實例化策略，能夠被用作背書的策略進行描述；
C、擁有鏈碼的實體的一組簽名。
其中，鏈碼的簽名主要目的如下：
A、建立鏈碼的所有權(quán)；
B、允許驗證鏈碼包中的內(nèi)容；
C、允許檢測鏈碼包是否被篡改。
通道上的鏈碼的實例化交易的創(chuàng)建者能夠被鏈碼的實例化策略驗證。
鏈碼打包的方法由兩種，一種是打包被多個所有者所擁有的鏈碼，需要初始化創(chuàng)建一個被簽名的鏈碼包（SignedCDS），然后將其按順序的傳遞給其它所有者進行簽名；一種是打包單個所有者持有的鏈碼。
創(chuàng)建一個被簽名的鏈碼包的命令如下：
peer chaincode package -n sacc -p chaincodedev/chaincode/sacc -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out
-s選項創(chuàng)建一個能被多個所有者簽名的鏈碼包，而不是簡單的創(chuàng)建一個原始的CDS。一旦-s被指定，如果其它所有者想要簽名CDS，則-S選項必須被指定。否則，將會創(chuàng)建一個SignedCDS，除CDS外僅僅包括實例化策略。
-S選項使用被在core.yaml文件中定義的localMspid屬性的值標識的MSP對鏈碼包進行簽名。
-S選項是可選的。如果創(chuàng)建了一個沒有簽名的鏈碼包，不能被其它所有者使用signpackage命令進行簽名。
-i選項是可選的，允許為鏈碼指定實例化策略。實例化策略與背書策略有相同的格式，指定哪些身份能夠?qū)嵗湸a。本例中僅OrgA的admin能夠?qū)嵗湸a。如果沒有實例化策略被指定，將會使用默認的策略，僅允許擁有Peer的MSP的管理員身份實例化鏈碼。

3、簽名鏈碼

在創(chuàng)建階段就被簽名的鏈碼包能夠交給其它所有者進行檢查與簽名，支持帶外對鏈碼進行簽名。
?ChaincodeDeploymentSpec可以選擇由所有者集合進行簽名，從而創(chuàng)建一個SignedChaincodeDeploymentSpec(SignedCDS)。SignedCDS包括3個部分：
A、CDS包括源代碼，鏈碼的名稱與版本號；
B、鏈碼的實例化策略，表示為背書策略；
C、鏈碼所有者的列表，由背書策略定義。
當在某些通道上實例化鏈碼時，背書策略是在帶外確定的，用于提供合適的MSP主體。如果沒指定實例化策略，則默認的策略就是通道的任何MSP管理員。
每一個鏈碼的所有者通過將SignedCDS與鏈碼所有者的身份（例如證書）組合并簽署組合結(jié)果來背書ChaincodeDeploymentSpec。
一個鏈碼的所有者能夠?qū)ψ约核鶆?chuàng)建的簽名過的鏈碼包進行簽名，需要使用如下命令：
peer chaincode signpackage ccpack.out signedccpack.out
ccpack.out、signedccpack.out分別是輸入與輸出包。signedccpack.out包括一個對鏈碼包附加的簽名（通過local msp進行的簽名）。

4、安裝鏈碼

安裝交易將鏈碼的源代碼打包成ChaincodeDeploymentSpec（CDS）的規(guī)定的格式，然后安裝到通道中的背書節(jié)點上。
當安裝的鏈碼包只包含一個ChaincodeDeploymentSpec時，將使用默認初始化策略并包括一個空的所有者列表。
鏈碼應(yīng)該僅僅被安裝在鏈碼所有者成員的背書節(jié)點上，用于實現(xiàn)鏈碼對于網(wǎng)絡(luò)中其它成員在邏輯上是隔離的。沒有鏈碼的Peer節(jié)點，不能成為鏈碼交易的背書者，不能執(zhí)行鏈碼，但作為記賬節(jié)點仍然能夠驗證與提交交易到賬本上。
安裝鏈碼會發(fā)送一個SignedProposal到生命周期系統(tǒng)鏈碼(LSCC) 。
使用CLI安裝sacc鏈碼的命令如下：
peer chaincode install -n sacc -v 1.0 -p sacc
-n選項指定鏈碼實例名稱
-v選項指定鏈碼的版本
-p選項指定鏈碼所在路徑，必須在GOPATH路徑下
CLI內(nèi)部創(chuàng)建sacc的SignedChaincodeDeploymentSpec，然后將其發(fā)送給本地Peer節(jié)點，Peer節(jié)點會調(diào)用LSCC上的安裝方法。為了在Peer節(jié)點上安裝鏈碼，SignedProposal的簽名必須來自于Peer節(jié)點的本地MSP管理員之一。

5、實例化鏈碼

實例化調(diào)用生命周期系統(tǒng)鏈碼(LSCC)用于創(chuàng)建及初始化通道上的鏈碼。鏈碼能夠被綁定到任意數(shù)量的通道，以及在每個通道上單獨的操作。無論鏈碼安裝及實例化到多少個通道上，每個通道的狀態(tài)都是隔離的。
實例化的創(chuàng)建者必須滿足包含在SignedCDS內(nèi)鏈碼的實例化策略，而且還必須是通道的寫入器（作為通道創(chuàng)建的一部分被配置）?？梢苑乐共渴疰湸a的流氓實體或者欺騙者在未被綁定的通道上執(zhí)行鏈碼。
默認的實例化策略是任意的通道MSP的管理員，因此鏈碼實例化交易的創(chuàng)建者必須是通道管理員之一。當交易提案到達背書節(jié)點后，背書節(jié)點會根據(jù)實例化策略驗證創(chuàng)建者的簽名。在提交實例化交易到賬本前，在交易驗證時再一次完成該操作。
實例化交易同樣設(shè)置了通道上的鏈碼的背書策略 。背書策略描述了交易被通道上成員接受的認證要求。
使用CLI去實例化sacc的鏈碼并初始化狀態(tài)為user1與0，命令如下：
peer chaincode instantiate -n sacc -v 1.0 -c '{"Args":["user1","0"]}' -P "OR ('Org1.member','Org2.member')"
-n選項指定鏈碼實例名稱
-v選項指定鏈碼的版本
-c 選項指定鏈碼的調(diào)用參數(shù)
-P選項指定鏈碼的背書策略
背書策略表示，org1.member或者org2.member必須對調(diào)用使用sacc的交易進行簽名，以保障交易是有效的。在成功實例化后，通道的鏈碼進入激活狀態(tài)，可以處理任意的交易提案。交易到達背書節(jié)點時，會同時被處理。

6、調(diào)用鏈碼

調(diào)用鏈碼：
peer chaincode invoke -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C mychannel -n sacc -c '{"Args":["invoke","user1","user2","10"]}'
查詢鏈碼
peer chaincode query -C mychannel -n sacc -c '{"Args":["query","user1"]}'

7、升級鏈碼

鏈碼的升級通過改變其版本號（作為SignedCDS的一部分）。SignedCDS另外的部分，如所有者及實例化策略都是可選的。然而，鏈碼的名稱必須是一致的，否則會被當做另外一個新的鏈碼。
在升級前，必須將新版本的鏈碼安裝到有需求的背書節(jié)點上。升級也是一種交易，會把新版本的鏈碼綁定到通道中。升級只能在一個時間點對一個通道產(chǎn)生影響，其它通道仍然運行舊版本的鏈碼。
由于可能存在多個版本的鏈碼同時存在，升級過程不會自動刪除老版本倆馬，用戶必須手動操作刪除過程。
升級與實例化transaction有一點不同的是：通過現(xiàn)有的chaincode實例化策略檢查升級transaction，而不是用新的策略檢查。這是為了確保只有當前實例化策略中指定的成員能夠升級chaincode。
在升級期間，鏈碼的Init函數(shù)也會被調(diào)用，執(zhí)行有關(guān)升級的數(shù)據(jù)或者使用數(shù)據(jù)重新進行初始化，在升級鏈碼的期間避免對狀態(tài)進行重置。
安裝新版本的鏈碼
peer chaincode install -n sacc -v 1 -p path/to/my/chaincode/v1
upgrade升級鏈碼
peer chaincode upgrade -n sacc -v 1 -c '{"Args":["d", "e", "f"]}' -C mychannel