COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode


Faisal
 

Failure Scenario

1- Started the network with privatechannel_cc v1 chaincode installed
2- Did multiple transactions 
3- Ran a script to upgrade the privatechannel_cc v2 ( GOT THE ABOVE ERROR)
`COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY`
4- The condition for step 3 is that the peer went down just before the chaincode upgrade and were out-of-sync. They were in the process of fetching all the previous blocks and the chaincode containers of V1 were down on both machines.


Checked the IDs (Hashes) of chaincodes installed on Peers of both Orgs and they are same.
Tried to instantiate instead of upgrade and it gives error as the chaincode is already instantiated.
Tried to query/invoke the chaincode and it gives the following error

"[channel org1channel] failed to get chaincode container info for privatechannel_cc:v1: could not get chaincode code: chaincode fingerprint mismatch: data mismatch" 

LOGS of the peer are attached in the file below.

 

peer chaincode upgrade -C org1channel -n privatechannel_cc -l golang -v v2 -c '{"Args":["init"]}' -P "OutOf(2,'org1MSP.member','org2MSP.member')" -o 192.168.171.32:7050 --tls --cafile /data/tls/ca.pem --clientauth --keyfile /data/tls/client-key.pem --certfile /data/tls/client.pem


Gari Singh <garis@...>
 

Looks like you were actually not persisting the storage for your peers (ledger, installed chaincode, etc).

It seems the orderer was still running so the channel already considered the chaincode to be instantiated.

I assume that when you started the peers, you installed the chaincode as well as joined the peer(s) to the channel.

The issue is likely that when you installed the chaincode on the "restarted" peer, the package that was built does not actually match the chaincode that was previously installed and instantiated.


Faisal
 

I can see how that is a problem when we are upgrading the chaincode (Hash might have changed due to the timestamp) but we tried installing and instantiating a chaincode with a different name first on the same channel and then on a different channel and even then we got the same Policy Violation error. 


Gari Singh <garis@...>
 

If you run "install" with the package option on two different machines then instantiation can fail due to the mismatch issue.
Did you try packaging first and then installing the same package on both peers prior to instantiating?

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Desktop Dev"
Sent by: fabric@...
Date: 11/15/2019 09:48AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] COULD NOT ASSEMBLE TRANSACTION, ERR PROPOSAL RESPONSE WAS NOT SUCCESSFUL, ERROR CODE 500, MSG INSTANTIATION POLICY VIOLATION: SIGNATURE SET DIDNOT SATIFY POLICY #fabric-chaincode

I can see how that is a problem when we are upgrading the chaincode (Hash might have changed due to the timestamp) but we tried installing and instantiating a chaincode with a different name first on the same channel and then on a different channel and even then we got the same Policy Violation error.


Faisal
 

Yes we have tried packaging, signing and then installing on each peer. We also confirmed by listing the chaincodes on both the peers and the IDs matched. The IDs also matched in the previous case as we did a "peer chaincode list --installed" on each peer and compared the IDs of chaincodes.