chaincode_lifecycle

发表于

先附上一张早上刚刚“新鲜出炉”的chaincode生命周期的流程图，欢迎指教；

img


四种声明周期

Chaincode 的生命周期有四种：package、install、instantiate、upgrade

Package

    • CDS根据代码和其他属性（名字和版本）定义chaincode包

    • 实例化政策能在endorsement政策中描述

    • 拥有chaincode的实体进行签名

      • 签名目的：建立chaincode的所有者、验证包的内容，防止被篡改

    • Create package

      • 两种方法：

        • 一种是我们希望该chaincode有多个owner，因此需要创建一个可以被前面的chaincode包（signerCDS），然后按顺序地被每个owner签名；
        • 另一种则是仅部署具有发出安装事物的结点签名的signedCDS

      • signerCDS包含3个元素

        • 源码，名字和版本（即CDS）
        • 实例化策略
        • chaincode的所有者，由endorsement定义


Install

  • 安装事务将源码组装成CDS的格式，然后install到运行该chaincode的结点上；
  • 只有chaincode的拥有者拥有的结点能执行chaincode，其它的结点可以验证和提交；
  • 安装chaincode的时候，会发送一个signer protocol到lifecycle system chaincode（LSCC）；


Instantiate

  • 实例化事务通过调用LSCC来创建和实例化一个chaincode到channel上；
  • chaincode可以安装到多个channel上，它们相互之间是独立的；
  • 默认的实例化策略：链码实例化事物的创建者必须是channel管理员的成员；
  • 实例化事物的创建者必须满足signedCDS中的实例化策略，并且还是channel的writer；否则，会有可能出现恶意实体部署chaincode到未绑定的channel上或者欺骗成员在未绑定的channel上执行链码；
  • transaction到达endorser时，endorser根据实例化策略来验证创建者的签名；在提交大账本前，也会再做一次验证；
  • 实例化事物也会设立一个endorsement policy，这个策略用来被channel其它成员去接受，认可；


经过上述三个周期，chaincode进入活跃状态；


upgrade

  • chaincode名必须要一样；
  • 新的chaincode在安装、实例化到一个channel上时，其它绑定了旧的chaincode仍然运行旧的版本；
  • （旧的版本与新的版本可能共存，所以需要我们手动删除）
  • 与实例化事物不一样，检查upgrade事务是根据当前chaincode的实例化策略，而不是新的策略，这是为了保证只有当前chaincode实例化策略的成员才能upgrade

关于stop与start

据说新版本会推出stop与start两种生命周期的管理，拭目以待；

  • 没有停止和启动生命周期

    • 只能从每个endorser中删除signedCDS，然后从承载对等节点运行的主机或者虚拟机里删除chaincode的容器