Calculation of chaincode package ID in v2.2.x #fabric-questions #externalbuilders #fabric


chintanr97@...
 

Hi Team, I was trying to identify how is the chaincode package id calculated in HLF v2.2.x. More specifically, I understand that when dependencies change, the package ID would change too, for same package label.

However, I was facing an issue while following this guide to generate a package for "external chaincode service". If we see, the contents of package in this case are not likely to change for given "chaincode package label". Given that, I am not using CouchDB indexes in the package for now, whenever I delete and recreate the package, ideally the installation should be give me "same package id" on different peers. I am confused, because installing the package in this case (on re-creating package for different peers) is giving me different package IDs.

Given that I might not want to install chaincode package on all the peers I am running (at the same time), and I would also not like to store the packages in a place, given I can dynamically generate it before running `peer lifecycle chaincode install` command - I expect that because the contents are not going to change for a particular chaincode package label (or neither the environment is changing), why would the package ID be different?


Brett T Logan <brett.t.logan@...>
 

The unique identifier on the package ID is the sha256 of the chaincode "package" bytes. When you package the chaincode a metadata file is added that contains the path to the chaincode, its language, and its label. Is there any variation in these? In 2.0 and later the chaincode package is simply a tarball, you can untar it as you would any other tarball and inspect the contents to see what might be different between them.
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: chintanr97@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Calculation of chaincode package ID in v2.2.x #fabric-questions #externalbuilders #fabric
Date: Sat, Nov 7, 2020 12:00 PM
 
Hi Team, I was trying to identify how is the chaincode package id calculated in HLF v2.2.x. More specifically, I understand that when dependencies change, the package ID would change too, for same package label.

However, I was facing an issue while following this guide to generate a package for "external chaincode service". If we see, the contents of package in this case are not likely to change for given "chaincode package label". Given that, I am not using CouchDB indexes in the package for now, whenever I delete and recreate the package, ideally the installation should be give me "same package id" on different peers. I am confused, because installing the package in this case (on re-creating package for different peers) is giving me different package IDs.

Given that I might not want to install chaincode package on all the peers I am running (at the same time), and I would also not like to store the packages in a place, given I can dynamically generate it before running `peer lifecycle chaincode install` command - I expect that because the contents are not going to change for a particular chaincode package label (or neither the environment is changing), why would the package ID be different?
 


chintanr97@...
 

I am using "chaincode as an external service". So likely my package does not have any chaincode related dependencies. My package mycc.tgz contains following contents:
1. code.tar.gz
  1. This contains `connection.json` file whose content is constant for the given package label:

```
{
  "address": "mycc:9999",
  "dial_timeout": "10s",
  "tls_required": true
}
```

2. `metadata.json`:
  1. `{"path":"","type":"external","label":"mycc"}`

Now, as we see the package label `mycc` is not going to change and so are the contents going to be constant. When I create package for first time, I install only on `peer1` and `peer2`. Given that I know the contents are exactly the same, I will not persist the package. Later after some period I decide to install package on `peer3`. Again I create the same tarball `mycc.tgz` with exactly the same content. However, on installing on `peer3` the `packageID` turns out to be different than what it was on `peer1` or `peer2`. I do not understand this difference in hash calculations. Ideally, content is exactly same, creating packages at different timestamps, should not affect the hash right? In my case the environment and the script I am running are also the same always. 


conanoc
 

>>  Ideally, content is exactly same, creating packages at different timestamps, should not affect the hash right?
No.
A tar file contains timestamps of the files included. So the tar files will give different hash value each time.

-----Original Message-----

From: <chintanr97@...>
To: <fabric@...>;
Cc:
Sent: 2020. 11. 8. (일) 16:06 (GMT+09:00)
Subject: Re: [Hyperledger Fabric] Calculation of chaincode package ID in v2.2.x #fabric-questions #externalbuilders #fabric
 

I am using "chaincode as an external service". So likely my package does not have any chaincode related dependencies. My package mycc.tgz contains following contents:
1. code.tar.gz
  1. This contains `connection.json` file whose content is constant for the given package label:

```
{
  "address": "mycc:9999",
  "dial_timeout": "10s",
  "tls_required": true
}
```

2. `metadata.json`:
  1. `{"path":"","type":"external","label":"mycc"}`

Now, as we see the package label `mycc` is not going to change and so are the contents going to be constant. When I create package for first time, I install only on `peer1` and `peer2`. Given that I know the contents are exactly the same, I will not persist the package. Later after some period I decide to install package on `peer3`. Again I create the same tarball `mycc.tgz` with exactly the same content. However, on installing on `peer3` the `packageID` turns out to be different than what it was on `peer1` or `peer2`. I do not understand this difference in hash calculations. Ideally, content is exactly same, creating packages at different timestamps, should not affect the hash right? In my case the environment and the script I am running are also the same always. 
_._,_._,_