Hyperledger Fabric New Chaincode Lifecycle V 2.0

我最近在看文档，希望能为大家学习提供一点帮助，欢迎查看之前翻译的文章、提问以及建议，谢谢。

Chaincode 命令介绍

Chaincode 是规则，是业务逻辑，用来定义资产，修改已定义的资产。链码由交易提案触发。链码针对的是账本的状态数据库。

所有对等节点都具有“系统”链码（ system chaincode ），用于管理验证和认可策略，它们还具有生命周期链码（lccc），用于管理已安装和已部署链码的生命周期。节点只有被指定为背书节点时，才安装对应的应用程序链码（ application chaincode ）

Init

一种初始化链码应用程序的方法。所有链码都需要具有一个 Init函数。默认情况下，此功能从不执行。但是，您可以使用链码定义来请求执行 Init 函数，以初始化链码（ Init 也是一个 proposal ）。

Install

The process of placing a chaincode on a peer’s file system.

Instantiate （已被 chaincode define 替代）

在通道上启动和初始化 Chaincode 应用程序的过程。实例化之后，安装了链码的节点可以接受链码的调用。

注意： 在1.4.x和更早版本的chaincode生命周期中使用了此方法。

Chaincode define

在链码可以在通道上使用之前，参与组织需要就链码参数达成共识。一旦足够多的通道成员同意了链码定义（默认情况下设置为该通道中的大多数组织），就可以将链码提交给该渠道。提交后，链码的首次调用将在通道上启动链码。

Query

查询是链码调用，只读取账本的当前状态，但不写入账本。查询账本上的某些关键字，也可以查询账本上的一组密钥。

由于查询不会更改账本状态，因此客户端应用程序通常不会提交这些该交易提案（只读）给排序服务排序、验证和提交。

尽管不是很常见，但是客户端应用程序也可以选择提交，例如，如果客户端希望链上记录自己查账了，没偷懒，别说我没查，你去看记录。

Invoke

用于调用 chaincode 函数。客户端应用程序通过向 peer 发送交易提案来调用链码。其中包括通道 ID、要调用的chaincode函数以及一系列的参数。

peer lifecycle chaincode 命令

命令

Deploying a chaincode

Fabric 链码生命周期可能包含以下过程：
安装并定义一个链码升级链码部署方案迁移到新的Fabric生命周期

Install and define a chaincode

V 2.0 要求组织同意链码中包含的参数，例如名称，版本和链码认可策略。一个通道中的组织通过以下四个步骤达成协议，当然并非通道上的每个组织都需要完成这些步骤。

1. 链码打包，只需通道中的任一组织完成
2. 安装链码：每个将使用链码来为交易背书或查询账本的组织都需要完成此步骤
3. 同意链码参数：每个将使用链码的组织（一般是组织内的管理员代替组织完成）都可以完成此步骤。在通道上使用链码前，必须达到一定数量的组织同意该链码参数。
4. 链码参数提交到通道：完成 #3 后，由一个组织进行提交该参数到通道。提交者首先收集大家同意的签名（类似客户端提交交易提案），然后提交交易提案。

要了解有关的 CLI 命令，请参考 peer lifecycle chaincode

步骤 1 ：链码打包

链码必须先打包为 tar 文件，然后才能安装在节点上。您可以使用二进制文件（ peer ），Node Fabric SDK或第三方工具（例如GNU tar）来打包链码。创建链码压缩包时，需要提供一个链码标签，以简洁易读的描述该链码。

如果您使用第三方工具打包链码，则生成的文件需要采用以下格式。二进制文件和 Fabric SDK 将自动创建此格式的文件。

• 链码需要打包在一个 tar 文件中，并以 .tar.gz 文件扩展名结尾
• tar 文件需要包含两个文件（无目录）
  • 一个元数据文件metadata.json
  • 一个包含链码的 tar 文件。

metadata.json包含代码路径、链码使用的语言和程序包的标签。下面是示例：

{"Path":"fabric-samples/chaincode/fabcar/go","Type":"golang","Label":"fabcarv1"}

如图 1，链码由 Org1 和 Org2 分别打包。两个组织都使用 MYCC_1 作为标签，也非必须使用相同的包装标签。

步骤 2：安装链码

您需要在将执行和背书交易的每个节点上安装链码。您的对等方将在安装链码后构建链码，如果链码存在问题，则返回构建错误。官方建议组织仅将链码打包一次，然后在属于组织的每个节点上安装相同的软件包。如果通道想要确保每个组织都运行相同的链码，则一个组织可以打包一个链码并将其发送到通道的其他成员。

成功安装将返回一个链码标识符，该标识符是链码标签和其哈希值。此标识符将会在第三步使用，您可以进行保存。您还可以通过使用命令查询节点上安装的链码包来查看链码标识符。

如上图，来自 Org1 和 Org2 的节点将链码压缩包 MYCC_1 安装在加入该通道的对等节点上。

同意链码参数

链码必须满足一定条件后，比如需要一半以上的组织同意，链码中的参数才能够生效。主要包含以下参数，这些参数在组织之间必须保持一致：

• 名称：应用程序在调用链码时将使用的名称。
• 版本：与给定的链码关联的版本号或值。如果升级链码，需要更改链码版本。
• 序号：更新链码的次数。此值是整数，用于跟踪链码。例如，当您第一次安装并同意链码参数时，序列号将为1。下次升级链码时，序列号将增加为2。
• 背书策略：哪些组织需要执行和验证交易。背书策略可以为传递给 CLI 的字符串，也可以引用通道配置中的策略。默认情况下，背书策略设置为Channel/Application/Endorsement，默认情况下一个交易要求通道中的大多数组织背书。
• 集合配置：与您的链码关联的私有数据集定义文件的路径。有关私有数据收集的更多信息，请参阅Private Data architecture reference。
• ESCC / VSCC 插件：此链码将使用的自定义背书或验证插件的名称。
• Initialization：同意链码参数时可以使用--init-required标志，以指示必须调用Init函数来初始化新的链码。要使用 CLI 调用Init，请使用peer chaincode invoke命令并传递--isInit标志。

每个想要使用链码的通道成员都需要为其组织批准链码参数。该批准需要提交给排序服务，然后再分发给所有节点。该批准需要由您的组织管理员提交。成功提交批准交易后，批准的定义将存储在一个集合中，该集合可供组织的所有节点使用。

如上图，Org1 和 Org2 的组织管理员为他们的组织批准 MYCC 的链码参数，包括链码名称，版本和背书策略以及其他字段。由于两个组织都将使用链码来背书交易，因此两个组织都需要包含 packageID。

链码参数提交到通道

您可以使用checkcommitreadiness命令检查哪些通道组织同意了链码参数。需要的组织数量由Channel / Application / LifecycleEndorsement策略控制。LifecycleEndorsement策略与链码的背书策略是无关的。有关 fabric 中策略的文章。

如上图， 来自 Org1 或 Org2 的一位组织管理员将链码参数提交给通道。通道上的定义不包括 packageID。

注意：组织可以同意链码参数而不安装链码。

在将链码参数提交到通道后，链码容器将在已安装链码的所有节点上启动，从而允许通道成员开始使用链码。启动链码容器可能需要几分钟。您可以使用链码参数来要求调用 Init 函数来初始化链码。如果要求调用Init函数，则链码的第一次调用必须是对Init函数的调用。Init函数的调用也受链码背书策略的约束。

如下图，一旦在通道上提交了 MYCC 参数，Org1 和 Org2 就可以开始使用链码了。每个节点上的链码的第一次调用都会在该节点上启动链码容器。

Upgrade a Chaincode

您可以使用部署链码的步骤来升级链码。您可以升级链码二进制文件，或仅更新链码策略。请按照以下步骤升级链码：

1. 重新打包链码：仅在升级链码二进制文件时，你只需要完成此步骤。
   

2. 安装新的链码压缩包：安装新的chaincode软件包将生成一个链码 ID，您需要将其传递给新的链码参数。您还需要更改链码版本，生命周期流程将使用它来跟踪链码是否已升级。如下图，Org1 和 Org2 在 peer 上安装新的链码，创建了一个新的 packageID。
   

3. 同意链码参数：新参数中的序列加1。新参数引用了新的packageID 并更改了链码版本。由于这是链码的第一次更新，因此序列从 1 递增到 2。
   

4. 提交：当足够数量的通道组织批准了新的链码参数时，一个组织可以提交新参数以将链码升级。
   

将新参数提交给通道后，每个节点将自动启动新的链码容器。Fabric 链码生命周期使用链码参数中的序列来跟踪升级。所有通道成员都需要将序列号增加一，并批准新的参数以升级链码。版本参数用于跟踪链码二进制文件，仅在升级链码二进制文件时才需要更改。

Sample

Joining a channel

新加入的组织可以使用已提交的链码，并在安装、批准链码后，开始使用链码。

如图， Org3。

该链码参数不需要再次提交。如果将背书策略设置为默认策略，要求大多数成员进行背书，则背书策略将自动更新以包括新组织。

在首次调用后，链码容器将生成。

Updating an endorsement policy

您可以使用链码参数来更新背书策略，而不必重新打包或重新安装链码。渠道成员可以批准带有新背书策略的链码参数，并将其提交给通道。

Org1，Org2 和 Org3 批准了一项新的背书策略，要求所有三个组织都需要认可一项交易。它们将定义序列从 1 递增到 2，但不需要更新链码版本。新的背书政策将在将新参数提交给通道后生效。

Approving a definition without installing the chaincode

您可以批准链码参数而不安装链码。这使您可以在将链码参数提交到通道之前对其进行背书，即使您不想使用该链码对交易进行背书或查询账本。您需要批准与通道的其他成员相同的参数，但不需要将 packageID 包含在链码定义中。

如上图，Org 3不安装链码。结果，他们不需要提供 packageID作为链码参数的一部分。但是，Org3仍然可以认可已提交给该频道的 MYCC 的参数。

One organization disagrees on the chaincode definition

Org3 批准的链码参数与Org1和Org2的不同。结果，Org3无法在通道上使用 MYCC 链码。但是，Org1或Org2仍然可以获得足够的认可，以将定义提交到通道并使用链码。链码中的交易仍将添加到分类帐中并存储在 Org3 的节点中。但是，Org3 无法背书交易。组织可以批准具有任何序列号或版本的新链码。您也可以批准新的链码参数，以更正在批准或打包链码过程中犯的任何错误。

The channel does not agree on a chaincode definition

如果通道上的组织不同意链码参数，则无法将该参数提交给通道。任何通道成员都将无法使用链码。

Org1，Org2 和 Org3 都认可不同的链码参数。结果，该通道的任何成员都无法获得足够的背书以将链码定义提交给该通道。任何通道成员都无法使用链码。

Organizations install different chaincode packages

每个组织在批准链码参数时都可以使用不同的 packageID。这允许通道成员安装使用相同背书策略的、不同的链码二进制文件，并在同一链码名称空间中读取和写入数据。组织可以使用此功能来安装包含特定于组织的业务逻辑的智能合约。每个组织还可以编写代码，以帮助将智能合约与其现有系统中的数据集成在一起。

Creating multiple chaincodes using one package

您可以通过同意并提交多个链码参数，而使用一个链码包。每个都需要指定一个不同的链码名称。这使您可以在一个通道上运行智能合约的多个实例，使合约服从不同的背书策略。

Org1 和 Org2 使用 MYCC_1 链码包来批准和提交两个不同的链码参数。结果，两个节点都有两个在其对等点上运行的链码容器。MYCC1的背书政策为1/2，而MYCC2的背书政策为2/2。