Error: endorsement failure during invoke. response: status:500 message:"error in simulation: failed to execute transaction 83d5de17fa5569456cdd4205808455177bde8953e2b1e4f7c59100c3f76559f0: invalid invocation: chaincode 'CVT' is already initialized but called as init
It sounds like you are submitting a transaction that is flagged as an initialization transaction to a chaincode that has already been initialized. An initialization transaction must only be called once for each deployment of a chaincode.
See the description of initialization in the Approve a chaincode definition for your organization section of this page in the Hyperledger Fabric documentation for a more thorough explanation:
https://hyperledger-fabric.readthedocs.io/en/release-2.4/chaincode_lifecycle.html#step-three-approve-a-chaincode-definition-for-your-organization
Related
I am setting up the Key-based endorsement policy on Hyperledger fabric v2.3.3.
My chaincode endorsement policy is "OR('org1.peer','org2.peer','org3.peer','org4.peer')" and for a very specific key, the endorsement policy is "AND('org1.peer','org2.peer')". When a transaction is submitted very first time, it works fine because at that time chaincode endorsement policy works, but when I try to update the same key, it does not work. The node fabric-sdk sends the endorsement request to only 1 org i.e org1 (invoker) and the peer rejects the block and throws "Endorsement Policy Failure".
When I verified the block, I saw that the transaction was endorsed by only org1 not by both org1 and org2. Seems like the fabric-sdk did not send the transaction to the other org.
However, if I change my chaincode-endorsement policy to "AND('org1.peer','org2.peer','org3.peer','org4.peer')", everything works fine because the fabric-sdk is sending the transaction to every org's peer for endorsement.
The official document says
In practice, this means that the key-level endorsement policy can be either less restrictive or more restrictive than the chaincode-level or collection-level endorsement policies.
but from the above scenario, it seems like it can only be less-restrictive.
Peer logs:
2021-10-14 11:05:24.443 UTC [gossip.privdata] StoreBlock -> INFO 36d Received block [207] from buffer channel=assetschannel
2021-10-14 11:05:24.450 UTC [vscc] Validate -> ERRO 36e VSCC error: stateBasedValidator.Validate failed, err validation of key PUB-TEST-6 (coll'':ns'assets') in tx 207:0 failed: signature set did not satisfy policy
2021-10-14 11:05:24.454 UTC [committer.txvalidator] validateTx -> ERRO 36f Dispatch for transaction txId = b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e returned error: validation of key PUB-TEST-6 (coll'':ns'assets') in tx 207:0 failed: signature set did not satisfy policy
2021-10-14 11:05:24.454 UTC [committer.txvalidator] Validate -> INFO 370 [assetschannel] Validated block [207] in 5ms
2021-10-14 11:05:24.459 UTC [validation] preprocessProtoBlock -> WARN 371 Channel [assetschannel]: Block [207] Transaction index [0] TxId [b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2021-10-14 11:05:24.495 UTC [kvledger] commit -> INFO 372 [assetschannel] Committed block [207] with 1 transaction(s) in 36ms (state_validation=0ms block_and_pvtdata_commit=6ms state_commit=29ms) commitHash=[35570558fc04d3dfa400f053f2a0f9bed92ea227c894ae4536990627a5a19036]
fabric-sdk logs:
2021-10-14T11:05:24.491Z - warn: [TransactionEventHandler]: strategyFail: commit failure for transaction "b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e": TransactionError: Commit of transaction b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e failed on peer peer1.org1.com:7051 with status ENDORSEMENT_POLICY_FAILURE
2021-10-14T11:05:24.491Z - warn: [TransactionEventHandler]: strategyFail: commit failure for transaction "b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e": TransactionError: Commit of transaction b13b21ddd0cb351b93b47ccc556ea4b62bf41abd3a23a3734d56304c91e6066e failed on peer peer1.org1.com:7051 with status ENDORSEMENT_POLICY_FAILURE
The problem here is that during endorsement the client does not know what ledger keys your transaction invocation will read/write or what key-based endorsement policies might be applied. All it knows about (using the discovery service) is the endorsement policy for the chaincode being invoked, and so it will pick endorsing peers to satisfy that policy.
If your transaction invocation is going to access private data collections or make chaincode-to-chaincode calls, you can indicate that to the client so it can (again using the discovery service) select an appropriate set of endorsing peers to satisfy the effective endorsement policy considering those collections and/or chaincode invocations. This tutorial page describes how this is done:
https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-discovery-fabric-network.html
This still doesn't cover the scenario of key-based endorsement policies since the ledger keys accessed are a determined by the business logic of your transaction function and parameters passed in by the client application. So you need to provide the knowledge of organizations that must endorse explicitly using Transaction.setEndorsingOrganizations(). This will override the normal mechanism for selecting endorsing peers and use the organizations you have specified.
At the time of writing, a newer Fabric Gateway client API (Node, Go and Java) is under development, which moves much of the logic that exists in the client-side SDKs today into a Gateway peer. It is targeted for release with Fabric v2.4. This Fabric Gateway implementation will inspect the read/write sets generated by simulation of the transaction invocation during endorsement, and use this to dynamically detect the endorsement requirements for a given transaction invocation. So you should no longer need to specify the required organizations, collections or chaincode-to-chaincode calls when making client invocations, and it should work out-of-the-box with key-based endorsement policies. The exception to this general rule is when passing private data, where you should specify the organizations that you will allow to receive the data to prevent accidental leakage of private information.
Transaction is not endorsed by the endorsers in the multiple organisations
Tried changing the endorsement policy from 3 orgs to 2 orgs to verify whether the transaction is working or not.
Unhandled error for request POST /api/TransferCommodityPossession:
Error: Error trying invoke business network with transaction id d5334feb70ba03629859f1e4b87d2a687c14f5a5300b3219ecf330d6d22ae5d9.
Error: Peer localhost:7051 has rejected transaction 'd5334feb70ba03629859f1e4b87d2a687c14f5a5300b3219ecf330d6d22ae5d9' with code ENDORSEMENT_POLICY_FAILURE
Transaction should get executed which is being endorsed by the endorsers in the three different organizations in a single instance system such that the data gets updated in the couch db.
I have set up a fabric network of three organizations. 1 endorser peer each. 1 orderer across all three. I packaged the contract code(node) and installed on all three. Instantiated it via CLI of one of the peer.
Points to consider:
My chaincode tries to create a key value or I should say update the
World State.On invoking the function that does so, I always end up
getting [ENDORSEMENT_POLICY_FAILURE].
I have specified AND policy. OR policy seems to work fine. But I
have a scenario where AND is the necessity.
I invoke the chaincode via CLI of one peer. All other peers start
showing activity but ends up saying [ENDORSEMENT_POLICY_FAILURE].
Exact Error : "VSCCValidateTx for transaction txId =
3c0f7b5c5f81b5c261d1a981720273cdc617424ea264b157898dd17ad2de07ce
returned error: VSCC error: endorsement policy failure, err:
signature set did not satisfy policy".
I have monitored the chaincode containers of all three orgs. Only
the the container of the chaincode corresponding to the calling peer
shows activity.
As I perceive from my reading of the book Hands-On Blockchain with
Hyperledger, all the peers execute the chaincode. But in my case,
nothing is happening on other two peers' chaincode container.
I would be grateful to obtain help on this issue.
Am working on hyperledger fabric, i have network setup of 2 org,1 channel and 1 orderer.
I installed chaincode(Say CH1) in Org1, with endoserment policy "AND(Org1.member,Org2,member)". Now i need to install same chaincode(CH1) in Org2 to validate and endorse transaction.
Since chaincode(CH1) installed in Org2(for endorsement purpose), also permitted to execute transaction using same chaincode(CH1), which will affect state, created by Org1. How to prevent this?
You need to separate 3 concepts here:
Installing chaincode
Instantiating chaincode on a channel
Endorsing chaincode
Installing chaincode simply makes the bytes of the chaincode available on the peer on which it is installed.
Instantiating chaincode on a channel makes that chaincode available for execution on the channel.
The endorsement policy determines which peers need to successfully execute and sign a transaction (technically peers sign the endorsement response).
In your case, installing the chaincode on the peers for both Org1 and Org2 makes the chaincode bytes available to the peers.
Instantiating the chaincode on a channel will make it available for execution.
The endorsement policy you set requires that a peer from Org1 AND a peer from Org2 must execute and endorse the transaction.
Once the client has collected the endorsements, the transaction will be send to the ordering service and then delivered to all peers in the channel. When the peers in the channel receive a transaction which involves CH1, they will check to make sure that the endorsement policy has been met (in this case that a peer from both Org1 and Org2 signed the transaction) and only then can it be committed (after the other validation checks)
I referenced the web page : http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html
And I want to ask you about this picture and Endorsement Policy.
In section 2.3 of the website, the following statement appears. And that is related to ③ of the picture.
"The exact number of “enough” depend on the chaincode endorsement
policy"
And in section 2.4 of this web site, the following statement appears for a peer. that is related to ④ of the picture.
It checks that the blob.endorsement is valid according to the policy
of the chaincode (blob.tran-proposal.chaincodeID) to which it refers.
Question
What is the difference between an ③ endorsement policy and ④ a policy of
the chaincode?
Is ESCC related to ③, and ④ related to VSCC?
Question
What is the difference between an ③ endorsement policy and ④ a policy of the chaincode?
At stage 3, the peer actually proceed with endorsement, meaning literally signing the results of the chaincode invocation. While at 4 this is happens at commit time, where peer ensures whenever endorsement policy satisfied.
NOTE: It's up to the client to collect required number of endorsements.
Is ESCC related to ③, and ④ related to VSCC?
Yes, ESCC or Endorsement System ChainCode is the actually a system chaincode which responsible to "endorse" transaction, where VSCC or Validation System ChainCode is a system chaincode to check whenever endorsement policy satisfied.