008-運維管理鏈碼

　　如下，將經過一個塊鏈網絡運營商Noah的眼睛來探索鏈碼。於諾亞的興趣，咱們將重點關注鏈碼生命週期操做;做爲塊代碼在塊鏈網絡中的操做生命週期的函數的鏈式代碼的封裝，安裝，實例化和升級過程。

1、鏈碼生命週期

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

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

2、包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。

四、實例化

　　實例化交易調用生命週期系統鏈碼（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.

View Code

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

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"]}'

3、系統鏈碼

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

　　系統鏈碼的目的是在對等和鏈碼之間實現快捷的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被修改或更換，則須要特別當心。