// SignedChaincodeDeploymentSpec carries the CDS along with endorsements

message SignedChaincodeDeploymentSpec {

	// This is the bytes of the ChaincodeDeploymentSpec

	bytes chaincode_deployment_spec = 1;

	// This is the instantiation policy which is identical in structure

	// to endorsement policy.  This policy is checked by the VSCC at commit

	// time on the instantiation (all peers will get the same policy as it

	// will be part of the LSCC instantation record and will be part of the

	// hash as well)

	bytes instantiation_policy = 2;

	// The endorsements of the above deployment spec, the owner's signature over

	// chaincode_deployment_spec and Endorsement.endorser.

	repeated Endorsement owner_endorsements = 3;

}

// Specify the deployment of a chaincode.

// TODO: Define `codePackage`.

message ChaincodeDeploymentSpec {

    // Prevent removed tag re-use

    reserved 2;

    reserved "effective_date";

    enum ExecutionEnvironment {

        DOCKER = 0;

        SYSTEM = 1;

    }

    ChaincodeSpec chaincode_spec = 1;

    bytes code_package = 3;

    ExecutionEnvironment exec_env=  4;

}

// Carries the chaincode specification. This is the actual metadata required for

// defining a chaincode.

message ChaincodeSpec {

    enum Type {

        UNDEFINED = 0;

        GOLANG = 1;

        NODE = 2;

        CAR = 3;

        JAVA = 4;

    }

    Type type = 1;

    ChaincodeID chaincode_id = 2;

    ChaincodeInput input = 3;

    int32 timeout = 4;

}

// An endorsement is a signature of an endorser over a proposal response. By

// producing an endorsement message, an endorser implicitly "approves" that

// proposal response and the actions contained therein. When enough

// endorsements have been collected, a transaction can be generated out of a

// set of proposal responses. Note that this message only contains an identity

// and a signature but no signed payload. This is intentional because

// endorsements are supposed to be collected in a transaction, and they are all // expected to endorse a single proposal response/action (many endorsements

// over a single proposal response) 

message Endorsement {

 // Identity of the endorser (e.g. its certificate)

 bytes endorser = 1;

// Signature of the payload included in ProposalResponse concatenated with

 // the endorser's certificate; ie, sign(ProposalResponse.payload + endorser)

bytes signature = 2;

}

// sign the concatenation of cds, instpolicy and the serialized endorser identity with this endorser's key

 signature, err := owner.Sign(append(cdsbytes, append(instpolicybytes, endorser...)...))

// each owner starts off the endorsements with one element. All such endorsed
// packages will be collected in a final package by CreateSignedCCDepSpecForInstall
// when endorsements will have all the entries

endorsements = make([]*peer.Endorsement, 1)
endorsements[0] = &peer.Endorsement{Signature: signature, Endorser: endorser}

Package the specified chaincode into a deployment spec.

Usage:

  peer chaincode package [flags]

Flags:

  -s, --cc-package                  create CC deployment spec for owner endorsements instead of raw CC deployment spec

  -c, --ctor string                 Constructor message for the chaincode in JSON format (default "{}")

  -i, --instantiate-policy string   instantiation policy for the chaincode

  -l, --lang string                 Language the chaincode is written in (default "golang")

  -n, --name string                 Name of the chaincode

  -p, --path string                 Path to chaincode

  -S, --sign                        if creating CC deployment spec package for owner endorsements, also sign it with local MSP

  -v, --version string              Version of the chaincode specified in install/instantiate/upgrade commands 

#这是用 -i 指定了一个实例化策略，创建一个名为 ccpack.out的包
peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/example02/cmd -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out

The optional -i option allows one to specify an instantiation policy for the chaincode. The instantiation policy has the same format as an endorsement policy 
and specifies which identities 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 identity of the peer’s MSP to instantiate chaincode.

#org1  
peer chaincode signpackage ccpack.out signedccpack.out
#org2

peer chaincode signpackage signedccpack.out signedccpack2.out

Note that this endorsement policy is determined out-of-band to provide proper MSP principals when the chaincode is instantiated on some channels.
 If the instantiation policy is not specified, the default policy is any MSP administrator of the channel.

the default instantiation policy allows any of the channel MSP admins to be able to instantiate

#直接指定源码路径安装

peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/example02/cmd 

#安装chaicode package

peer chaincode install ccpack.out

#用 -P 指定了背书策略
peer  chaincode instantiate  -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR('Org1MSP.peer','Org2MSP.peer')"

There’s one subtle difference with the instantiate transaction: the upgrade transaction is checked against the current chaincode instantiation policy, not the new policy (if specified). 
This is to ensure that only existing members specified in the current instantiation policy may upgrade the chaincode.

// executeUpgrade implements the "upgrade" Invoke transaction.

 [executeUpgrade](https://github.com/hyperledger/fabric/blob/9e9ebe651225104823d228a09e94432592252ca3/core/scc/lscc/lscc.go#L540)(...) {
　　//cdLedger.InstantiationPolicy 当前chaincode的实例化策略
　　err = lscc.support.CheckInstantiationPolicy(signedProp, chainName, cdLedger.InstantiationPolicy)
   if err != nil {
      return nil, err
   }

.... ....

   //retain chaincode specific data and fill channel specific ones

     cdfs.Escc = string(escc)

     cdfs.Vscc = string(vscc)

   cdfs.Policy = policy

   **// retrieve and evaluate new instantiation policy**
　　//cdfs.InstantiationPolicy 新chaincode 的实例化策略

   cdfs.InstantiationPolicy, err = lscc.support.GetInstantiationPolicy(chainName, ccpackfs)

   if err != nil {

      return nil, err

   }
　　

// CheckInstantiationPolicy checks whether the supplied signed proposal
// complies with the supplied instantiation policy

   err = lscc.support.CheckInstantiationPolicy(signedProp, chainName, cdfs.InstantiationPolicy)

   if err != nil {

      return nil, err

   }

  …… ……

   return cdfs, nil

}

#安装新版本的chaincode，安装规则不变
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/example02/cmd
#更新智能合约
peer chaincode upgrade  -o orderer.example.com:7050  -n mycc -v 1.2 -c '{"Args":["init","a","100","b","200"]}' -P "AND('Org1MSP.peer','Org2MSP.peer')" -C mychannel

peer chaincode invoke -o orderer.example.com:7050 -C mychanel -n mycc -c '{"Args":["invoke","a","b","10"]}'