Chaincode Packaging and Signing

Introduction

A chaincode will be placed on the file system of the peer on installation simply as a file with name <chaincode name>.<chaincode version. The contents of that file is called a chaincode package.

This document describes how a chaincode package can be created and signed from CLI. It also describes how the install command can be used to install the chaincode package.

What’s in the package ?

The package consists of 3 parts * the chaincode as defined by ChaincodeDeploymentSpec. This defines the code and other meta properties such as name and version * an instantiation policy which can be syntactically described by the same policy used for endorsement and described in endorsement-policies.rst * a set of signatures by the entities that “own” the chaincode.

The signatures serve the following purposes * establish an ownership of the chaincode * allows verification that the signatures are over the same content * allows detection of package tampering

The creator of the instantiation of the chaincode on a channel is validated against the instantiation policy of the chaincode.

Chaincode Packaging

The package is created and signed using the command

peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out

where -s specifies creating the package as opposed to generating raw ChaincodeDeploymentSpec -S specifies instructs to sign the package using the Local MSP (as defined by localMspid property in core.yaml)

The -S option is optional. However if a package is created without a signature, it cannot be signed by any other owner using the signpackage command in the next section.

The -i option is optional. It allows specifying an instantiation policy for the chaincode. The instantiation policy has the same format as an endorsement policy and specifies who can instantiate the chaincode. In the example above, only the admin of OrgA is allowed to instantiate the chaincode. If no policy is provided, the default policy is used, which only allows the admin of the peer’s MSP to instantiate chaincode.

Package signing

A package can be handed over to other owners for inspection and signing. The workflow supports out of band signing of package.

A previously created package can be signed using the command

peer chaincode signpackage ccpack.out signedccpack.out

where ccpack.out and signedccpack.out are input and output packages respectively. signedccpack.out contains an additional signature over the package signed using the Local MSP.

Installing the package

The package can be installed using the install command as follows

peer chaincode install ccpack.out

where ccpack.out is a package filecreated using the package or signedpackage commands.

Conclusion

The peer will support use of both raw ChaincodeDeploymentSpec and the package structure described in this document. This will allow existing commands and workflows to work which is especially useful in development and test phases.