give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: h3. Introduction  The current deployment model has the following properties with regards to chaincode code (as opposed to chaincode data)  * the code is deployed on a per-channel basis  * the code is stored on the ledger for the channel    There are a few issues with the model  # the deploy transaction is large and has performance issues  # a chaincode redeployed on different channels results in different instances of the container which could put a strain on infrastructure when this duplication becomes prevalent  # by virtue of the code being on the ledger, all peers in the chain have access to the chaincode. There is no mechanism to run a chaincode on a subset of peers - for example, only on those that are endorsers of this chaincode.    While (3) may sound like a good idea, in most cases it does not make sense (in a "Car" blockchain a Registration-Chaincode may belong to both DMV and Insurance but not to Dealership, while a CarAsset-Chaincode may run on all peers).    This proposal is to change the deploy semantics to _install_ on a peer instead of on a channel but at the same time _invoke_ the chaincode in the context of a channel (akin to program code being allocated once in memory once but data section for many processes that are launched for that program).    This will result in greater flexibility  * given a channel a chaincode can be deployed to a subset of the peers on the channel  * reduce load on the infrastructure to run multiple instances of the chaincode for different channels  * reduce communication overhead due to large chaincode binaries     The only downside is we will lose the ability to do "one-shot" deployment of a chaincode onto all the peers in the channel. Given other benefits (and hopefully not being a common scenario) this is likely not a big detraction.    While this is a change to the "deploy" model, it has implications for upgrade as well.  Rest of the proposal deals with the details of deploy and upgrade.    h3. User level changes to deploy  * a new "install" command which installs the chaincode on the peer (basically puts the packaged chaincode on the file system)  and not on the channel  ** {{peer chaincode install -n <chaincode id> -v <version> -p <path to chaincode>}}  * an new instantiate command to associate the chaincode with a channel  ** {{peer chaincode instantiate -C <channel id> -n <chaincode id> -v <version> -p <path to chaincode> -c <init args>}}    +High level implementation and design details to deploy+  * chaincode code is not stored on the chain ledger but on the peer (say on the filesystem)  * The instantiate command will also update the LCCC for that chain. The command will also run the "Init"    function of the chaincode on a given chain.   * The LCCC entry for the chaincode on a channel will contain the hash of the chaincode in addition    to other fields such as name and location of the chaincode. This will be used to detect changes    h3. Upgrade  Notation  * channels are x, y, z  * peers are P1, P2, P3  * chaincode is mycc  * hashcode of version 1 chaincode mycc is h1-mycc    Hence, *mycc:h1-mycc/x* refers to version *h1-mycc* of chaincode *mycc* on channel *x*.    Version rule - multiple channels can run different versions of a chaincode but given a channel only one version of a chaincode can be running on it at any given time. ie,  # mycc:h1-mycc/x and mycc:h1-mycc/y - same version of a chaincode, different channels - OK  # mycc:h1-mycc/x and mycc:h2-mycc/y - 2 versions of a chaincode, different channels - OK  # mycc:h1-mycc/x and mycc:h2-mycc/x - 2 versions of a chaincode on one channel - NOT OK    Peer constraint that follows from above (as a channel encompasses many peers)  * If P1 successfully initiates upgrades to a new version on channel *x*, all other Peers have to upgrade for successful invocation of the chaincode. We will be implicitly violating 3 above.    There will be two commands related to upgrade  * {{peer chaincode install -n mycc -p <path to mycc with version hash1-mycc>}} - this will put the chaincode on the peer's filesystem.   ** this command will fail if that version exists on the filesystem  ** note that this command does not involve ledger or channel in any manner  * {{peer chaincode upgrade -C x -n mycc -p <path to mycc with version hashn-mycc> -c <init args>}}  - this will upgrade the channel  ** this command will fail if that chaincode does not exist on the filesystem  ** this command will fail if the chaincode has not been instantiated on the channel  ** this command will fail if the running version matches the upgrading version for the channel  ** on successful commit this will update LCCC for the channel to *mycc:hashn-mycc*      {code:java}  Note on the effect of upgrade on inflight transactions    The scenario - many proposals are happening on the chaincode on channel x at the time of upgrade of a chaincode. Some of them end up as transactions before the block on which upgrade turns up, others after and a few on the same block.    For consistency and determinism, enforcing the following rules will be sufficient       - invokes will be stamped not only with chainID but also version. This will thus be part of the MVCC rw-set      - at commit time, all transactions for the *mycc:--/x*  will be invalidated on the block on which there's an upgrade (they had to be on the previous version of the chaincode)      - at commit time, all transactions for the *mycc:<prev hash>/x* on previous block will follow normal processing.      - at commit time, all transactions for the *mycc:<prev hash>/x* will naturally fail MVCC validation on succeeding blocks    Note that successful commit of *mycc:hashn-mycc/x* on P1 will not bring down other *mycc:--/x* running on P1 as these may be still running on other channels. See next section on *Stop chaincode*    {code}     h3. Stop chaincode    As noted in the previous section, chaincodes may still be running and deployed even if not in use in any channels. Rather than do GC of some sort, we will provide a {{peer chaincode stop [ --destroy ]}} command to stop the chaincode and optionally remove it from the filesystem. Symmetrical to "deploy" command, these do not involve channels or ledger but simply will remove them from system. A "deploy" will put the chaincode back on the filesystem.    h3. User Scenarios  +I want to install a chaincode to a set of peers+  This is the standard happy path for deploying chaincode. Basically log into each peer and install the chaincode    +I want to first install a chaincode to a set of peers and then instantiate the chaincode on different channels A, B and C+ (instantiation can only be done on the peers the chaincode is deployed upon)  This is the standard happy path for instantiating a chaincode on channels    +I want to install a chaincode on another Peer 2 after it has been instantiated on the channel by Peer 1+  Install is independent of the channels. The instantiation of the chaincode on a channel will have no effect on the deployment on a Peer 2. The chaincode is inaccessible on Peer2 till it has be been installed on it.    +I want to reinstantiate a chaincode on a channel (say from a different peer which instantiated the chaincode)+  This should fail as a chaincode cannot be reinstantiated on a channel (the LCCC for the channel will have  a chaincode entry)    +I want to invoke a chaincode on a channel on Peer2 when it was instantiated on the channel by Peer1+  It will fail if it was not installed on Peer2.  It will fail if the invoke causes the chaincode to be brought up but the hash does not match what's on the LCCC.    +I want to install *mycc:hash1-mycc* on P1  It will fail if  *mycc:hash1-mycc* exists on P1    +I want to upgrade to *mycc:hash2-mycc/x* via P1  This will fail if   ** chaincode mycc is not running on x  ** *hash2-mycc* version of chaincode not deployed on P1  ** current version same as hash2-mycc    NOTE: we will add other scenarios  
Answer: 1244500.0