8、运维管理链码

如下，将经过一个块链网络运营商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

  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被修改或更换，则须要特别当心。