一文读懂Fabric 2.0新特性

前言

链码不需要“实例化”，可以同时运行java和go链码，同一个链码多次实例化。

想要了解上面的特性，请看下面的分解。

Fabric 2.0 在2020年1月29号终于release了，我们来看下有哪些新的变化。

主要体现在：对新应用和隐私的支持，增强了智能合约的管理，增加了对节点的操作。

需要注意的是，只能由fabric-1.4.x升级到2.0。

ps：在网上有个翻译，那一字一句的翻译，真的让我很难受。

下面我尝试使用自己的理解来解读。
(ps:我是在本地写的，导致导入的时候，有些图片未能上传，有需要看的，请移步到我的blog：https://haojunsheng.github.io/2020/02/fabric-relase-2/)

1. 智能合约的去中心化管理

fabric 2.0引入了智能合约的去中心化管理，在此之前，链码的安装和实例化都是一个由组织在操作，现在则发生了变化。新的链码的生命周期中，只有多个组织达成了共识，才可以和账本才可以进行交互。

• 多个组织必须同意链码的参数。在2.0之前，一个组织可以为channel中的所有成员设置链码的参数（例如实例化链码时指定的背书策略），拒绝安装链码的组织将不能参与链码的调用。在2.0中，同时提供中心化的模型和去中心化的模型。
• 链码的升级更加安全。在之前的链码生命周期中，一个组织即可升级链码。在新的版本中，需要别的组织进行同意。
• 简化了背书策略和private data的更新。我们不必重新打包/安装链码即可更新背书策略和private data集合的配置。同时我们设置了默认的背书策略，默认的背书策略在我们增加或者删除组织的时候会自动生效。
• 打包链码：会打包为tar文件，方便进行阅读。
• 一次打包多次复用：之前链码是通过名字+版本号来决定的，现在一次打包生成多个名字，可以多次安装（在相同或者不同的通道上）
• 不需要所有人的同意即可打包chaincode：组织可以扩展链码，不需要所有人的同意，只要符合背书要求，这些交易即可被更新到账本中。这样做的好处是，不需要所有人的同意，即可小规模的修改链码的bug。

1.1 链码新的生命周期

1.1.1 链码的安装和定义

新的链码周期要求组织对链码的名字，版本，背书策略达成一致，需要执行以下四步，但不需要每个组织都执行：

• 打包链码：一个或者每一个组织完成。
• 自己的节点安装链码。每个组织要执行，因为需要交易或者查询账本。
• 同意链码的定义：需要满足channel LifecycleEndorsment（默认是大多数）策略的足够数量的组织来执行。
• 提交chaincode的定义：第一个收集到足够数量的节点来执行。

下面来详细的看上面4步：

1.1.1.1 打包链码

链码在安装前需要打包为tar文件。我们可以使用peer命令，node sdk，或者第三方工具。

第三方的打包工具需要满足以下要求：

• 链码以tar.gz结尾；

• tar文件需要包含2个文件（不是目录），元文件Chaincode-Package-Metadata.json和chaincode文件。

• Chaincode-Package-Metadata.json文件长成下面这样。

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

一个demo如下。2个组织不需要使用相同的名字。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tgtM5BdB-1582029897382)(…/images/posts/fabric/Lifecycle-package.png)]

1.1.1.2 安装链码

每个节点上都需要安装。强烈建议每个组织只打包一次链码，然后把该链码安装在该组织的所有节点上。如果一个channel想要保证所有的组织运行相同的链码，那么打包命令应该由一个组织来进行。

安装成功后会返回*MYCC_1:hash.*这样的格式，我们需要进行保存，方便后面的使用，如果忘记了，可以进行查询。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d2cqLO8D-1582029897383)(…/images/posts/fabric/Lifecycle-install.png)]

1.1.1.3 同意链码的定义

我的理解是，在上面，每个组织都给chaincode起了一个名字，这样，在实际中是无法使用的，所以现在大家来投票来确定一个统一的名字，包含下面的参数：

• 名字
• 版本：chaincode打包的时候生成的。
• Sequence：用来追踪链码的升级过程。是自增的。
• 背书策略：哪些组织可以执行可以验证交易。
• **Collection Configuration:**私有数据相关。
• Initialization：原来chaincode的默认的init函数不执行，现在可以了。
• ESCC/VSCC Plugins

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QjcOOW7T-1582029897383)(…/images/posts/fabric/Lifecycle-approve.png)]

1.1.1.4 提交链码的定义

一旦得到了绝大多数成员的同意，就可以提交链码的定义了。

我们可以使用checkcommitreadiness命令来检查是否已经有链码的定义了，首先会发送给所有的peer节点，在发送给order节点。提交必须是组织的管理员来完成的。

Channel/Application/LifecycleEndorsement来管理认可的组织的数量，默认是大多数。LifecycleEndorsement和chaincode的背书策略是分离的，没有任何关系的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u1wIoDGz-1582029897384)(…/images/posts/fabric/Lifecycle-commit.png)]

即使一个组织没有安装链码，仍然可以响应链码的定义。

当链码的定义被确认后，将会在所有安装链码的节点上启动链码容器。如果我们在定义链码的时候要求使用init函数，那么init函数将会被调用。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KSkVwjYw-1582029897384)(…/images/posts/fabric/Lifecycle-start.png)]

1.1.2 链码的升级

升级和安装类似，我们既可以升级链码的内容，还可以升级链码的背书策略。

1. 打包链码。只有在升级链码内容的时候需要。

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pN4ACywl-1582029897386)(…/images/posts/fabric/Lifecycle-upgrade-package-20200217233850395.png)]

2. 安装新链码。同上。

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UN0fCSd6-1582029897387)(…/images/posts/fabric/Lifecycle-upgrade-install.png)]

3. 链码定义投票。sequence将会自增1。

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wntCVO9Q-1582029897388)(…/images/posts/fabric/Lifecycle-upgrade-approve-20200218163958279.png)]

4. 提交定义。

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wZPOieSz-1582029897388)(…/images/posts/fabric/Lifecycle-upgrade-commit.png)]

将会启动新的链码容器。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IU1hSe4v-1582029897389)(…/images/posts/fabric/Lifecycle-upgrade-start.png)]

1.1.3 完整的demo

下面是chaincode的比较完整的操作。来自fabric-samples。

## at first we package the chaincode
packageChaincode 1

## Install chaincode on peer0.org1 and peer0.org2
echo "Installing chaincode on peer0.org1..."
installChaincode 1
echo "Install chaincode on peer0.org2..."
installChaincode 2

## query whether the chaincode is installed
queryInstalled 1

## approve the definition for org1
approveForMyOrg 1

## check whether the chaincode definition is ready to be committed
## expect org1 to have approved and org2 not to
checkCommitReadiness 1 "\"Org1MSP\": true" "\"Org2MSP\": false"
checkCommitReadiness 2 "\"Org1MSP\": true" "\"Org2MSP\": false"

## now approve also for org2
approveForMyOrg 2

## check whether the chaincode definition is ready to be committed
## expect them