I was trying to test out the endorsement policy feature of Fabric with the Running a Fabric Application tutorial and I have encountered a few questions/issues.
Instead of using LevelDB, I up the network using CouchDB by changing the command to ./network.sh up createChannel -c mychannel -ca -s couchdb.
After the call to InitLedger, I manually edit asset2's "Size" field value to another random value through fauxton, accessed from http://127.0.0.1:5984/_utils/ (couchdb0, which belongs to organization 1). So at this point, asset2 has 2 different value sitting in couchdb0 and couchdb1.
Then I invoke the UpdateAsset function in the chaincode to update asset2's value. I was expecting an error about endorsement policy is not met or something to be thrown as the different value of asset2 in couchdb0 and couchdb1 should results in different RW set.
peer0.org1.example.com|2021-03-23 09:03:09.568 UTC [statecouchdb] commitUpdates -> WARN 0b4 CouchDB batch document update encountered an problem. Reason:Document update conflict., Retrying update for document ID:asset2
I did notice this warning in logspout however there was no error caught in my try catch block, and it seems that a valid block is committed and the world states is getting updated as usual without any error.
Shouldn't the different RW Set would cast the transaction as invalid and the world states wouldn't be updated?
This is working as expected. You updated the size field but not the version field. The read set check only checks the version field. It is up to the chaincode to check other fields such as asset ownership (and size, if there are business rules around that, such as size not being allowed to change in an update). The asset transfer chaincode is a trivial sample and only checks for asset existence in state database by key. So in your case chaincode execution succeeded because it passed the asset existence check, endorsements succeeded, and validation succeeded since both endorsements were over the same read set (version) and write set.
You get the CouchDB warning because the internal CouchDB revision number was different due to your external update, but this is not a fatal problem and gets resolved by a retry (CouchDB internal revision numbers are not guaranteed to be the same across state databases since peer may update the same state multiple times, e.g. in crash recovery scenarios).
Related
I was going through https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html link where 3 phases of ledger updates have been discussed. My question is with regard to phase 3.We have below text at the above link:
After a peer has successfully validated each individual transaction, it updates the ledger.Failed transactions are not applied to the ledger, but they are retained for audit purposes, as are successful transactions.
Where are these failed transactions retained, are these with peer's FileSystem?
Are Failed and Invalidated transactions the same?
They are appended to the block of the corresponding channel's chain, but they do not alter the channel's state.
With "failed" you probably refer to those transactions discarded by the chaincode's logic (those returning an HTTP 500 error on endorsement as launched by shim.Error).
With "invalidated" you probably refer to those transactions that do not fulfill the endorsement policy. For instance, individual endorsements return an HTTP 200 success code, but endorsements from different peers do not match. Another example: a MVCC_READ_CONFLICT error when trying to update the same writeset in the same block.
what are the steps to troubleshoot below error when trying to invoke a chaincode?
Error: could not assemble transaction: ProposalResponsePayloads do not match - proposal response: version:1 response:<status:200 payload:"[\"00000\"]" > ...
we get this error when trying to invoke a chaincode using peer chaincode invoke
#morpheus: Has answered it excellently:
So I thought I will add to the above list of possible reasons:
I had by mistake added something like getting the current timestamp, and was using this for capturing the event date. This led to the different transaction responses by the endorsers, thus leading to the Response Payload not matching. The whole point to remember is that the result of execution should be deterministic as it is going to be run on all of the selected endorsing peers.
So use ctx.GetStub().GetTxTimestamp() for capturing the event time. This is the time when the transaction began and it will be constant across the endorser executions.
Check that you have installed the chaincode on all the peers your peer chaincode invoke command is targetting. That is the most likely cause of this error.
Other ways this error can occur:
You modified your chaincode and instead of installing a new version and upgrading the chaincode, you tried to be smart and overwrite the chaincode with the new file thinking that Fabric would not notice.
It can also happen if there is no chaincode container running on target peer and Docker daemon cannot be found on the peer node when it tries to instantiate a container or instantiation fails for some other reason
Another reason why this error can happen is if some peer nodes are using LevelDB and others are using CouchDB
The error itself originates from here. The first step to debug this error is to invoke the chaincode individually one-by-one on one peer node at a time.
Another reason that I forgot to check is using storing randomly generated values.
I never used random "Id" until now and didn't notice that it leads to ENDORSEMENT_MISMATCH
I am bit confused to understand following use case:
Lets assume, We have more than one transactions in same block which are changing state of same asset, then what will happen in consensus cycle of Hyperledger Fabric?
Block will be rejected
First transaction in block will be successful, but rest of them will be failed
Kindly help me to understand this corner case.
Consensus in Fabric involves multiple pieces:
Invoking chaincode functions and obtaining enough endorsements
(typically signatures) to meet the endorsement policy by invoking
the chaincode and receiving responses from the correct number of
peers
Submitting the transactions to the ordering service node(s) which reach consensus on the order of transactions and then package them into blocks
Ordering node(s) broadcast the transactions to the peer nodes which then validate the transactions and commit state changes for valid transactions
Peers validate transactions by checking to make sure each transaction meets the endorsement policy for the chaincode invoked and then checks the read set of each transaction to make sure that the version of each key which was read in the chaincode has not changed. If it has changed, the transaction is marked invalid and it's write set (state changes) is not processed. The transaction still remains in the block but the block is annotated with metadata indicating the status of each transaction in the block. The validation and commit logic is deterministic.
You should read through the Transaction Flow and Read-Write set semantics in the documentation for the lower level details.
I successfully deployed my network file(.bna). Then I started a REST API using command composer-rest-server. I submit a single transaction using my front end Laravel application. When I try using for loop for submitting multiple transactions, I get an error in some time that MVCC_READ_CONFLICT. I decrease my network's bachtimeout. But the error continues. Please answer anyone if you have any idea about this issue.
Fabric vertion: 1.1.0
Composer : .19.16
Node :8.12
OS: Ubuntu 16.04
Well, MVCC_READ_CONFLICT means you are doing concurrent modification for some key in two different transactions, hence after transaction being ordered into block, whatever transaction gets in first committed while second one or subsequent transaction which works on same key marked invalid with MVCC_READ_CONFLICT.
To understand better the reason behind this status it's probably worth noting the transaction flow in fabric:
Client submit transaction proposal for endorsement sending it to endorsing peers
Endorsing peers executes simulation of chaincode where execution results are captured into Read-Write Set
Client collects endorsements and composes transaction, submitting it for ordering
Ordering service batches transactions into block employing total order of transactions
Block distributed between peers
Peer conducts validation to attest conformance with endorsement policy for each transaction
After that there is multi value concurrency control (MVCC), which checks for concurrent modifications, in fact validating keys version of RWSet and if concurrent modification detected tx invalidated with status MVCC_READ_CONFLICT
You can find more details in documentation "Transaction Flow".
lower the latency of the block creation so that blocks will be created more frequently and thus peers would be updated faster, for example, max_message_count=1 .but that may lead to some performance issue
What should be some of the best practices to follow to avoid bugs and write efficient Hyperledger Fabric Chaincode?
General Guidelines for writing Hyperledger Fabric Chaincodes.
Refer to the below link for a detailed description on the same:
https://gist.github.com/arnabkaycee/d4c10a7f5c01f349632b42b67cee46db
Some steps are concisely mentioned below:
Use Chaincode DevMode
Use Chaincode Logging
Using logging is simple and easy. Use Fabric's inbuilt logger. Fabric provides logging mechanism as follows:
For Golang: https://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#ChaincodeLogger
For NodeJS: https://fabric-shim.github.io/Shim.html#.newLogger__anchor
For Java: You can use any standard logging framework like Log4J
Avoid using Global Keys - Hyperledger Fabric uses an Optimistic Locking Model while committing transactions. In the two-stage process of endorsement & committment, if some versions of the keys that you had read in the Endorsement has changed till your transactions reach the committing stage, you get an MVCC_READ_CONFLICT error. This often is a probability when one or more concurrent transactions are updating the same key.
Use Couch DB Queries wisely
Couch DB Queries DO NOT alter the READ SET of a transaction -
Mongo Queries are for querying the Key Value store aka StateDB only. It does not alter the read set of a transaction. This might lead to phantom reads in the transaction.
Only the DATA that you have stored in the couchDB is searchable - Do not be tempted to search for a key by its name using the MangoQuery. Although you can access the Fauxton console of the CouchDB, you cannot access a key by querying a key by which it is stored in the database. Example : Querying by channelName\0000KeyName is not allowed. It is better to store your key as a property in your data itself.
Write Deterministic Chaincode - Never write chaincode that is not deterministic. It means that if I execute the chaincode in 2 or more different environments at different times, result should always be the same, like setting the value as the current time or setting a random number. For example: Avoid statements like calling rand.New(...) , t := time.Now() or even relying on a global variable (check ) that is not persisted to the ledger.
This is because, that if the read write sets generated are not the same, the Validation System chaincode might reject it and throw an ENDORSEMENT_POLICY_FAILURE.
Be cautions when calling Other Chaincodes from your chaincode. - Invoking a chaincode from another is okay when both chaincodes are on the same channel. But be aware that if it is on the other channel then you get only what the chaincode function returns (only if the current invoker has rights to access data on that channel). NO data will be committed in the other channel, even if it attempts to write some. Currently, cross channel chaincode chaincode invocation does not alter data (change writesets) on the other channel. So, it is only possible to write to one channel at a time per transaction.
Remember to Set Chaincode Execution Timeout - Often it might so happen that during high load your chaincode might not complete its execution under 30s. It is a good practice to custom set your timeout as per your needs. This is goverened by the parameter in the core.yaml of the peer. You can override it by setting the environment variable in your docker compose file :
Example: CORE_CHAINCODE_EXECUTETIMEOUT=60s
Refrain from Accessing External Resources - Accessing external resources (http) might expose vulnerability and security threats to your chaincode. You do not want malicous code from external sources to influence your chaincode logic in any way. So keep away from external calls as much as possible.