According to architecture explained (http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html), ordering service collects transactions (RWSets) into block for distribution to committing peers. Then, committing peer validates endorsement policy and RWsets then apply the transaction to ledger.
To verify the transaction was succeeded, should client application wait until all committing peers returned "Success" event ? Or just need to verify only one "Success" event ?
To verify the transaction was succeeded, should client application
wait until all committing peers returned "Success" event ? Or just
need to verify only one "Success" event ?
Tanaka, that's a very good question!
The short answer is No.
The reason is that in contrast to existing popular blockchains, HLF has a unique transaction lifecycle which does:
A transaction is simulated on some endorser or a few endorsers
It is sent to the ordering service and is cut into some block
The block is sent to peers, and they all execute the same validation code and all validation code for a specific transaction is guaranteed to reach the same conclusion in all peers, because they run it in the same order across all of them.
Therefore, if a transaction is validated on some peer - when other peers will receive the block the transaction resides in - they will too consider it as valid.
However - a very important aspect you should consider is data availability and synchronization.
For example, if you have an application that uses 10 peers and only 1 peer got the event and the rest didn't, and you invoke another transaction on the other peers, it might be that the endorsements that the other peers will compute will be turned into an invalid transaction, because they will simulate on old data (the fact that they didn't get the event yet proves that they have not processed the block for that transaction), so you need to keep that in mind.
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.
In the transaction flow documentation
5. Transaction is validated and committed
The blocks of transactions are “delivered” to all peers on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid.
Does it means that a block holds invalid transaction also?
Yes - since blocks from the orderer are signed, the peer serializes the entire block with both valid and invalid transaction. It adds external metadata to the serialized blocks to mark invalid transactions. And of course the state changes for invalid transactions are not applied to the state database.
Even I was confused about it initially, and had to re-read the documentation for better understanding.
As we know - a Hyperledger Fabric Ledger consists of two parts - 1. World State and 2. Transaction Log. So, what happens is, after an orderer sends a block containing ordered transactions with policies and transactions verifications, it is received by an anchor peer which in turn broadcasts the block to all the other peers in the channel.
Once a peer receives the block, it goes through every transactions in the block and validates the transaction - i.e. Policies Check, and sanity check of transaction details against the world state data. If a transaction is found defective on any account (Policies/Data check), the peer marks the transaction invalid and does not commit the transaction on the world state. In contrast, if a transaction is valid, the peer would perform actions (Add/Update/Delete) on the world state based on the transaction's read/write set.
Once all the transactions are processed, the block would be appended to the transaction log (aka Block Chain). Which means, the block in the blockchain would contain both valid as well as invalid transactions and transactions would have markings stating whether it is valid or invalid one. A peer can rebuild the world state by going through the transaction log - in that scenario, only valid transactions would be considered for rebuilding the world state.
There is also another answer on the similar line - https://stackoverflow.com/a/50622463/2040522
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 does it actually mean when we say endorsing peer simulates a proposed transaction. Why does endorsing peer needs to hold smart contracts to simulate proposed transaction ?
So, keep in mind that the transaction flow works as follows:
The client sends a transaction proposal to some peers, with input parameters for the transaction, such as: "please move 20$ from alice to bob"
The peers run the transaction in the chaincode container, and afterwards sign the output of the transaction: "this is the new balance of alice, and the new balance of bob"
The client sends the transaction that contains the results and the signatures of the peers to the ordering service
The ordering service puts the transaction into some block
The peers pull the blocks from the ordering service or from other peers, and then commit the transaction (if it's valid) into the database.
Therefore, the transaction is not committed in the peers at the time of its execution, but instead - it's "simulated". Meaning - the peer runs the transaction in a simulation where the reads from the database are normal database operations that read data, but the writes to the database are not actually being written during the transaction execution - but instead, they are recorded as "simulation results" which the peer signs and returns to the client