Hyperledger Fabric链码之三

在《Hyperledger Fabric链码之一》和《Hyperledger Fabric链码之二》中我们介绍了链码的定义，并通过dev网络测试了测试了自己编写的链码程序。

本文中我们站在区块链网络管理员的角度来阐述链码，我们集中在链码的声明周期管理，如链码的打包，安装，初始话以及升级。

链码声明周期

超级帐本Fabric提供的接口使得多种类型的节点能够进行交互 — 节点，排序节点以及成员管理服务 — 同时使得在背书节点上可以进行打包、安装、初始化和升级链码。

Hyperledger Fabric的SDKs对API接口进行了抽象以便于应用开发，用来管理链码的生命周期。此外Hyperledger Fabric的API可以通过CLI的方式直接访问，本文中我们使用了这种方式。

我们为链码的生命周期管理提供了4个命令 package, install, instantiate, 以及 upgrade。以后版本中，我们计划添加stop和start交易来关闭和启动链码而不需要真正的卸载它。链码被成功安装和初始化后，链码会处于激活状态（running）并通过invoke来处理交易。之后链码也可以被升级。

打包

链码的打包包含3个部分：

链码，被定义为ChaincodeDeploymentSpec或者CDS。 CDS根据代码以及名字和版本来定义链码包。
一个可选的初始化策略，语法构成上与背书endorsement-policies相同
一组签名，来自拥有该链码的实体

签名具有下面的目的：
建立链码归属权
验证链码包的内容
防止链码包篡改

在一个channel中链码初始化交易的创建者会经过链码的初始化策略的验证。

创建链码包

有两种方式来打包链码。一种方式是：当一个链码有多个拥有者，因此需要链码包被多个身份进行签名。首先需要创建一个签名的链码包SignedCDS，然后顺序传送给其他拥有者进行签名。

更简单的方式是：当部署一个仅仅由一个节点签名的SignedCDS时执行install交易

我们首先解决最复杂的情况。但是，如果你不需要担心多个拥有者的情况，你可以直接跳到:ref:安装章节。

使用下面的命令创建链码包

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选项。否则，除了CDS以外，上述命令会创建一个仅包含初始化策略的SignedCDS。

-S选项用来指导链码包的签名过程，使用core.yaml文件中localMspid指定的MSP的值。该选项是可选的。然而如果链码包创建没有使用签名，也就不能被别的拥有者使用signpackage命令来进行签名。

选项-i允许指定链码的初始化策略。初始化策略与背书策略具有相同的格式，用来指定什么身份可以来初始化链码。在上面的例子中，仅仅OrgA的管理员能够初始化该链码。如果未提供初始化策略，会使用默认值，仅允许节点MSP的管理员身份来初始化链码。

链码包签名

被签名的链码包被创建后可以交给其他拥有者进行检查和签名。工作流支持线下的链码包签名。

ChaincodeDeploymentSpec 被一组拥有者进行签名得到 SignedChaincodeDeploymentSpec或者SignedCDS. SignedCDS包含3个元素：

注意::背书策略是线下确定的，用来提供合适的MSP规则当链码在一些通道初始话的时候。如果未指定初始化策略，那么缺省策略是通道的任何MSP管理员。

每个拥有者背书ChaincodeDeploymentSpec, 然后结合自己的身份（比如证书）后进行签名。

链码拥有者可以使用如下的命令对之前签名的链码包进行签名

 peer chaincode signpackage ccpack.out signedccpack.out

其中， ccpack.out和`signedccpack.out``分别是命令的输入和输出。后者包含一个额外的本地MSP签名。

安装

install交易将链码源码打包为一个指定的格式ChaincodeDeploymentSpec （或者CDS），并安装到运行链码的节点上。

注意：链码必须安装在同一个通道的所有背书节点上。

当install API输入参数仅是ChaincodeDeploymentSpec时，会使用默认的初始化策略并包含一个空的拥有者列表。

注意：链码应该仅安装在拥有者的背书节点上以保护链码逻辑的机密性，防止网络中其他成员的访问。那些没有链码的成员，不能作为链码交易的背书人；也就是说，他们不能执行链码。然而，他们仍然可以验证和提交交易。

为了安装链码，需要向lifecycle system chaincode (LSCC), 在System Chaincode章节描述，发送一个SignedProposal。例如，安装sacc链码。

使用CLI的方式，安装命令如下：

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

CLI内部会为sacc创建SignedChaincodeDeploymentSpec 并且发送给本地的peer，节点调用LSCC的install方法。-p参数指定了链码的路径，必须在用户GOPATH下，例如$GOPATH/src/sacc。 CLI命令的完整描述参考CLI章节。

值得注意的是为了在节点上安装链码，SignedProposal的签名必须来自peer本地MSP管理员。

初始化

instantiate交易调用lifecycle System Chaincode (LSCC)`创建并初始化通道中的链码。这是一个链码-通道绑定的过程：链码可以绑定到多个通道中，并独立运行在每一个通道中。也就是说，不管链码被安装并初始化到多少个通道中，通道状态都是隔离的。

instantiate交易的创建者必须在SignedCDS中指定初始化策略，同时必须在通道中具有可写权限，在通道创建时配置。这些对于防止恶意实体部署链码并欺骗成员执行链码具有重要作用。

例如，默认的初始化策略是通道MSP的任意管理员，因此链码初始化交易的创建者必须是一个通道管理员。当交易提议发送到背书节点，会使用背书策略验证创建者的签名。在交易提交到账本前的验证阶段会再一次进行验证。

初始化交易也会为通道中链码设置背书策略。背书策略描述的是需要多少个对交易结果的背书，交易才能被通道成员承认。

比如，使用CLI的方式来初始化sacc链码，并用状态john和0来进行初始化，命令描述如下：

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

注意：上面命令中背书策略（使用波兰表示法）表示需要Org1或者Org2中的任意成员对所有sacc的所有交易进行背书。即，Org1或Org2必须对执行Invoke的结果进行签名，交易才是有效交易。

交易成功初始化后，链码进入了激活状态，准备处理接收到的类型为ENDORSER_TRANSACTION的交易提议。交易在背书节点上进行并行处理。

升级

链码可以通过改变版本号的方式来进行升级，版本号是SignedCDS的一部分。其他组成有拥有者、背书策略是可选的。然而，链码名必须是相同的，否则会被认为是完全不同的链码。

升级前，新版本的链码必须首先安装到背书节点上。升级交易与初始化交易类似，会将新版本的交易绑定到通道中。其他绑定旧版本的通道仍然运行旧版本。也就是说upgrade交易一次只影响一个通道，即交易提交到的通道。

注意：既然链码多个版本可以同时运行，那么升级过程不会自动移除旧版本，因此用户需要自己进行处理。

与instantiate细微的不同是：upgrade交易会用当前链码的初始化策略进行检查，而不是新的策略。这样用来保证只有当前初始化策略指定的成员能够来升级链码。

注意：在升级阶段，链码Init函数会被调用来升级数据或者重新初始化，因此当升级链码的时候需要格外小心防止重新设置状态。

停止和启动

stop和start交易现在还没有实现。然而，你可以通过手动删除每个背书节点上的链码容器和SignedCDS包来停止一个链码。注：你需要登入peer节点容器来删除CDS。我们提供一个工具脚本来执行这个操作。

 docker rm -f <container id>

rm /var/hyperledger/production/chaincodes/<ccname>:<ccversion>

链码的停止将有助于在可控方式下进行升级，在链码升级前，将通道中所有节点上的链码进行停止。

CLI

注：我们需要平台相关的二进制可执行程序peer. 现在，你可以简单的在运行的docker容器中使用此命令。

在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命令在执行失败的时候会返回一个非零的错误码。

链码命令使用示例：

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

系统链码

系统链码与链码具有相同的编程模型，不同的是，系统链码运行在peer进程中，而不是隔离的docker容器中。因此，系统链码被编译进了peer可执行程序中，生命周期与前面的不同。比如，系统链码没有install,instantiate和upgrade。

系统链码的作用是降低节点和链码之间的gRPC通信开销，折中了管理的灵活性。例如，系统链码只能使用peer二进制程序来升级。也必须使用固定的参数来注册，不具有背书策略或者背书策略函数。

系统链码在Fabric中用来实现一些系统行为，可以进行合理的替换和修改。

当前提供的系统链码列表：

在对系统链码进行修改和替换时需要格外的小心，尤其是LSCC，ESCC和VSCC，因为他们管理了整个交易的执行。值得注意的是在将交易提交到账本前VSCC来验证一个区块的有效性，通道中所有节点执行相同的验证以防止账本分叉（不确定）是至关重要的。因此需要格外关注VSCC的修改和替换。

------------------------------------------------------------------------------------完美的终结线--------------------------------------------------------------------------------------