以下，將通過一個塊鏈網絡運營商Noah的眼睛來探索鏈碼。於諾亞的興趣，我們將重點關註鏈碼生命周期操作;作為塊代碼在塊鏈網絡中的操作生命周期的函數的鏈式代碼的封裝，安裝，實例化和升級過程。

一、鏈碼生命周期

　　Hyperledger Fabric API允許與塊鏈網絡中的各種節點（對等體，訂戶和MSP）進行交互，並且還允許在批準的對等節點上進行包代碼，安裝，實例化和升級鏈碼。Hyperledger Fabric語言特定的SDK提取了Hyperledger Fabric API的細節，以促進應用程序開發，雖然它可以用於管理鏈碼的生命周期。此外，Hyperledger Fabric API可以通過CLI直接訪問，我們將在本文檔中使用。

　　我們提供四個命令來管理鏈碼的生命周期：包package，安裝install，實例化instantiate和升級upgrade。在未來的版本中，我們正在考慮添加停止stop和啟動start事務以禁用並重新啟用鏈碼，而無需實際卸載它。鏈代碼已成功安裝並實例化後，鏈碼處於活動狀態（正在運行），並可通過調用事務處理事務。鏈碼可以在安裝完成後隨時升級。

二、包Packing

鏈碼包由3部分組成：

　　鏈碼，由ChaincodeDeploymentSpec或CDS定義。 CDS根據代碼和其他屬性（如名稱和版本）定義了chaincode包，

　　可選的實例化策略，可以通過用於認可的相同策略進行語法描述，並在認可政策中描述，

　　一組簽名由實體“擁有”鏈碼。

簽名用於以下目的：

　　建立鏈碼的所有權，允許驗證包的內容，以及 以允許檢測包篡改。

鏈碼上鏈碼的實例化事務的創建者根據鏈碼的實例化策略進行驗證。

1.創建包

　　包裝鏈碼有兩種方法。一個是當你想擁有一個鏈碼的多個所有者，因此需要使用多個身份簽署的鏈碼包。這個工作流程要求我們最初創建一個簽名的鏈碼包（SignedCDS），隨後將其連續傳遞給其他所有者進行簽名。更簡單的工作流程是在部署僅具有發出安裝事務的節點的標識簽名的SignedCDS時。

　　我們將首先處理更復雜的案例。但是，如果您不需要擔心多個所有者，您可以跳到下面的“安裝chaincode”部分。

　　要創建一個簽名的鏈碼包，請使用以下命令：

peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v 0 -s -S -i "AND(‘OrgA.admin‘)" ccpack.out

　　-s選項創建一個可以由多個所有者簽名的包，而不是簡單地創建一個原始的CDS。當指定-s時，如果其他所有者將需要簽名，則還必須指定-s選項。否則，該過程將創建一個SignedCDS，除了CDS之外僅包括實例化策略。

　　-s選項指示進程使用由core.yaml中的localMspid屬性的值標識的MSP對程序包進行簽名。

　　-s選項是可選的。但是，如果沒有簽名創建包，則不能使用signpackage命令由其他所有者簽名。

　　可選的-i選項允許為鏈碼指定實例化策略。實例化策略具有與認可策略相同的格式，並指定哪些身份可以實例化鏈碼。

　　在上面的例子中，只有OrgA的管理員可以實例化鏈碼。如果沒有提供策略，則使用默認策略，這僅允許對等體的MSP的管理員身份實例化鏈碼。

2.包簽名

　　創建時簽署的鏈碼包可以交給其他業主進行檢查和簽名。該工作流程支持鏈碼包的帶外簽名。

　　ChaincodeDeploymentSpec可以由集體所有者可選地簽名以創建SignedChaincodeDeploymentSpec（或SignedCDS）。 SignedCDS包含3個元素：

　　　　1.CDS包含鏈碼的源代碼，名稱和版本。

　　　　2.鏈碼的實例化政策，表示為認可政策。

　　　　3.鏈碼所有者的列表，通過認可來定義。

　　請註意，當某些渠道上的鏈碼被實例化時，這種認可策略是在帶外確定的，以提供適當的MSP主體。如果未指定實例化策略，則默認策略是通道的任何MSP管理員。

　　每個所有者通過將其與該所有者的身份（例如證書）組合並簽署組合結果來批準ChaincodeDeploymentSpec。

　　鏈碼所有者可以使用以下命令簽名先前創建的簽名包：

peer chaincode signpackage ccpack.out signedccpack.out

　　ccpack.out和signedccpack.out分別是輸入和輸出包。 signedccpack.out包含使用本地MSP簽名的包的附加簽名。

3.安裝鏈碼

　　將要安裝的交易鏈碼源代碼打包成一個稱為ChaincodeDeploymentSpec（或CDS）的規定格式，並將其安裝在將運行該鏈碼的對等節點上。

　　您必須在將運行您的鏈碼的通道的每個認可對等節點上安裝鏈碼。

　　當安裝API只是一個ChaincodeDeploymentSpec，它將默認實例化策略並包含一個空的所有者列表。

　　鏈碼只能安裝在鏈碼的擁有成員的認可對等節點上，以保護鏈碼邏輯與網絡上其他成員的機密性。那些沒有鏈碼的成員，不能是鏈碼交易的代言人;也就是說，它們不能執行鏈碼。但是，它們仍然可以驗證並將交易提交給分類帳。

　　要安裝鏈碼，請將SignedProposal發送到系統鏈碼部分中描述的生命周期系統鏈碼（LSCC）。例如，要使用CLI安裝Simple Asset Chaincode簡介中描述的sacc示例鏈碼，命令將如下所示：

peer chaincode install -n asset_mgmt -v 1.0 -p sacc

　　CLI內部為sacc創建SignedChaincodeDeploymentSpec並將其發送到本地對等體，該對等體調用LSCC上的Install方法。-p選項的參數指定鏈碼的路徑，該路徑必須位於用戶的GOPATH的源樹中，例如。 $ GOPATH / src目錄/ SACC。有關命令選項的完整說明，請參閱CLI部分。

　　請註意，為了安裝在對等體上，SignedProposal的簽名必須來自對等體的本地MSP管理員的1。

4、實例化

　　實例化交易調用生命周期系統鏈碼（LSCC）來創建和初始化通道上的鏈碼。這是一個鏈碼信道綁定過程：鏈碼可以綁定到任何數量的信道，並且在每個信道上單獨和獨立地操作。換句話說，無論鏈碼可能被安裝和實例化了多少其他頻道，狀態將與交易提交的頻道保持隔離。

　　實例化交易的創建者必須滿足SignedCDS中包含的鏈碼的實例化策略，並且還必須是通道上的寫入器，它被配置為通道創建的一部分。這對於通道的安全性很重要，以防止流氓實體部署鏈式代碼或欺騙成員來執行未綁定通道上的鏈式代碼。

　　例如，請記住，默認實例化策略是任何MSP管理員通道，因此鏈碼實例化事務的創建者必須是通道管理員的成員。當交易建議到達代理人時，它會根據實例化策略來驗證創建者的簽名。在提交到分類帳之前，在事務驗證期間再次完成此操作。

　　實例交易還在該頻道上設置了該代碼的認可政策。認可政策描述了渠道成員接受的交易結果的認證要求。

　　例如，使用CLI實例化sacc chaincode並用john和0初始化狀態，命令如下所示：

peer chaincode instantiate -n sacc -v 1.0 -c ‘{"Args":["john","0"]}‘ -P "OR (‘Org1.member‘,‘Org2.member‘)"

　　註意認可政策（CLI使用拋光符號），這需要Org1或Org2的任何成員的所有交易的認可。也就是說，Org1或Org2必須對sacc執行Invoke的結果進行簽名，以使事務生效。

　　在成功實例化之後，鏈碼在通道上進入活動狀態，並準備處理ENDORSER_TRANSACTION類型的任何交易提案。這些交易在到達支持對等體時同時處理。

5.更新

　　鏈碼可以隨時通過更改其版本來升級，這是SignedCDS的一部分。其他部分，如所有者和實例化策略是可選的。然而，鏈碼名稱必須相同;否則將被視為完全不同的鏈碼。

　　在升級之前，新版本的鏈碼必須安裝在所需的支持者身上。升級是類似於實例化事務的事務，它將新版本的鏈碼綁定到通道。綁定到舊版本的鏈碼的其他渠道仍然與舊版本一起運行。換句話說，升級事務只會影響一個通道，即交易提交的通道。

　　請註意，由於鏈碼的多個版本可能同時處於活動狀態，所以升級過程不會自動刪除舊版本，因此用戶必須暫時進行管理。

　　與實例化事務有一個微妙的區別：根據當前鏈碼實例化策略檢查升級事務，而不是新策略（如果指定）。這是為了確保只有當前實例化策略中指定的現有成員可以升級鏈碼。

　　請註意，在升級期間，調用chaincode Init函數來執行任何數據相關更新或重新初始化它，因此必須註意在升級鏈碼時避免復位狀態。

6.開始和停止

　　請註意，停止和啟動生命周期交易尚未實施。但是，您可以通過從每個支持者中刪除chaincode容器和SignedCDS包來手動停止鏈碼。這是通過刪除每個承載對等節點運行的每個主機或虛擬機上的鏈碼的容器，然後從每個支持的對等節點刪除SignedCDS：

docker rm -f <container id>
rm /var/hyperledger/production/chaincodes/<ccname>:<ccversion>

　　停止在工作流中以受控的方式進行升級將是有用的，其中在發布升級之前可以在所有對等體上的通道上停止鏈碼。

7.Cli

　　我們正在評估為Hyperledger Fabric對等體二進制文件分發平臺特定二進制文件的需求。暫時的，你可以直接在運行中的docker容器內調用命令。

　　要查看當前可用的CLI命令，請從正在運行的fabric-peer Docker容器中執行以下命令：

docker run -it hyperledger/fabric-peer bash
# peer chaincode --help

Usage:
  peer chaincode [command]

Available Commands:
  install     Package the specified chaincode into a deployment spec and save it on the peer‘s path.
  instantiate Deploy the specified chaincode to the network.
  invoke      Invoke the specified chaincode.
  package     Package the specified chaincode into a deployment spec.
  query       Query using the specified chaincode.
  signpackage Sign the specified chaincode package
  upgrade     Upgrade chaincode.

Flags:
      --cafile string     Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
  -C, --chainID string    The chain on which this command should be executed (default "testchainid")
  -c, --ctor string       Constructor message for the chaincode in JSON format (default "{}")
  -E, --escc string       The name of the endorsement system chaincode to be used for this chaincode
  -l, --lang string       Language the chaincode is written in (default "golang")
  -n, --name string       Name of the chaincode
  -o, --orderer string    Ordering service endpoint
  -p, --path string       Path to chaincode
  -P, --policy string     The endorsement policy associated to this chaincode
  -t, --tid string        Name of a custom ID generation algorithm (hashing and decoding) e.g. sha256base64
      --tls               Use TLS when communicating with the orderer endpoint
  -u, --username string   Username for chaincode operations when security is enabled
  -v, --version string    Version of the chaincode specified in install/instantiate/upgrade commands
  -V, --vscc string       The name of the verification system chaincode to be used for this chaincode

Global Flags:
      --logging-level string       Default logging level and overrides, see core.yaml for full syntax
      --test.coverprofile string   Done (default "coverage.cov")

Use "peer chaincode [command] --help" for more information about a command.

　　為了方便在腳本化應用程序中的使用，在命令失敗的情況下，對等體命令總是生成一個非零返回碼。

peer chaincode install -n mycc -v 0 -p path/to/my/chaincode/v0
peer chaincode instantiate -n mycc -v 0 -c ‘{"Args":["a", "b", "c"]} -C mychannel
peer chaincode install -n mycc -v 1 -p path/to/my/chaincode/v1
peer chaincode upgrade -n mycc -v 1 -c ‘{"Args":["d", "e", "f"]} -C mychannel
peer chaincode query -C mychannel -n mycc -c ‘{"Args":["query","e"]}‘
peer chaincode invoke -o orderer.example.com:7050  --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C mychannel -n mycc -c ‘{"Args":["invoke","a","b","10"]}‘

三、系統鏈碼

　　系統鏈碼具有相同的編程模型，除了它在對等體進程中運行，而不是象一般鏈接碼在孤立的容器中運行。因此，系統鏈碼內置於對等可執行文件中，並不遵循上述相同的生命周期。特別是安裝，實例化和升級不適用於系統鏈碼。

　　系統鏈碼的目的是在對等和鏈碼之間實現快捷的gRPC通信成本，並且權衡管理的靈活性。例如，系統鏈碼只能用對等體二進制升級。它還必須使用固定的一組參數進行註冊，並且不具有認可政策或認可政策功能。

　　系統鏈碼在Hyperledger Fabric中用於實現多個系統行為，以便系統集成商可以根據需要對其進行替換或修改。

　　當前系統鏈碼列表：：

　　1.LSCC生命周期系統鏈碼【 Lifecycle system chaincode】處理上述生命周期請求。

　　2.CSCC配置系統鏈碼【Configuration system chaincode】處理對端的通道配置。

　　3.QSCC查詢系統鏈碼【Query system chaincode】提供分類帳查詢API，例如獲取塊和事務。

　　4.ESCC認可系統鏈碼【Endorsement system chaincode 】通過簽署交易建議回復來處理認可。

　　5.VSCC驗證系統鏈碼【Validation system chaincode】處理事務驗證，包括檢查認可策略和多路調用並發控制。

　　修改或更換這些系統鏈式代碼時，特別是LSCC，ESCC和VSCC必須小心，因為它們在主事務執行路徑中。值得註意的是，由於VSCC在將其提交給分類帳之前對塊進行驗證，所以通道中的所有對等體都必須計算相同的驗證以避免分類分歧（非確定性）。如果VSCC被修改或更換，則需要特別小心。

008-運維管理鏈碼