CODEWITHSUNDEEP
hyperledger-fabrichyperledgerhyperledger-composer
Matheus Correia
Matheus Correia

Reputation: 101

Hyperledger - Chaincode Fingerprint Mismatch

We have internally set up a Hyperledger network to run some tests. The version of Hyperledger Fabric being used is 1.1.

We have a network of 5 machines, each representing an organization, and all of them have - running over Docker - two peers, a CA, as well as a Command-line Interface. We also have an Orderer node that is running on a standalone machine.

We can install Golang chaincodes and make the organizations communicate just fine. The problem arises when we try to install business network logic via BNAs. We are using Hyperledger Composer 0.19.7. to do that and here is what happens:

  1. I generate the BNA by using npm install.

  2. I install it successfully on my local peers and start the network via the composer install and composer start commands.

  3. I send the very same BNA file over to other members of the network, and they also successfully install it on their peers with the composer install command.

  4. However, when they try to communicate with the network (composer network ping) with the appropriate admin card the following message is shown:

Error: Error trying to ping. Error: 2 UNKNOWN: error executing chaincode: could not get ChaincodeDeploymentSpec for todo-poc5-network:0.0.1: get ChaincodeDeploymentSpec for todo-poc5-network/default from LSCC error: chaincode fingerprint mismatch data mismatch Command failed

The really weird part is that if I - instead of the BNA - distribute the bin file that is installed on my peers (which is found in the /var/hyperledger/peer0/chaincodes folder) the ping command works perfectly and the organizations can communicate. But distributing bin files rather than the BNA itself does not seem like the ideal solution.

Has anyone experienced anything that is similar to that?

Thanks in advance.

EDIT:

Ok, sorry for the long absence.

It turns out we had different versions of CLI running, but even after normalizing them the error still appears. Any other suggestions?

You mentioned that following an install a path, ID, and version are provided. Is there anywhere I can see them?

Over the command line, by doing a composer install all I see is:

✔ Installing business network. This may take a minute... Successfully installed business network predic-poc, version 1.0.2 Command succeeded

Upvotes: 0

Views: 1007

Answers (2)

Diya Li
Diya Li

Reputation: 1088

When installing chaincode you provide a path, ID, and version. All three attributes become part of a "fingerprint" that must match when invoking chaincode. The issue appears when you install the same chaincode but used a different path. This situation will happen organically when different people on the same channel want to run the chaincode independently. example:

person A installs on Peer1 with:

path - /uhoh/chaincode/marbles/dir,
id - marbles
version - v1

and person B installs on Peer2 with:

path - /marbles
id - marbles
version - v1

then lets pick Person A to instantiate the chaincode on a channel both peers have joined. the intent was that each person would have their own chaincode running, but b/c the path is different invokes will fail to run on person B's peer.

This issue has been closed at the version of fabric v1.1.3, v1.2.2, and v1.3+ , see issues FABN-855 for more detail.

Upvotes: 0

david_k
david_k

Reputation: 5868

A fingerprint mismatch data mismatch occurs because the package that is installed onto the peers differs in same way and as such fabric sees this difference as an issue and reports this error.

In order to understand how this can occur, details about how composer puts the bna onto a peer is needed.

An expanded bna file looks like a node module, it has a package.json file and some artifacts that make up the business network, so composer unpacks the bna file and uses the fabric-node-sdk to package it up, telling it is is a node module and the fabric-node-sdk will package it up appropriately and send it to the peer. fabric can then unpackage this package and perform an npm install --production to complete the setting up of this business network. However there is a need to ensure that a reference to some composer npm modules are present in the package.json of the bna in order for the business network to be able to actually run, if these references do not exist then the composer network install command injects them into the package.json for you before the fabric-node-sdk creates the final package and sends it to the peer. What the command effectively does is to add these lines to the dependencies section of the package.json file

“composer-runtime-hlfv1”: “0.19.9”,
“composer-common”: “0.19.9”

(note the version number presented here was the latest version at the time of writing, you may want to use a different/newer version of the composer runtime)

And the version number that is inserted is taken from the version of the composer-cli you have currently installed, so if you have differing versions of the composer-cli you can see that when you deploy the same bna onto different peers, the package that ends up on the peer will differ if different versions of composer-cli are installed. (As a side point, the fabric-node-sdk doesn’t use the date/time of the files but sets them to a deterministic value so differing date/times are not an issue.)

There are 2 ways you can ensure this problem doesn’t occur.

  1. Ensure you use the exact same levels of composer-cli for installing onto different organisations’ peers
  2. You can explicitly set the version of the composer-runtime-hlfv1 and composer-common dependencies yourself inside the package.json of your business network implementation. If these are present then the command line will not overwrite or inject entries into the package.json prior to sending the package to the peers.

Upvotes: 1

Related Questions