I have a conceptual question. I'm performing async requests to Composer REST and I'm getting message: 'error trying invoke chaincode. Error: Peer has rejected transaction \'552b42fa4d2cfd366ff1b7d01371878f53f7553b44f141187c6db86b75f68906\' with cdoe MVCC_READ_CONFLICT',. I got the same problem when using node-sdk. What is the reason for that? Shouldn't it be possible to submit multiple transactions asynchronously?
Hyperledger Fabric uses lock-free optimistic concurrency, with rollback in case of dirty read/writes. You need to avoid key collisions as far as possible and may need to write retry logic on the client side.
The BatchTimeout setting for Fabric can be used to decrease latency (minimise the chance of collisions) at the expense of throughout:
https://github.com/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml#L144
When you submit a transaction, the peer generates a read and write set. This read/write set is then used when the transaction is committed to the ledger. It contains the name of the variables to be read/written and their version when they were read. If, during the time between set creation and committing, a different transaction was committed and changed the version of the variable, the original transaction will be rejected during committal because the version when read is not the current version.
To address this, you will have to create data and transaction structures which avoid concurrently editing the same key. A sample way to do this is provided in fabric-samples here:
https://github.com/hyperledger/fabric-samples/tree/release/high-throughput
Related
I am new in this field and therefore I am still doing studies and researches, I would like to know if JSON files can be imported in Hyperldeger Fabric--if it is better Hyperledeger Fabric or Fabric Composer. more precisely I would like to understand if there is a way to populate the DLT of Hyperledger Fabric automatically.
for now, I have only tried Hyperledger Composer online playground
Fabric don't have any feature to automatically populate the ledger.
You have to develop a solution in order to upoload each Json file and put that on the ledger state.
Any type of data can be inserted on the ledged because it stores byte arrays so its up to you how to serialize.
in case you're asking to making your chaincode or smart contract like talking to the file system and read file or even call some API to collect JSON files,
it could be done but this will break your transaction flow specially during the endorsement process due to during the endorsement process it's expected from each peer to return the same value after executing the transaction against the chaincode to consider the transaction is a valid transaction,
so in case one of the endorsers failed to call the API or failed to read file from file system the transaction will considered to be invalid.
so it's not recommended to do any third party activity in your chaincode or smart contract even if it's possible to do so.
about populating the ledger it can be done it's eventually a database so you can dump it's data, However, if you're trying to backup to recover the ledger in case the whole network down it's impossible due to when you'll reinstall the network the whole config and certificates which were bounded to the transaction will be changed so it has no sense to do it.
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.
I'm aware that read query is a chaincode invocation which reads the ledger current state but does not write to the ledger.
The client app can choose to submit the read-only transaction for ordering, validation, and commit (for auditing purpose)
Question:
Is it possible to read the ledger db without going via the chaincode ?
What prevents someone on channel from directly reading CouchDB (assuming that is the underlying DB used) without using contracts and avoiding recording of reads
Fundamentally, we use an async communication in fabric. The node initiating transaction talks only with the peers synchronously and after that ordering service is initiated which will commit the txn to ledger after all verification check..
Is the following possible ?
node A submits a data to the ledger request for an operation -> which needs to be done by node B.
Is this possible for node A to notify B to check ledger and perform operation and B upon completion notify A to check the updated ledger ?
Is it possible to read the ledger db without going via the chaincode ?
What prevents someone on channel from directly reading CouchDB
(assuming that is the underlying DB used) without using contracts and
avoiding recording of reads
Nothing prevents you from doing it, if you have access to the database itself.
However, the clients usually don't have access to the database and thus the peer (through the chaincode) may enforce selective logic on which clients and what data can be read.
Think of an application server, a servlet container, etc.
The user that browses from the browser doesn't have access to the database the application server uses, right?
A similar thing takes place here.
Fundamentally, we use an async communication in fabric. The node
initiating transaction talks only with the peers synchronously and
after that ordering service is initiated which will commit the txn to
ledger after all verification check..
Strictly speaking, the ordering service does not commit the txn to the ledger, as the ordering service has no ledger. It packages transactions into blocks, then sends the blocks to peers. It is the peers that then validate and commit the block to their own ledgers.
Is this possible for node A to notify B to check ledger and perform
operation and B upon completion notify A to check the updated ledger ?
You need the client SDK to orchestrate all of these. User Chaincodes only run in the context of a client's request.
So, you can have a client perform an operation that submits a transaction, and then the client sends another transaction in which the chaincode checks the current ledger, etc.
Is there a way to disable reading from Hyperledger Fabric for a period of time?
I need this to allow only to write in hyperledger Fabric for a period of time, after this to allow only reading from hyperledger Fabric.
You might add a transaction to your chaincode that would update a state value that your other chaincode functions could check.
For example a disable_write transaction might set a state variable that other transaction chaincode could check before writing/modifying the world state. If the variable is set, don't allow the "write" transaction to occur.
You could then also add a second transaction to enable writes.
The only way to block any client from reading from blockchain has to be coded in the deployed smart contract and applying appropiate logic depending on your desired time policies, you will return requested data or an error indicating that reading is not allowed.
Found this today on https://chat.hyperledger.org/channels/fabric-questions:
Question:
from an operational standpoint, can you
'stop' a channel - for application-type transactions? That is,
'quiesce' the channel (ie the question posed is from an operational
management perspective based on a time-event)
jeffgarratt Answered:
one possibility is to alter the policies associated with the
channel with a config update. However, in general config changes
require multiple signatures from channel members. but once the
config is changed, you can effectively 'stop' the channel, i.e. alter
ability to write. this would still allow for reads, but the chain
would not progress, as no writes are allowed