05-ChainCode生命周期、分类及安装、实例化命令解析 |我的资源库露水湾

在 HyperLedger-Fabric 区块链网络中，ChainCode是一个重要的部分。它运行在与外界隔离的容器中，承担着更新账本的重要功能。可以说，Fabric 区块链网络所维护的公共账本，正是因为有了ChainCode，才有了“代码即法律”一说。接下来，这篇文章将来将简单介绍一下ChainCode。全文按照如下结构来展开：

1、ChainCode 与智能合约

首先，来说一下智能合约。

智能合约，是一个抽象的概念。那么，智能合约有什么样的特性呢？

智能合约的历史可以追溯到 1990s 年代。它是由尼克萨博（Nick Szabo）提出的理念，几乎与互联网同龄。他在发表在自己的网站的几篇文章中提到了智能合约的理念。他的定义如下：

“一个智能合约是一套以数字形式定义的承诺（promises），包括合约参与方可以在上面执行这些承诺的协议。”

这样高度抽象的定义，只有建立在一定的知识储备量，才能够理解。这里，我们不去强行解释清楚什么是智能合约，而是抓住智能合约的几个重要的属性，来慢慢的理解智能合约。

简单来讲智能合约就是用程序实现合约的内容，并且这个程序是事件驱动、有状态的。下图是智能合约的模型。

智能合约程序不只是一个可以自动执行的计算机程序：它自己就是一个系统参与者。它对接收到的信息进行回应，它可以接收和储存价值，也可以向外发送信息和价值。

这个程序就像一个可以被信任的人，可以临时保管资产，总是按照事先的规则执行操作。

智能合约模型：它是运行在可复制、共享的账本上的计算机程序，可以处理信息，接收、储存和发送价值。

从合同的角度来说，智能合约（Smart contract ）是一种旨在以信息化方式传播、验证或执行合同的计算机程序。

那么，什么是ChainCode？

ChainCode（链码）是智能合约在 Fabric 区块链网络的实现形式。

链码被部署在 Fabric 网络节点上，运行在隔离沙盒（目前为 Docker 容器）中，并通过 gRPC 协议与相应的 Peer 节点进行交互，以操作分布式账本中的数据。

启动 Fabric 网络后，可以通过命令行或 SDK 进行链码操作，验证网络运行是否正常。

它扮演的角色如下图所示：

应用程序通过向区块链网络发送交易来调用智能合约，从而操作账本中的状态。

2、ChainCode 的运行方式

在 Fabric 中交易的处理过程，客户端将提案首先发送到背书节点，背书节点检提案的合法性。如果合法的话，背书节点将通过交易所属的链码临时执行一个交易，并执行背书节点在本地持有的状态副本。

Chaincode应该仅仅被安装于 chaincode 所有者的背书节点上，链码运行在节点上的沙盒（Docker 容器）中，并通过 gRPC 协议与相应的 Peer 节点进行交互，以使该 chaincode 逻辑对整个网络的其他成员保密。

请务必在一条 channel 上每一个要运行你 chaincode 的背书节点上安装你的 chaincode

其他没有 chaincode 的成员将无权成为 chaincode 影响下的交易的认证节点（endorser）。也就是说，他们不能执行 chaincode。不过，他们仍可以验证交易并提交到账本上。

ChainCode要在区块链网络中运行，需要经过链码安装和链码实例化两个步骤。

[多次安装，一次实例化]
在一个区块链子链中，该网络是由“1 账本+1 通道+N 个 peer 节点”组成。
如果我们要手动来搭建 Fabric 网络的话，即通过命令行的形式来进行 ChainCode 的安装与实例化。我们需要多次 install，一次 instance。

也就是说，对于整个 Fabric 网络来说，假设有 X 个背书节点，那么，我们需要给每个背书节点安装 ChainCode，但是在整个网络搭建过程中只需要 instance ChainCode 一次。
因为 install 针对的是背书节点，instance 针对的是通道。

install 链码的对象是背书节点，主要目的是方便背书节点对运行链码，对交易进行模拟。
instance 链码的对象是 channel，主要目的是为了将安装过的链码在指定通道上进行实例化调用，在节点上创建容器启动，并执行初始化操作。实例化的过程中，需要指定背书策略，来确定通道上哪些节点执行的交易才能添加到账本中。

安装的过程其实就是对指定的代码进行编译打包，并把打包好的文件发送到 Peer，等待接下来的实例化。其实，这就是我们接下来要讲解的链码的生命周期这一部分。

实例化链上代码主要是在 Peer 所在的机器上对前面安装好的链上代码进行包装，生成对应 Channel 的 Docker 镜像和 Docker 容器。并且在实例化时我们可以指定背书策略。

1. Chaincode 运行在一个受保护的 Docker 容器当中，与背书节点的运行互相隔离。
2. Chaincode 可通过应用提交的交易对账本状态初始化并进行管理。

3、ChainCode 的生命周期

对于区块链网络的操作者来说，他们也许并不想涉足 chaincode 应用的开发，不过却需要肩负管理区块链网络的责任，并运用 Hyperledger Fabric API 来安装、实例化与升级 chaincode。

Hyperledger Fabric API 提供了四个管理 chaincode生命周期的命令：package, install, instantiate,upgrade。在未来的版本中，正考虑添加stop和start交易的指令，以便能方便地停止与重启 chaincode，而不用非要真正卸载它才行在一个区块链网络中，将打包、安装、实例化和升级 chaincode 的过程作为一种可操作的 chaincode生命周期函数进行调用。

在这里，我们简单讨论package,signpackage ，install, instantiate,upgrade，stop&start这几个生命周期。具体如下图所示：

1.Packaging | 打包

在区块链中，将链码安装到 Peer 节点，与我们安装普通程序不一样。

Fabric 对链码的安装有严格的验证和安全机制。

安装好的链码，谁有资格实例化？

又该使用什么样的背书策略来调用 ChainCode 呢？

这一切，都需要在安装之前，将它们规定好。我们把这些附加信息+ChainCode 源码统称为 ChainCode 包。

一般而言，ChainCode 包由以下三个部分组成：

chaincode 本身，其由ChaincodeDeploymentSpec（Chaincode 部署规范）来定义。ChaincodeDeploymentSpec，以下简称CDS。CDS 是根据代码及一些其他属性（名称，版本等）来定义 chaincode。
一个可选的实例化策略，该策略可被 背书策略 描述。
一组表示 chaincode所有权的签名。

打包的过程，就是将这三部分信息打包成一个整体。一般来说，打包 chaincode 有两种方式：

第一种是当你想要让 chaincode 有多个所有者的时候，此时就需要让 chaincode 包被多个所有者签名。这种情况下需要我们创建一个被签名的 chaincode 包（SignedCDS），这个包依次被每个所有者签名。

另一种就比较简单了，让 chaincode 有一个所有者的时候，此时只要被一个人签名即可。

要创建一个签名过的 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也必须同时使用。否则，该过程将创建一个仅包含实例化策略的签名 chaincode 包（SignedCDS）。
-S选项可以使在core.yaml文件中被localMspid相关属性值定义好的 MSP 对包进行签名。该选项是可选的。不过，如果我们创建了一个没有签名的包，那么它就不能被任何其他所有者用signpackage指令进行签名。
-i选项也是可选的，它允许我们为 chaincode 指定实例化策略。实例化策略与背书策略格式相同，它指明谁可以实例化 chaincode。

2.signpackage | 签名并打包

一个在创建时就被签名的 chaincode 包可以交给其他所有者进行检查与签名。具体的工作流程支持通道外对 chaincode 包签名。

ChaincodeDeploymentSpec 可以选择被全部所有者签名并创建一个 SignedChaincodeDeploymentSpec（SignedCDS），SignedCDS 包含三个部分：

CDS 包含 chaincode 的源码、名称与版本
一个 chaincode 实例化策略，其表示为背书策略
chaincode 所有者的列表，由 Endorsement 定义

一个 chaincode 所有者可以对一个之前创建好的带签名的包进行签名，具体使用如下指令：

peer chaincode signpackage ccpack.out signedccpack.out

指令说明：

指令中的ccpack.out和signedccpack.out分别是输入与输出包。
signedccpack.out则包含一个用本地 MSP 对包进行的附加签名。

3. install | 安装

install 的过程会将 chaincode 的源码以一种被称 ChaincodeDeploymentSpec（CDS）的规定格式打包，并把它安装在一个将要运行该 chaincode 的 peer 节点上。

在 Fabric 网络中，我们需要在一个 channel 上每一个要运行你 chaincode 的背书节点上安装你的 chaincode。

Chaincode 应该仅仅被安装于 chaincode 所有者的背书节点上，以使该 chaincode 逻辑对整个网络的其他成员保密。其他没有 chaincode 的成员将无权成为 chaincode 影响下的交易的认证节点（endorser）。对于认证节点来说，他们不能执行 chaincode。不过，他们仍可以验证交易并提交到账本上。

下面安装 chaincode：

使用 CLI 安装一个存放在 sacc 目录下的 chaincode 时，命令如下

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

选项说明：

-n：name 对链码进行命令
-v: version 指定 chaincode 的版本
-p: path 指明 chainCode 的路径

在 CLI 内部会为 sacc 创建 SignedChaincodeDeploymentSpec，并将其发送到本地 peer 节点。这些节点会调用 LSCC 上的Install方法。

4. instantiate | 实例化 chaincode

实例化 ChainCode 过程会调用 生命周期系统 chaincode (LSCC)来在一个 channel 上创建并初始化一段 chaincode。实例化过程，会生成对应 Channel 的 Docker 镜像和 Docker 容器。并且在实例化时我们可以指定背书策略。

当然，一个实例化交易的创建者必须符合在 SignedCDS 中 chaincode 的实例化策略，且必须充当 channel 的写入器（这会成为 channel 创建配置的一部分），这对于 channel 的安全至关重要。

使用 CLI 去实例化名为 mycc 的 chaincode，指令具体如下：

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

选项说明：

-n 实例化链码的名称
-c –ctor，链码的具体执行参数，为 json 格式
-P –Policy 指定实例化策略

5.upgrade | 升级 chaincode

一段 chaincode 可以通过更改它的版本（SignedCDS 的一部分）来随时进行更新。至于 SignedCDS 的其他部分，比如所有者及实例化策略，都是可选的。不过，chaincode 的名称必须一致，否则它会被当做完全不同的另一段 chaincode。

在升级之前，chaincode 的新版本必须安装在需要它的背书节点上。升级是一个类似于实例化交易的交易，它会将新版本的 chaincode 与 channel 绑定。其他与旧版本绑定的 channel 则仍旧运行旧版本的 chaincode。换句话说，升级交易只会一次影响一个提交它的 channel。

6.stop&star | 停止与启动

注意，停止与启动生命周期交易的功能还没实现。不过，你可以通过移除 chaincode 容器以及从每个背书节点删除 SignedCDS 包来停止 chaincode。具体而言，就是删除所有主机或虚拟机上 peer 节点运行于其中的 chaincode 的容器，随后从每个背书节点删除 SignedCDS。

7.chainCode 的状态总结

在上述的过程中，ChainCode 的状态有以下几种。这里做一个小总结：

CDS -ChainCodeSpec 包含链码源码，名称，版本等信息
SignedCDS-SignedChaincodeDeploymentSpec ，包含 CDS、一个 chaincode 实例化策略，其表示为背书策略、chaincode 所有者的列表，由 Endorsement 定义。