智能合约和链码

智能合约和链码

**目标读者：**架构师、开发者、管理员

从应用程序开发人员的角度来看，智能合同和账本构成了Hyperledger Fabric区块链系统的核心。分类账保存一组业务对象的当前和历史状态的事实，而智能契约定义可执行逻辑，该逻辑生成添加到分类账的新事实。链码通常由管理员用于对相关的智能协议进行分组以进行部署，但也可以用于Fabric的低级系统编程。在本主题中，我们将关注为什么智能契约和链码存在，以及如何和何时使用它们。

在本主题中，我们将涉及:

• 什么是智能合约

• 术语说明

• 智能合同和账本

• 如何发展智能合约

• 背书政策的重要性

• 有效的交易

• 频道和链码定义

• 智能合约之间的沟通

• 什么是系统链码?

智能合约

在企业之间进行交易之前，它们必须定义一组公共契约，涵盖公共术语、数据、规则、概念定义和流程。综合起来，这些契约列出了管理交易各方之间所有交互的业务模型。

智能契约在可执行代码中定义不同组织之间的规则。应用程序调用智能合同来生成记录在分类账上的交易。

使用区块链网络，我们可以将这些合同转化为可执行程序——在业界被称为智能合同——来开辟各种各样的新可能性。这是因为智能契约可以为任何类型的业务对象实现治理规则，以便在执行智能契约时自动执行这些规则。例如，一个聪明的合同可以确保在指定的时间框架内交付一辆新车，或者根据预先安排的条款释放资金，分别改善货物或资本的流动。然而，最重要的是，智能契约的执行要比人工业务流程高效得多。

在上面的图中，我们可以看到两个组织，ORG1和ORG2如何定义一个汽车智能契约来查询、转移和更新汽车。来自这些组织的应用程序调用此智能契约来执行业务流程中商定的步骤，例如将特定汽车的所有权从ORG1转移到ORG2。

术语

Hyperledger 用户经常交替使用智能合同和链码这两个术语。通常，智能契约定义了控制世界状态中包含的业务对象生命周期的事务逻辑。然后，它被打包成一个链码，然后部署到一个区块链网络。可以把智能契约看作是管理事务，而链式代码则管理如何打包智能契约以进行部署。

智能合同是在链码中定义的。可以在同一个链码内定义多个智能合同。当一个链码被部署时，其中的所有智能合同都可以被应用程序使用

在图中，我们可以看到一个包含三个智能契约的车辆链码:汽车、船和卡车。我们还可以看到一个包含四种智能合同的保险链代码:保单、责任、银团和证券化。在这两种情况下，这些合同都涵盖了与车辆和保险相关的业务流程的关键方面。在本主题中，我们将以汽车合同为例。我们可以看到，智能契约是与特定业务流程相关的领域特定程序，而链码是一组相关智能契约的技术容器。

账本

在最简单的层次上，区块链不变地记录更新分类帐状态的交易。智能分类帐的合同以编程方式访问两个不同的部分——一个区块链,永恒地记录所有交易的历史,和一个世界状态,这些状态的当前值的缓存,因为它的当前值是一个对象,通常是必需的。

智能契约主要在世界状态中放入、获取和删除状态，还可以查询不可变的区块链交易记录。

get通常表示检索有关业务对象当前状态的信息的查询。

put通常在分类器世界状态中创建一个新的业务对象或修改一个现有的业务对象。

delete 通常表示从分类账的当前状态中删除业务对象，而不是从其历史记录中删除。

智能合约有许多可用的api。关键的是，在所有情况下，无论事务在世界状态下创建、读取、更新或删除业务对象，区块链都包含这些更改的不可变记录。

开发

智能契约是应用程序开发的重点，正如我们所见，一个或多个智能契约可以在单个链码中定义。在网络上部署链码，可以使网络中的组织机构获得所有智能合同。这意味着只有管理员需要担心链码;其他人都可以从智能合同的角度来思考。

智能契约的核心是一组事务定义。例如，看看这里的fabcard .js，你可以看到一个智能合同交易，创造了一辆新车:

async createCar(ctx, carNumber, make, model, color, owner) {

    const car = {
        color,
        docType: 'car',
        make,
        model,
        owner,
    };

    await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));
}

您可以在编写第一个应用程序教程中了解有关Fabcar智能合同的更多信息。

智能契约可以描述与多组织决策中数据的不变性相关的几乎无穷无尽的业务用例。智能合同开发人员的工作是采用可能控制财务价格或交付条件的现有业务流程，并用编程语言(如JavaScript、GOLANG或Java)将其表达为智能合同。将数百年的法律语言转化为编程语言所需要的法律和技术技能，正越来越多地被聪明的合同审计员运用。您可以在开发应用程序主题中了解如何设计和开发智能契约。

背书

与每个链码相关联的是一个背书策略，它适用于其中定义的所有智能合同。背书政策非常重要;它指示区块链网络中的哪些组织必须签署由给定智能契约生成的事务，以便声明该事务有效。

每个智能合同都有一个相关的背书策略。此背书策略确定哪些组织必须批准智能合同生成的交易，然后才能将这些交易识别为有效的。

一个背书策略示例可以定义参与区块链网络的四个组织中的三个必须对一个事务进行签名，才能认为该事务是有效的。所有的事务，无论有效或无效，都被添加到一个分布式分类帐，但只有有效的事务更新世界状态。

如果背书策略指定必须有多个组织签署交易，那么智能合同必须由足够多的组织执行，以便生成有效的交易。在上面的示例中，一个转移汽车的智能合同交易需要由ORG1和ORG2执行和签署，这样才能使其有效。

背书政策使得超级账本的结构有别于其他区块链，如以太坊或比特币。在这些系统中，网络中的任何节点都可以生成有效的事务。超分类织物更真实地模拟现实世界;事务必须由网络中受信任的组织进行验证。例如，政府机构必须签署一份有效的证件交易，或者汽车的买卖双方必须签署一份汽车转让交易。背书政策的设计是为了让Hyperledger Fabric更好地模拟这些真实世界的互动类型。

最后，背书策略只是Hyperledger结构中策略的一个例子。可以定义其他策略来确定谁可以查询或更新分类账，或者从网络中添加或删除参与者。一般来说，策略应该事先由区块链网络中的组织联盟商定，尽管它们不是一成不变的。实际上，策略本身可以定义可以修改它们的规则。尽管这是一个高级主题，但是也可以在Fabric提供的规则之上定义自定义背书策略规则。

有效的交易

当智能契约执行时，它运行在区块链网络中某个组织拥有的对等节点上。契约接受一组称为交易建议的输入参数，并将它们与程序逻辑结合使用来读写分类账。对世界状态的更改被捕获为事务建议响应(或仅仅是事务响应)，其中包含一个读写集，包含已读状态和如果事务有效将写入的新状态。注意，在执行智能契约时，世界状态没有更新!

所有事务都有一个标识符、一个建议和一个由一组组织签名的响应。所有的事务都记录在区块链上，无论有效或无效，但是只有有效的事务才构成世界状态。

检查汽车转让交易。您可以看到在ORG1和ORG2之间进行汽车传输的事务t3。查看事务如何具有输入{CAR1, ORG1, ORG2}和输出{CAR1。老板= ORG1 CAR1。owner=ORG2}，表示owner从ORG1更改为ORG2。请注意输入是如何由应用程序的组织ORG1签名的，输出是如何由背书策略标识的组织ORG1和ORG2签名的。这些签名是通过使用每个参与者的私钥生成的，这意味着网络中的任何人都可以验证网络中的所有参与者在交易细节上是一致的。

分配给网络中所有对等节点的事务由每个对等节点分两个阶段进行验证。首先，根据背书策略对交易进行检查，以确保交易已由足够的机构签署。其次，检查世界状态的当前值是否与认可对等节点签名事务的读集匹配;没有中间更新。如果事务通过了这两个测试，则将其标记为有效。所有事务都被添加到区块链历史记录中，无论有效或无效，但只有有效事务才会导致对世界状态的更新。

在我们的示例中，t3是一个有效的事务，因此CAR1的所有者已被更新为ORG2。然而，t4(未显示)是一个无效的事务，因此当它记录在分类帐中时，世界状态没有更新，CAR2仍然属于ORG2。

最后，要了解如何使用带有世界状态的智能契约或链码，请阅读链码名称空间主题。

通道

Hyperledger Fabric允许一个组织同时通过渠道参与多个独立的区块链网络。通过加入多个渠道，一个组织可以参与所谓的网络中的网络。通道在维护数据和通信隐私的同时提供了基础设施的有效共享。它们足够独立，可以帮助组织分离与不同对手方的工作流量，但也足够集成，可以在必要时协调独立的活动。

​ 通道在一组组织之间提供了完全独立的通信机制。当将链码定义提交到通道时，该链码内的所有智能契约对该通道上的应用程序可用。

当智能合约码安装在组织对等的链码包中时，渠道成员只能在定义链码后执行智能合约。链码定义是包含控制链码操作方式的参数的结构。这些参数包括链码名称、版本和背书策略。每个渠道成员通过批准其组织的链码定义来同意链码的参数。当足够多的组织(默认情况下是大多数)批准了相同的链码定义时，就可以将该定义提交到通道中。然后，根据链码定义中指定的背书政策，渠道成员可以执行链码内的智能合同。签注政策同样适用于同一链码内定义的所有智能合同。

在上面的示例中，在车辆通道上定义了汽车合同，在保险通道上定义了保险合同。car的链码定义指定了一种背书策略，要求ORG1和ORG2在交易被认为有效之前签署交易。保险合同的连锁码定义规定，只需要ORG3就可以批准交易。ORG1参与两个网络，车辆渠道和保险网络，并可以协调ORG2和ORG3跨这两个网络的活动。

链码定义为渠道成员在开始使用智能契约在渠道上进行交易之前，就链码的治理达成一致意见提供了一种方法。基于上面的示例，ORG1和ORG2都希望支持调用car契约的事务。因为默认策略要求大多数组织批准链码定义，所以两个组织都需要批准和{ORG1,ORG2}的背书策略。否则，ORG1和ORG2将批准不同的链码定义，从而无法将链码定义提交给通道。这个过程保证了car smart合同中的交易需要得到两个组织的批准。

内部通信

​ 智能契约可以在同一通道内或跨不同通道调用其他智能契约。通过这种方式，他们可以读写世界状态数据，而由于智能契约名称空间，他们无法访问这些数据。

这种契约间通信有一些限制，这些限制在链码命名空间主题中有完整的描述。

系统链码

在链码中定义的智能契约对一组区块链组织之间达成一致的业务流程的域相关规则进行编码。然而，链码也可以定义底层的程序代码，它对应于领域独立的系统交互，与这些业务流程的智能契约无关。

以下是不同类型的系统链码及其相关缩写:

• _lifecycle运行在所有的对等节点中，并管理链码在对等节点上的安装、组织对链码定义的批准以及向通道提交链码定义。你可以阅读更多关于_lifecycle如何实现Fabric chaincode生命周期过程的信息。

• 生命周期系统链码(LSCC)管理1的链码生命周期。织物释放。这个版本的生命周期要求在通道上实例化或升级链码。如果您将通道应用程序功能设置为V1_4_x或以下，您仍然可以使用LSCC来管理您的链码。

• 配置系统链码(CSCC)在所有对等点中运行，以处理对通道配置的更改，例如策略更新。你可以在下面的链码主题中了解更多关于这个过程的信息。

• 查询系统链码(QSCC)在所有节点上运行，提供分块查询、交易查询等分类api。您可以在事务上下文主题中阅读更多关于这些分类api的信息。

• 背书系统链码(ESCC)在背书对等点中运行，以密码方式签署交易响应。您可以阅读有关ESCC如何实现此过程的更多信息。

• 验证系统链码(VSCC)验证事务，包括检查背书策略和读写集版本控制。您可以阅读有关LSCC实现此过程的更多信息。

  底层的Fabric开发人员和管理员可以修改这些系统链代码以供自己使用。然而，系统链码的开发和管理是一项专门的活动，与智能合同的开发完全分开，通常是不必要的。对系统链码的更改必须极其小心地处理，因为它们对超分类账织物网络的正确运行至关重要。例如，如果系统链码没有正确开发，一个对等节点可能会以与另一个对等节点不同的方式更新其世界状态或区块链的副本。这种缺乏共识是账簿分叉的一种形式，是一种非常不可取的情况。

链码生命周期

什么是链码

链码是一个程序，用Go、Node编写。实现指定接口的Java。链码运行在一个安全的Docker容器中，与认证对等进程隔离。链码通过应用程序提交的事务来初始化和管理分类账状态。

链码通常处理网络成员同意的业务逻辑，因此它可以被视为“智能合同”。由链码创建的分类帐更新只局限于该链码，不能被另一个链码直接访问。但是，在同一个网络中，给定适当的权限，一个链码可以调用另一个链码来访问它的状态。

在这个概念主题中，我们将通过区块链网络运营商而不是应用程序开发人员的视角来研究链码。链码操作员可以利用这个主题来指导如何使用Fabric chainode生命周期来部署和管理他们的网络上的链码。

链码部署

Fabric链码生命周期是一个过程，它允许多个组织在链码在通道上使用之前就如何操作达成一致。网络操作员将使用Fabric生命周期执行以下任务:

• 安装和定义一个链码

• 升级chaincode

• 部署场景

• 迁移到新的Fabric生命周期

  您可以通过创建一个新通道并将通道功能设置为V2_0来使用Fabric链码生命周期。您将不能使用旧的生命周期在启用V2_0功能的通道上安装、实例化或更新链代码。但是，在启用V2_0功能之后，您仍然可以调用使用前面的生命周期模型安装的chaincode。如果您正在从v1.4升级。网络和需要编辑您的频道配置，以启用新的生命周期，检查启用新的链码生命周期。

安装和定义一个链码

Fabric链码生命周期要求组织同意定义链码的参数，例如名称、版本和链码背书策略。渠道成员通过以下四个步骤达成一致。并不是每个组织都需要完成每一步。

1. 打包链码:这一步可以由一个组织完成，也可以由每个组织完成。
2. 在你的对等节点上安装链码:每个使用链码支持交易或查询总账的组织都需要完成这一步。
3. 为您的组织批准链码定义:将使用链码的每个组织都需要完成此步骤。在链码可以在通道上启动之前，链码定义需要被足够多的组织批准，以满足通道的LifecycleEndorsment策略(默认情况下是大多数)。
4. 将链码定义提交到通道:一旦通道上所需的组织数量获得批准，提交事务就需要由一个组织提交。提交者首先从已经批准的足够多的组织同行中收集背书，然后提交事务以提交链码定义。

本主题提供对Fabric链代码生命周期操作的详细概述，而不是特定命令。要了解如何使用对等CLI使用Fabric生命周期的更多信息，请参阅向通道部署智能契约教程或对等生命周期命令参考资料。

第一步:包装智能合同

链码需要打包到一个tar文件中，然后才能安装到你的同龄人中。您可以使用Fabric对等二进制文件、Node Fabric SDK或第三方工具(如GNU tar)打包链代码。在创建链码包时，需要提供一个链码包标签，以创建对包的简洁和易于阅读的描述。

如果使用第三方工具打包链代码，结果文件需要采用以下格式。Fabric对等二进制文件和Fabric sdk将自动创建这种格式的文件。

该链码需要打包到一个tar文件中，以.tar.gz文件扩展名结尾。

tar文件需要包含两个文件(没有目录):一个元数据文件“Chaincode-Package-Metadata”。和另一个包含链码文件的tar。

“Chaincode-Package-Metadata。包含指定链码语言、代码路径和包标签的json。下面是一个元数据文件的例子:

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

链码分别由Org1和Org2打包。这两个组织都使用MYCC_1作为它们的包标签，以便使用名称和版本识别包。组织不需要使用相同的包装标签。

第二步:在你的对等节点身上安装链码

您需要在将执行和认可事务的每个对等点上安装链码包。无论使用CLI还是SDK，您都需要使用对等管理员来完成此步骤。您的同伴将在您的链码安装后构建链码，如果您的链码有问题，将返回一个构建错误。建议组织只打包一个链码一次，然后在属于他们组织的每一个节点上安装相同的包。如果一个通道想要确保每个组织运行相同的链码，一个组织可以打包一个链码并将其发送给其他的通道成员。

成功的安装命令将返回一个链码包标识符，它是包标签和包的散列组合在一起。此包标识符用于将安装在对等节点上的链码包与组织批准的链码定义关联起来。为下一步保存标识符。您还可以通过使用对等点CLI查询安装在对等点上的包来查找包标识符。

来自Org1和Org2的对等点管理员在连接到信道的对等点上安装链码包MYCC_1。安装链码包将构建链码并创建一个MYCC_1:hash的包标识符。

第三步:批准组织的链码定义

链码由链码定义控制。当通道成员批准一个链码定义时，该批准充当组织对其接受的链码参数的投票。这些已批准的组织定义允许通道成员在链码在通道上使用之前就其达成一致。链码定义包括以下参数，需要跨组织保持一致:

• **Name:**应用程序在调用链码时使用的名称。

• **版本:**与给定的链码包相关联的版本号或值。如果升级链码二进制文件，还需要更改链码版本。

• **序列:**定义链码的次数。该值是一个整数，用于跟踪链码升级。例如，当您第一次安装和批准一个链码定义时，序列号将为1。当你下次升级链码时，序列号将增加到2。

• **背书策略:**哪些组织需要执行和验证事务输出。背书策略可以表示为传递给CLI的字符串，也可以引用通道配置中的策略。默认情况下，背书策略设置为通道/应用程序/背书，默认情况下要求通道中的大多数组织背书一个事务。

• **集合配置:**与您的链码关联的私有数据集合定义文件的路径。有关私有数据收集的更多信息，请参见私有数据体系结构参考。

• **初始化:**所有的链码都需要包含一个初始化函数。默认情况下，这个函数永远不会执行。但是，您可以使用chaincode定义来请求Init函数是可调用的。如果请求执行Init, fabric将确保Init在任何其他函数之前被调用，并且只被调用一次。

• **ESCC/VSCC插件:**此链码使用的自定义背书或验证插件的名称。

  链码定义还包括包标识符。对于希望使用链码的每个组织来说，这是一个必需的参数。包ID不需要对所有组织都相同。组织可以批准链码定义，而无需安装链码包或在定义中包含标识符。

  希望使用链码的每个渠道成员都需要为其组织批准链码定义。此审批需要提交给订购服务，然后将其分发给所有对等点。此批准需要由您的组织管理员提交。在成功提交批准事务之后，已批准的定义存储在一个集合中，该集合对组织的所有同行可用。因此，即使您有多个对等点，您也只需要批准组织的链码一次。

来自Org1和Org2的组织管理员批准其组织的MYCC的链码定义。链码定义包括链码名称、版本和背书策略等字段。由于两个组织都将使用链码来支持事务，因此两个组织的已批准定义需要包括packageID。

第四步:将链码定义提交到通道

一旦有足够数量的通道成员批准了链码定义，组织就可以将定义提交给通道。您可以使用checkcommitreadiness命令来检查提交链码定义是否成功，这取决于哪些通道成员在使用对等CLI将定义提交到通道之前批准了该定义。提交事务建议首先被发送给渠道成员的同行，他们查询为他们的组织批准的链码定义，如果他们的组织批准了定义，他们就批准该定义。然后将事务提交给订购服务，后者将链码定义提交给通道。提交定义事务需要作为组织管理员提交。

在定义成功提交到通道之前，需要批准它的组织数量由通道/应用程序/生命周期背书策略控制。默认情况下，此策略要求通道中的大多数组织认可该事务。生命周期背书策略与链码背书策略是分开的。例如，即使一个链码背书策略只需要一个或两个组织的签名，大多数渠道成员仍然需要根据默认策略批准链码定义。当提交通道定义时，您需要以通道中足够多的对等组织为目标，以满足您的lifecycle背书策略。您可以在策略概念主题中了解有关Fabric链代码生命周期策略的更多信息。

您还可以将通道/应用程序/ lifecycle背书策略设置为签名策略，并显式地指定通道上能够批准链码定义的组织集。这允许您创建一个通道，其中一些组织充当链码管理员，并控制通道使用的业务逻辑。如果您的通道有大量Idemix组织，它们不能批准链码定义或批准链码，可能会导致通道无法达到大多数，那么您也可以使用签名策略。

来自Org1或Org2的组织管理员将链码定义提交到通道。通道上的定义不包括packageID。

组织可以批准链码定义而不需要安装链码包。如果一个组织不需要使用链码，他们可以批准一个没有包标识符的链码定义，以确保生命周期背书策略得到满足。

在将链码定义提交到通道之后，链码容器将在安装了链码的所有节点上启动，允许通道成员开始使用链码。链码容器启动可能需要几分钟时间。可以使用链代码定义来要求调用Init函数来初始化链代码。如果请求Init函数的调用，则链代码的第一个调用必须是对Init函数的调用。Init函数的调用遵循链码背书策略。

在通道上定义了MYCC之后，Org1和Org2就可以开始使用链码了。对每个对等点的链代码的第一次调用将启动该对等点上的链代码容器。

更新链码

你可以使用与安装和启动链条码相同的织物生命周期过程来升级链条码。您可以升级链码二进制文件，或者只更新链码策略。按照以下步骤升级链码:

1、重新打包链码:您只需要在升级链码二进制文件时完成此步骤。

Org1和Org2升级链码二进制文件并重新打包链码。两个组织使用不同的包装标签。

2、在您的对等节点上安装新的链码包:同样，您只需要在升级链码二进制文件时完成此步骤。安装新的链码包将生成一个包ID，您需要将其传递给新的链码定义。您还需要更改链码版本，生命周期进程使用该版本来跟踪链码二进制文件是否已经升级。

Org1和Org2在它们的对等节点上安装新包。安装将创建一个新的packageID。

3、批准新的链码定义:如果您正在升级链码二进制文件，您需要更新链码版本和链码定义中的包ID。您还可以更新您的链码背书政策，而不必重新包装您的链码二进制文件。通道成员只需要批准使用新策略的定义。新定义需要将定义中的序列变量增加1。

来自Org1和Org2的组织管理员为各自的组织批准新的链码定义。新的定义引用新的packageID并更改链码版本。由于这是链码的第一次更新，序列从1增加到2。

4、将定义提交给通道:当足够多的通道成员批准了新的链码定义时，一个组织可以提交新的定义来将链码定义升级到通道。生命周期过程中没有单独的upgrade命令。

来自Org1或Org2的组织管理员将新的链码定义提交到通道。

提交链代码定义之后，一个新的链代码容器将使用升级后的链代码二进制文件中的代码启动。如果请求在链码定义中执行Init函数，则需要在成功提交新定义后再次调用Init函数来初始化升级的链码。如果您更新了链码定义而没有更改链码版本，那么链码容器将保持不变，并且您不需要调用Init函数。

一旦新的定义提交给通道，每个对等点将自动启动新的链码容器。

Fabric链码生命周期使用链码定义中的序列来跟踪升级。所有通道成员需要增加序列号1，并批准一个新的定义，以升级链码。版本参数用于跟踪链码二进制文件，只有在升级链码二进制文件时才需要更改。

部署场景

下面的示例演示如何使用Fabric链代码生命周期来管理通道和链代码。

加入一个通道

新组织可以加入一个已经定义了链码的通道，并在安装链码包并批准已提交给通道的链码定义后开始使用链码。

Org3加入通道并批准之前由Org1和Org2提交给通道的相同的链码定义。

批准链码定义后，新组织可以开始使用链码后，软件包已安装到他们的同行。不需要再次提交定义。如果将背书策略设置为默认策略，要求大多数渠道成员背书，那么背书策略将自动更新以包括新组织。

链代码容器将在第一次调用Org3对等点上的链代码之后启动。

更新部署政策

您可以使用链码定义来更新背书策略，而无需重新包装或重新安装链码。通道成员可以使用新的背书策略批准链码定义，并将其提交给通道。

Org1、Org2和Org3批准一个新的背书策略，要求这三个组织都批准一个事务。它们将定义序列从1增加到2，但不需要更新链码版本。

新的背书策略将在新定义提交到通道后生效。通道成员不必通过调用链码或执行Init函数来重新启动链码容器来更新背书策略。

一个组织向通道提交新的链码定义以更新背书策略。

批准定义而不安装链码

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

Org3没有安装链码包。因此，它们不需要提供packageID作为链代码定义的一部分。然而，Org3仍然可以认可已提交给通道的MYCC的定义。

一个组织不同意链码的定义

不批准已提交给信道的链码定义的组织不能使用链码。没有批准链码定义或批准了不同链码定义的组织将不能在其同行上执行链码。

Org3使用与Org1和Org2不同的背书策略批准链码定义。因此，Org3不能在通道上使用MYCC链码。然而，Org1或Org2仍然可以获得足够的背书来将定义提交给通道并使用链码。来自链码的交易仍将添加到总账并存储在Org3对等端。然而，Org3将不能认可事务。

组织可以批准任何序列号或版本的新链码定义。这允许您批准已提交给通道的定义，并开始使用链码。您还可以批准一个新的链码定义，以纠正在批准或包装链码过程中所犯的错误。

通道不同意链码定义

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

Org1、Org2和Org3都批准不同的链码定义。因此，没有任何一个频道成员能够获得足够的背书来将链码定义提交给该频道。任何频道成员将不能使用该链码。

组织安装不同的链码包

每个组织在批准链码定义时可以使用不同的packageID。这允许通道成员安装不同的链码二进制文件，使用相同的背书策略，读写相同的链码名称空间中的数据。

组织可以使用此功能来安装包含特定于其组织的业务逻辑的智能契约。每个组织的智能契约可以包含组织在其同行认可交易之前需要的额外验证。每个组织还可以编写代码，帮助智能契约与来自其现有系统的数据进行集成。

Org1和Org2各自安装了包含特定于其组织的业务逻辑的MYCC链码版本。

使用一个包创建多个链码

通过批准和提交多个链码定义，可以使用一个链码包在通道上创建多个链码实例。每个定义需要指定不同的链码名称。这允许您在一个通道上运行智能合同的多个实例，但是让合同受不同的背书策略控制。

Org1和Org2使用MYCC_1链码包来批准和提交两个不同的链码定义。结果，两个节点都有两个链代码容器在它们的节点上运行。MYCC1的背书策略为1 / 2，而MYCC2的背书策略为2 / 2。

迁移到新的Fabric生命周期

有关迁移到新的生命周期的信息，请参阅到达v2.0的注意事项。

如果您需要更新您的通道配置来启用新的生命周期，请查看启用新的链码生命周期。

更多的信息

你可以观看下面的视频来了解更多关于新的织物链代码生命周期的动机以及它是如何实现的。

来源：oschina

链接：https://my.oschina.net/u/2277392/blog/4353733