I am having difficulty understanding how Hyperledger Fabrics' execute-order-validate work. Can someone provide a specific examples and compare/contrast that against an order-execute architecture?
https://www.ibm.com/blogs/research/2018/02/architecture-hyperledger-fabric/
order-execute architecture
Order: Transactions are added to the ledger in some order and disseminated to all peers.
Execute: Transactions are sequentially executed (e.g. using smart contract code) on all peers.
execute-order-validate architecture
Execute: Transactions are executed (using chaincode) in any order, possibly even in parallel.
Order: When enough peers agree on the results of a transaction, it’s added to the ledger and disseminated to all peers. This step is where the transactions are first given an ordering — until transactions are added to the ledger, there’s no concept of one transaction happening before or after another.
Validate: Each peer validates and applies the ledger’s transactions in sequence. Now that the transactions have an ordering, the peers can check whether a later transaction was invalidated by an earlier transaction. For example, this prevents one item from being sold two times (called double-spending).
https://medium.com/kokster/hyperledger-fabric-endorsing-transactions-3c1b7251a709
In bitcoin and Ethereum, all peers execute the transactions in a block, after the transactions have been ordered in a block.
Thus, they operate in a "Order-Execute-Validate" blockchain.
In Fabric - you only need to execute the transaction in a subset of the nodes and not on all of them, and the transaction is executed speculatively and sent to ordering.
Related
In Hyperledger Fabric, chaincode can contain non-deterministic funcitons, and necessary consensus percentage can be customized.
What happens if chain code is non-deterministic and the output is different in some nodes, but consensus was passed.
How syncronizing is archived ?
Can new node joined this channel have same transaction history?
Since the endorsement passed it will be commited then syncronized by gossip with all nodes.
The nodes on committing(VSCC) only verify the signature and if the minimun necessary set of endorsers was reached.
For example if you require 2 out of 3 Orgs to agree, when you have the minimum necessary(2) agreeing it will be commited without the need of the third org.
Reading the Fabric ordering service documentation on peer validation and commit it's stated that "Each peer will validate distributed blocks independently, but in a deterministic fashion, ensuring that ledgers remain consistent."
My question is, how can block validation be simultaneously independent and deterministic? It seems circular that because validation is deterministic the ledger is consistent, how can we be absolutely certain that each peer ledger is up-to-date at the time of validation?
"Each peer will validate distributed blocks independently..."
This means that the peers don't depend of each other to validate the new block, so a peer can commit the block and have a state ahead of others.
"...but in a deterministic fashion..."
Even the time of commit of each peer is different the result is deterministic(the same result) for all the peers
how can block validation be simultaneously independent and deterministic?
As said earlier, the validation on commit time don't need to happen simultaneously for all peer, Fabric ensure determinism of the content of transaction by checking the signatures of Endorsers and order of transaction by checking the Orderer signature.
The peers still need to fallow the block order since it's a blockchain :)
If its still not clear comment this question and I will edit to fulfill your doubt.
i had a query regarding the ordering service of Hyperledger fabric. If the transactions are linked to one another and it takes time for one transaction to get completed. For example, a delivery system on blockchain.
If the order delivered block takes time to be added. How does the ordering service order the remaining nodes?
In general, the output of a transaction has to make it into a block and be marked valid on commit before it is available to another transaction to use.
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