Yuhan's BlogFabric 链码生命周期
链码是一个程序，用GO、Node.js 或者 Java 的指定接口的实现。
链码运行在一个安全的 Docker 容器中，与背书节点进程相隔离。
链码通过应用程序提交的事务来初始化和管理账本状态。
Fabric链码生命周期要求组织同意定义链码的参数，例如名称、版本和链码背书策略。渠道成员通过以下四个步骤达成一致。并不是每个组织都需要完成每一步。
-
打包链码：可以由一个组织或每个组织完成此步骤。
-
在对等节点上安装链码：每个将使用链码来认可交易或查询帐本的组织都需要完成此步骤。
-
批准组织的链码定义：每个将使用链码的组织都需要完成此步骤。 链码定义需要得到足够多的组织的批准，才能满足该频道的LifecycleEndorsment策略（默认情况），然后才能在该频道上启动链码。
-
将链码定义提交到通道：一旦渠道上所需数量的组织批准了该链码定义，就需要由一个组织提交。 提交者首先从已经批准的组织的足够的对等节点那里收集背书，然后提交交易以提交链码的定义。
链码需要打包到一个tar文件中，然后才能安装到对等节点中。
可以使用 Fabric peer 命令、Node Fabric SDK 或第三方工具如 GNU tar（第三方工具打包需满足预定的格式，而 Fabric 提供的工具自动完成） 进行打包，打包时需要提供链码包标签以简明地描述该包。
如图，链码分别由Org1和Org2打包。这两个组织都使用MYCC 1作为他们的包标签，以便使用名称和版本识别包。组织不需要使用相同的包标签。
需要在将执行交易和交易背书的每个对等节点上安装链码包。
无论使用CLI还是SDK，都需要使用管理员身份来完成此步骤。
对等节点将在链码安装后构建链码，如果链码有问题，将返回一个构建错误。
成功的安装命令将返回一个链码包标识符，它是包标签与包的散列值的组合。
保存该标识符用于下一步，也可使用 peer 命令获取安装的所有包的标识符。
建议组织仅打包一次链码，然后在属于其组织的每个对等方上安装相同的软件包。 如果某个通道想要确保每个组织都运行相同的链码，则一个组织可以打包一个链码并将其发送到其他通道成员。
链码由链码定义控制。当一个通道的成员们核准一个链码定义的时候，该过程就像一个组织在其可接受的链码参数上的投票，批准后需要被管理员提交到订阅服务，此后将分布于所有对等节点中。链码定义包含了以下参数，需要得到组织间的一致同意。
Name、Version、Sequence、Endorsement Policy、Collection Configuration、ESCC/VSCC Plugins、Initialization
链码定义也包含包标识符。
一旦有足够数量的通道成员批准了链码定义，组织就可以将定义提交给通道。
可使用 checkcommitreadiness 的 peer 命令来检查提交的链码定义是否成功（是否有足够的成员批准了）。
管理员的提交交易请求首先发送到了通道成员的对等节点，它们背书之后才发送到订阅服务，然后才提交链码定义给通道。
多少成员批准了才是足够的？由 Channel/Application/LifecycleEndorsement 策略控制，该策略默认需要大量组织背书，该策略与链码背书策略是分开的，即使链码背书策略仅需要少量组织同意，它还是默认要大量组织同意。当然，策略是可以更改的。
组织可以批准链码定义而不需要安装链码包。如果一个组织不需要使用链码，他们可以批准一个没有包标识符的链码定义，以确保生命周期背书策略得到满足。
在将链码定义提交到通道之后，链码容器将在安装了链码的所有节点上启动，允许通道成员开始使用链码。链码容器启动可能需要几分钟时间。
