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.
Related
I installed two peers in two different organizations Org1MSP and Org2MSP and installed chaincode on all 4 peers. I did not set signing policy explicitly as it takes "Majority" as implicit signing policy. I am able to get information from all the peers when executed query. Later I added two new peers to each organization and made both of them to join the channel and installed chaincode on both of them. I did not execute approveformyorg now as it was already done in the previous step.
I am using Hyperledger Fabric 2.2.3 version.
Later when I executed
"discover --configFile discovery-conf.yaml endorsers --channel
channelone --server peer0.org1.example.com:7051 --chaincode basic"
I am getting details of all 6 peers of both the organizations. How do I configure non endorsing peers in my set up. I want to have atleast one non endorsing peer in each organization.
Every peer that has joined a channel is a committer on that channel.
If the peer has chaincode installed, it can act as an endorser.
If clients Invoke the installed chaincode on the peer, then it will act as an endorser.
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.
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)
The 2018 hyperledger - fabric publication uses the following terms interchangably
Endorsement vs. (Transaction) Proposal Response
Transaction Proposal vs. Endorsement Request
Are they the same?
In other words, is Endorsement the same as (Transaction) Proposal Response?
Is Transaction Proposal the same as Endorsement Request?
is Endorsement the same as (Transaction) Proposal Response?
In Hyperledger Fabric, Transaction Proposal is a request to the endorser peers to simulate the transaction on the actual ledger and signing the read/write sets taken from the result. It doesn't actually means writing to the ledger. Its just a simulation. The response peers give back to the client for an endorsement request (Transaction Proposal) is the Proposal response that is used for transaction verification, validation and achieving consensus.
Is Transaction Proposal the same as Endorsement Request?
Yes. These both terminologies are the same.