why is byfn just invoked on two peers (hyperledger fabric)? - hyperledger-fabric

I saw in byfn that just two peers are used for the code invocation but we have four peers in the network. Why are just two used?
./byfn.md:+ peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n mycc --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:9051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"Args":["invoke","a","b","10"]}'
./byfn.md:2019-11-24 08:01:03.051 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200
./byfn.md:===================== Invoke transaction successful on peer0.org1 peer0.org2 on channel 'mychannel' =====================

Because peer0 and peer1 for org1 are actually the same.
They share a gossip protocol and they share the same ledger in the form of a local copy.
Querying and invoking peer0 will get the same output as querying and invoking peer1.
This for org1, but same for org2.
You can for sure invoke all peers and see that you will get the same results.

Related

Chaincode definition not agreed to by this org (Org1MSP)

When I try to run the following command to commit the chaincode,
peer lifecycle chaincode commit -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA --channelID testchannel --name property --peerAddresses localhost:7051 --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE_ORG1 --peerAddresses localhost:9051 --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE_ORG2 --version 1.0 --sequence 1 --init-required
I encountered the error as follows even though the org1 approved the chaincode definition,
Error: proposal failed with status: 500 - failed to invoke backing implementation of 'CommitChaincodeDefinition': chaincode definition not agreed to by this org (Org1MSP)
Error Screenshot
I've attached a screenshot of the error.
Both organizations approved the chaincode definition by returning 'true' in this scenario. It still encounters the error "chaincode definition not agreed to by this org (Org1MSP)" after that.
How can I rectify from this?
The checkcommitreadiness uses a contract called product whereas the commit uses a contract called property.

Examining the Behaviour of Hyperledger Fabric when one of the stateDB is Tampered

https://kctheservant.medium.com/exploring-the-behaviour-of-hyperledger-fabric-when-world-state-is-tampered-764676fe90f2
I am trying a similar approach as in this link but with some changes. I want to examine the same scenario with only one organisation and two peers.
I looked it up and people had suggested to make both the peers and endorsing peers or either just create one more organisation. Couldn't find anything helpful in the hyperledger docs as well. Can someone please help me with this. Also, I am fairly new to all of this.
Using hyperledger-fabric version 2.3.0
You need to have the AND endorsement policy in the chaincode and then invoke the transaction.
The possible solutions to your problem are
Make both the peers as endorsing peers or
Add a new organization to your network
You need to have the AND endorsement policies to mimic this scenario. Whenever we invoke the chaincode we need to pass the endorsing peers using the --peerAddresses and their TLS certificates using --tlsRootCertFiles flags
peer chaincode invoke -n basic -C mychannel -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile "$ORDERER_CA" --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"Args":["CreateAsset", "1001","red", "20","aditya","100"]}'

Getting "ENDORSEMENT_POLICY_FAILURE" as Validation Code in Hyperledger Explorer for every transaction / block

I Have two Orgs in My Network. I have Created a channel deployed the chaincode on both Orgs (Org1 and Org2) and received code as VALID.
Chaincode approved by both Orgs, Checked committed readiness and Committed the chaincode. log goes like...
2021-10-04 14:30:52.864 IST [chaincodeCmd] ClientWait -> INFO 001 txid [eff4729bb0fcb0ac21b6b4c4ee78de75d9fc3bc04b67fdd1cc22c9b67044d93a] committed with status (VALID) at localhost:9051
2021-10-04 14:30:52.911 IST [chaincodeCmd] ClientWait -> INFO 002 txid [eff4729bb0fcb0ac21b6b4c4ee78de75d9fc3bc04b67fdd1cc22c9b67044d93a] committed with status (VALID) at localhost:7051
=============== Commit chaincode definition Org 1 ============================== Committed chaincode definition for chaincode 'sample' on channel 'samplechannel': Version: 1, Sequence: 1, Endorsement Plugin: escc, Validation Plugin: vscc, Approvals: [Org1MSP: true, Org2MSP: true]
=============== query commited from Org 1====================`` Committed chaincode definition for chaincode 'sample' on channel 'samplechannel': Version: 1, Sequence: 1, Endorsement Plugin: escc, Validation Plugin: vscc, Approvals: [Org1MSP: true, Org2MSP: true]
I have gone through similiar issues posted and added
BlockValidation: Type: ImplicitMeta Rule: "ANY Writers" in my configtx.yaml
Transaction gets executed without any error. able to view transaction hash.
But getting ENDORSEMENT_POLICY_FAILURE in explorer.
I have added sceenshots below.
Can any one please help what is wrong / needs to be changed here ?
Thanks in advance.
Image for reference -
ENDORSEMENT_POLICY_FAILURE
Chaincode deployment
The default endorsement policy is MAJORITY. It means your transaction to be validated by a majority of channel members.
To change the endorsement policy, you can specify Channel/Application/Endorsement in configtx.yaml to ANY Endorsement. Fabric will use this config as the default endorsement policy in all chaincode.
Or you can specify the policy for each chaincode by define it when approve & commit chaincode. For example:
peer lifecycle chaincode approveformyorg --channelID mychannel --signature-policy "OR('Org1.member', 'Org2.member')" --name mycc --version 1.0 --package-id mycc_1:3a8c52d70c36313cfebbaf09d8616e7a6318ababa01c7cbe40603c373bcfe173 --sequence 1 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent
peer lifecycle chaincode commit -o orderer.example.com:7050 --channelID mychannel --signature-policy "OR('Org1.member', 'Org2.member')" --name mycc --version 1.0 --sequence 1 --init-required --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem --waitForEvent --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:9051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
See more in Hyperledger Fabric documentation

Hyperledger Fabric- How do I resolve 'ProposalResponsePayloads do not match' when my smart contract is deterministic?

I'm trying to invoke a chaincode function that sets details about a crop.
This function doesn't use date/time, and is logically deterministic. I've checked that the chaincode is successfully installed for each organization of the channel and committed to the channel using peer lifecycle chaincode queryinstalled and peer lifecycle chaincode querycommitted.
However, when I run peer chaincode invoke, it yields an error Error: could not assemble transaction: ProposalResponsePayloads do not match.
There was a broader question that covered some common causes of error, but I'm not completely sure if any of the reasons listed are applicable in my case (Hyperledger Fabric: Error: could not assemble transaction: ProposalResponsePayloads do not match).
This was the invoke command:
peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile /home/ubuntu/fabric-samples/extended-test-network/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n papercontract --peerAddresses localhost:7051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt --peerAddresses localhost:11051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org3.example.com/peers/peer0.org3.example.com/tls/ca.crt --peerAddresses localhost:12051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org4.example.com/peers/peer0.org4.example.com/tls/ca.crt --peerAddresses localhost:13051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org5.example.com/peers/peer0.org5.example.com/tls/ca.crt -c '{"function":"plant","Args":["bhut jolokia", "ghost pepper farms", "sustainable agriculture company", "two dozen", "three quintal per year", "yes", "polyculture", "organic, pesticide-free", "direct sowing"]}'
Here is what the error message looks like, after adding some newlines and tabs:
Error: could not assemble transaction:
ProposalResponsePayloads do not match -
proposal response: version:1 response:<status:200
payload:"{
\"field1\":\"\",
\"field2\":\"\",
\"field3\":\"\",
\"field4\":\"\",
\"field5\":\"\"}" >
payload:"\n \335-\3101\315<\016\327\324\005\037\202%\360\305\177\2369T\273\334\324X\363\020\302\"f\r6\030\373\022\325\020\n\343\010\022>\n\n_lifecycle\0220\n.\n(namespaces/fields/papercontract/Sequence\022\002\010\016\022\240\010\n\rpapercontract\022\216\010\032\213\010\n\030\000SpiceList\000bhut jolokia\000\032\356\007{
\"field1\":\"\",
\"field2\":\"\",
\"field4\":\"\",
\"splitKey\":[\"bhut jolokia\"],
\"field3\":\"\",
\"field5\":\"\"}"}
\032\330\007\010\310\001\032\322\007{
\"field1\":\"\",
\"field3\":\"\",
\"field4\":\"\",
\"field2\":\"\",
\"field5\":\"\"}"}
\"\022\022\rpapercontract\032\0010" endorsement:<endorser:"\n\007Org4MSP\022\252\006-----BEGIN CERTIFICATE-----\nMIICKTCCAc+gAwIBAgIRAJhO/KCN82dUT2ZWdlM5uREwCgYIKoZIzj0EAwIwczEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzQuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh\nLm9yZzQuZXhhbXBsZS5jb20wHhcNMjEwNjI1MDQxMjAwWhcNMzEwNjIzMDQxMjAw\nWjBqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMN\nU2FuIEZyYW5jaXNjbzENMAsGA1UECxMEcGVlcjEfMB0GA1UEAxMWcGVlcjAub3Jn\nNC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABGKB9vyBmDC9\nW9IGOaA7qlpAHUu2zuHxZGhuwcxqQSDY63/6L2Hpxhg3uVBhtxcOiROJvfZmjOxb\nkZxt2P25D9ujTTBLMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMCsGA1Ud\nIwQkMCKAIIEDOx3pOppcqaQjtVPfOozh9/NnLuOCB7UWNlSKndMZMAoGCCqGSM49\nBAMCA0gAMEUCIQDkmp/qnb0DpwPlRYSPH6Cv0JE4HkgKgoY9FUAFVR6rpwIgEsXH\nDn2uHMeio475cLoKbayZo87BRDsykM1rBNl1/bI=\n-----END CERTIFICATE-----\n" signature:"0D\002 \013v\273\205\327I >1\212\007\031\233o\276\315v\233\343\345\265r7\366\321\230\355z\361\023\005e\002 `\221\250!\372v\366\247H\213m\236\230\377\246\331\236\000\240< \337\346U\230RV\2040\376\035H" >
Does the output of the invoke command actually return the proposal response payloads? I've noticed that splitKey present in only one payload, and the order of the fields different in the payloads.
How do I get the proposal response payloads to be consistent?
try to use only one peer to endorsement,like these:
peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls --cafile /home/ubuntu/fabric-samples/extended-test-network/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n papercontract --peerAddresses localhost:7051 --tlsRootCertFiles /home/ubuntu/fabric-samples/extended-test-network/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt -c '{"function":"plant","Args":["bhut jolokia", "ghost pepper farms", "sustainable agriculture company", "two dozen", "three quintal per year", "yes", "polyculture", "organic, pesticide-free", "direct sowing"]}'```

--peerAddresses in Hyperledger Fabric v1.2

I was going through the documentation of Hyperledger Fabric v1.2. There was an invoke command and it seems like it is update in v1.2. I found a parameter --peerAddresses in
peer chaincode invoke -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"Args":["invoke","a","b","10"]}'
Anyone know what this parameter does? There was nothing mentioned in the official documentation about this paramete.
You can find the documentation here http://hyperledger-fabric.readthedocs.io/en/release-1.2/build_network.html
Topic: Build your first network
Command: Invoke
--peerAddresses introduced in Fabric v1.2 is used to specify a particular peer for endorsement.
Note: This parameter will not override the endorsement policy specified during chaincode instantiation.

Resources