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: This document has been a product of discussion with [~<USER>, [~<USER>, [~adc], [~<USER>.      *Background& Motivation*:    A chaincode is fully described by    - User provided unique name   - User provided version (this is generally represented by a string)   - User provided code along with meta properties such as the language the code is implemented in  The ChaincodeDeploymentSpec (CDS) protobuf message is the formal definition of the above.    In 0.5 and 0.6 the chaincode we didn’t associate ownership with chaincode. We only needed a client with the right permissions to request its deployment, and once deployed, it could be accessed on any peer in the network. This process radically changes in 1.0, where the process of a chaincode being available within a chain (deployment) is executed in two phases:   - installation of the chaincode onto a peer    - instantiation of the chaincode onto channel(s)    We could treat the "install" simplistically as just putting the chaincodeDeploySpec (CDS) on the filesystem of the peer in a chaincode configuration directory.  Indeed this is really what the first implementation of the new deployment model as described in https://jira.hyperledger.org/browse/FAB-1783 did.     This separation of chaincode deployment into “install” and “instantiation” separates to some extent the roles of chaincode instantiator within a specific chain with the ownership of the corresponding chaincode's source code and ownership of the latter. These three properties were guaranteed to be possessed by the deployer of a chaincode in v0.6, i.e., anyone who had the right to deploy chaincodes would be required to post the entire code-base associated to that chaincode to the chain, and concurrently demonstrate that it is owning that piece of deployed code. On the contrary, with the new installation model these three properties are not necessarily meet in the face of a possible chainocode instantiator.    Therefore we are looking for a technique to package chaincodes with the new deployment model, such that:    - a chaincode instantiator can bind at instantiation time the instantiated chaincode to the code that is actually being executed, in a way that claims on the running code cannot be muted after the instantiation transaction is included in the ledger   - a chaincode instantiator can prove to the rest of the peers in the network that process the instantiation transaction that it is among the owners of that chaincode, and is therefore authorized to make that chaincode available to any chain.     The new installation model provides the opportunity to properly associate ownership of chaincodes as part of the “install” of the chaincode.  This document describes how additional information such as ownership can be packaged with the CDS so the package can be secured (non-instantiated but by properly authorized entities), and non-malleable (non-modifiable).    The rest of this doc goes over the details of the contents of the package and its implementation.        *1. Chaincode Installation*    Contents of the chaincode installation package:   - The package will consist of the following materials   - CDS (described above)    - List of owners of the chaincode, defined by means of certificates (essentially, msp.SerializedIdentity objects), and a list of signatures of theirs over chaincode source code that can be in the form of endorsements (peer.Endorsement)   - An instantiation policy of that chaincode expressed in the same way chaincode endorsement polices are expressed; notice that for this policy to be determined, an out-of-band communication between the owners of the chaincode is needed (e.g., to provide proper MSP principals for their part in the chain).   - Signature of the peer organisation admin (peer's MSP admin) installing this package over the above      _Implementation details_  We assume the chaincode package is stored on the filesystem with name <user provided CC name>.<user provided version>. In future we could store this on Database.      _Step 1_. A proposal of type ENDORSER_TRANSACTION will be sent to the endorser targeted to LCCC.    The input args to the LCCC would be {“install”, <package>}.  The package will have the following structure  * Envelope  * Payload  * Header  ** ChannelHeader with type PACKAGE (other fields in header will be nulled out as the package needs to be deterministic)  ** SignatureHeader nulled out as the package needs to be deterministic.   ** Data  *** ChaincodeDeploymentSpec (CDS) in bytes  *** Array of Endorsement (basically “owners” of this package) where Endorsement is a predefined type  (see proposal_response.proto)      {code:java}        message Endorsement {          bytes endorser = 1; ---> this will be the owner identity          bytes signature = 2; ---> sign (above CDS+above endorser)        }  {code}        _Step 2._ LCCC will validate the creator signature on the LCCC install proposal.     LCCC uses the peer’s local MSP to check if the proposal signature is valid given the creator, and the creator of the proposal is an administrator of peer’s local MSP.If this check fails, the proposal is rejected. If it succeeds, we continue to the next validation step.    _Step 3._ LCCC checks the timestamp in the proposal and rejects if outdated. [~<USER> propose we remove this per discussion in comments    _Step 4._ LCCC checks if a chaincode with the same identifier IDcc has already been installed by looking up the file <user provided name>.<user provided version>. If this is the case, LCCC rejects the new chaincode installation by returning an “Error: chaincode already installed” message to the invoker.     _Step 5._ LCCC retrieves the ChaincodeDeploymentSpec and Endorsement array. At this point, we need to decide what to do. One option would be that the LCCC checks if any of the endorsements in the array of endorsements, correspond to its local MSP admin, and reject if this such a signature is not detected. An other alternative is that we do not do any signature verification there, as there is already a peer MSP admin signature on the proposal (see comment).   If we decide there is some signature check that needs to take place, then we should have the endorser rejecting the proposal if this check fails. Otherwise, it continues to next step.      *2. Chaincode Instantiation*  An important component of securing is the generation of a unique identifier called IDcc derived from the contents of the package of the Chaincode. LCCC computes IDcc of the chaincode to be instantiated as follows:   - Computes the hash of the chaincode source code, let it be HCC   - Computes the hash of the chaincode metadata, consisting of        --> The list of owners of the chaincode to be installed OwnCC,       -->The chaincode name, NameCC       --> The chaincode version, VersionCC      --> The chaincode instantiation policy, PolicyCC     Let the resulting hash be, HMetaCC.  Use as chaincode identifier, let it be IDcc,  the hash of the concatenation of HCC,, and HMetaCC, i.e.,   IDcc <- HASH(HCC || HMetaCC),  where “||” indicates concatenation.    Let that chaincode is to be installed into a chain with identifier IDchain, and LCCC instance referred to by LCCCchain that is equipped with an chaincode instantiation policy P_lccc. We assume the instantiation of a chaincode with identifier IDcc. Notice that due to the way chaincode identifiers are generated, this identifier would be uniquely bound to the chaincode’s source code CC, list of ownership OwnCC, instantiation policy PolicyCC and other chaincode metadata, i.e., name and version.     LCCC for a channel  is assumed to maintain a database on instantiated chaincodes within chain with id ChainID, and their status (active, terminated). We will refer to this table by DBcc_chain.    _Step 1_. A proposal of type ENDORSER_TRANSACTION will be sent to the endorser targeted to LCCC.    The input args to the LCCC would be   {“instantiate”, chainID, NameCC, VersionCC, PolicyCC, ESCC, VSCC, “anything else?”}    _Step 2_. Endorser retrieves LCCCchain. In particular it checks that ChainID is an identifier of a chain it has joined, and retrieves its LCCC instance, i.e., LCCCchain.    _Step 3_. LCCCchain (on the endorser side) will check “Creator” and its proposal signature complies  with the read policy of chain with identifier chainID, and chaincode instantiation policy P_lccc. Namely it would invoke P_lccc.evaluate, using as parameters the Creator, the proposal payload, and Creator signature. This step, with proposal of [~<USER> is to be substituted with the following proccess:   ```LCCCchain checks that proposal creator, and proposal signature satisfy the PolicyCC listed above, i.e., they run PolicyCC.evaluate with these parameters```.    _Step 4_. LCCCchain looks up the package file <user provided chaincode name>.<user provided version> file and rejects if not found.    _Step 5_ LCCCchain checks if the chaincode has already been instantiated in this chain (under the same name???)  by looking up into DBcc_chain,  and rejects if this is the case.     _Step 6_. .LCCCchain computes IDCC and checks if the IDcc is correctly formed, i.e.,   It computes HMetaCC <- Hash(OwnCC||NameCC||PolicyCC||VersionCC)  It checks if IDcc == Hash(HCC || HMetaCC), and rejects if this is not the case    _Step 7_. LCCCchain, checks if Creator is within OwnCC, and rejects if this is not the case. This is an optional step according to the proposal by [~<USER>.    _Step 8_. Endorser produces from LCCCchain the simulation result of its execution (essentially,  DBcc_chain enhanced with an entry for the chaincode to be freshly instantiated)    _Step 9_. Endorser calls LCCCchain_escc to create an endorsement, that returns to “Creator”.    _Step 10_. Creator uses this endorsement to create a transaction that then submits to the channel with identifier ChainID; let that this transaction is referred to by TXcc_chain    _Step 11_. Orderers upon receiving TXcc_chain check that a channel with identifier “chainID” exists, retrieve the chain’s metadata (ConfigManager), and from them retrieve the chain’s Writers, say Wchain. They then ensure (as with all transactions) that:   - Creator and its signature on transaction satisfies Wchain   - Creator’s signature in transaction matches the creator’s identity    - Orderers order the transaction into a channel block that is then released to committing peers.    _Step 12_. Committing peers receive TXcc_chain as part of the channel with identifier "chainID". They then run LCCCchain_vscc, where LCCCchain_vscc would need to repeat steps 3-7, after which it would need to evaluate the RW set. If the RWset validation still holds as current, validates the transaction as valid, and applies LCCCchain state changes to ledger. This, after discussion with [~<USER>, and [~adc] may not be necessary if we define an endorsement policy for LCCC at channel genesis time.     Note: Optionally, checks on the endorsement can be done to ensure that the endorser is part of the Wchain, and that the endorsement signature is valid.        *3. Installation Query System Chaincode*    The queries QSCC is to supportl:  1. list the installed chaincodes on a peer (“list cc --installed --all”)  2. list the instantiated chaincodes on a channel (“list cc (-installed) --chain channelid”)  3. list all the channels for a given peer (“list channels”)            Proposals for queries of type (1) and (3) may make sense to be cleared only for the admin of the MSP the peer belongs to. The reasn is that this is strongly related to an organization’s internal structure (e.g., which channels a peer has joined, which chaincodes it has installed, etc).     Proposals for queries of type (2) one option would be to allow it for any entity with read-access to a chain the query refers to. That is QSCC proposal creators should be checked against the channel’s read policy. However there is a chance that this reveals to the querier implicitly which channels that peer has joined, cause it will only list instntiated chaincodes in these chanels. For this reason, it may make sense to allow that also this query is allowed for the peer’s MSP admin.    Post V1, we may want to make all these policies configurable through this peer config file, i.e., core.yaml.          _Step 1_. A proposal of type ENDORSER_TRANSACTION will be sent to the endorser targeted to (chainless) QSCC.    The input args to the QSCC would be {“QSCC input”}.  The proposal would have the following structure  - SignedProposal    --> Proposal       --> Header              ----> ChannelHeader with type, set as normally; channelid nil and other fields nulled out             ----> Extension: visibility set to nil, ccid set to qscc             ----> SignatureHeader creator / nonce  set as for other chaincodes       --> Payload             ----> Input              ----> ChaincodeInvocationSpec                     ------> ChaincodeSpec (QSCC, with the above input)                     ------> GenerationID - not clear to me       --> Transient data set to nil       --> Creator signature , as usual    _Step 2_. QSCC will validates the identity of the creator on the QSCC proposal, as it being the local MSP/administrator.  QSCC uses the peer’s local MSP to check if the proposal signature is valid given the creator, and the creator of the proposal is an administrator of peer’s local MSP. If this check fails, the proposal is rejected. If it succeeds, we continue to the next validation step.  
Answer: 48134.0