HyperLeger Fabric開發（六）——HyperLeger Fabric智能合約（鏈碼）

HyperLeger Fabric開發（六）——HyperLeger Fabric智能合約（ChainCode）

一、鏈碼（Chaincode）簡介

1、鏈碼簡介

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

2、鏈碼的背書策略

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

3、系統鏈碼

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

二、鏈碼功能

Peer節點主要功能是調用鏈碼執行交易和記賬，其中交易執行由背書節點的鏈碼負責，記賬功能由記賬節點負責。

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

三、鏈碼管理

1、鏈碼生命周期

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

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

2、打包鏈碼

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

3、簽名鏈碼

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

4、安裝鏈碼

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

5、實例化鏈碼

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

6、調用鏈碼

調用鏈碼：
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另外的部分，如所有者及實例化策略都是可選的。然而，鏈碼的名稱必須是一致的，否則會被當做另外一個新的鏈碼。
在升級前，必須將新版本的鏈碼安裝到有需求的背書節點上。升級也是一種交易，會把新版本的鏈碼綁定到通道中。升級只能在一個時間點對一個通道產生影響，其它通道仍然運行舊版本的鏈碼。
由于可能存在多個版本的鏈碼同時存在，升級過程不會自動刪除老版本倆馬，用戶必須手動操作刪除過程。
升級與實例化transaction有一點不同的是：通過現有的chaincode實例化策略檢查升級transaction，而不是用新的策略檢查。這是為了確保只有當前實例化策略中指定的成員能夠升級chaincode。
在升級期間，鏈碼的Init函數也會被調用，執行有關升級的數據或者使用數據重新進行初始化，在升級鏈碼的期間避免對狀態進行重置。
安裝新版本的鏈碼
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