I'm going through the documentation on Hyperledger Fabric, and there's a portion in the introduction that writes:
"Hyperledger Fabric assigns network roles by node type. To provide concurrency and parallelism to the network, transaction execution is separated from transaction ordering and commitment. Executing transactions prior to ordering them enables each peer node to process multiple transactions simultaneously."
Maybe this is some fundamental misunderstanding on my part about the structure of the network and the different functions and mechanics of nodes, but how can one execute a transaction prior to ordering one?
Within a Hyperledger Fabric network, transactions start out with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.
Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets.
These RW sets are then signed by the endorsing peer, and returned to the client application to be used in future steps of the transaction flow. Endorsing peers must hold smart contracts in order to simulate the transaction proposals.
The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.
The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.
The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state.
Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state.
Here, you have the roles that there are in Hyperledger Fabric:
Endorser Peers: they receive a transaction. Then, they execute the transaction against the Smart Contrat and they sign the result. They send the transaction signed to the peer that has sent it.
Committer Peers: the Peers get the Blocks (with the validates transactions) and commit them to its ledger.
Orderes: nodes that sort the transactions and generate the blocks.
I take this info from an answer that I write for a question.
Related
I am new to blockchain technology and have a basic question.
I understand that in any blockchain network, if any node tries to commit something which is not in sync with other nodes , it gets rejected.Then how the new transaction is commited and validated? Who has authority to do it.
That's the thing about blockchain. There is no authority that determines which block will get added to the chain. And by blockchain, I mean public blockchain.
Blockchain's typically are either public or permissioned.
Public
Public blockchain's, such as bitcoin and ethereum work on the principle of proof of work. In layman's terms, if any participant wants there transaction to be processed, i.e added to the chain, they submit it to the network. This transaction is then processed by independent entities called miners who have to solve a computational puzzle in order to produce a valid block, which if accepted results in compensation in form of the said digital currency for the work put in by the miner. Also, the longest chain is always accepted as the valid chain.
There is absolutely no criteria or organisation that overlooks mining, meaning anybody can become a miner and start contributing. So the network is for the people, by the people, anybody can join and both submit as well as process transactions.
If the transaction is valid, that is you own the coin and are not double spending it, it will be processed by a miner. And if the block produced by the miner is accepted, so is your transaction.
Private/Permissioned
On the other hand, in case of private/permissioned blockchain's like hyperledger fabric for example, participation and block processing is decided by a single or multiple organisations. Hence in this case, a block is processed only if it produced by a valid member and it is endorsed by nodes of all participating organizations.
As you said "if any node tries to commit something which is not in sync with other nodes" what I get is that you are asking about the block which one node produce but rejected by the blockchain. This scenario happens when 2 nodes try to find the proof of work and one node finds it first and broadcast to the network but due to network delay (there could be other reasons too for that), and the other node didn't get the block in this way stale/uncle blocks are created. Bitcoin blockchain considers the longest blockchain and discards the other.
If one of the peers crashed and out of sync, can I just simply copy the block file from another node?
Does the block hash include the block metadata?
What's the difference between orderer ledger and peerLedger(besides the flag for each transaction)?
Each peer have it own cert, so copying from other peers will not work.
The four metadata stored in a block are SIGNATURES, LAST_CONFIG, TRANSACTIONS_FILTER, ORDERER.
Ledger is kept at all peers and, optionally, at a subset of orderers.Peer Ledger differs from the Orderer Ledger in that peers locally maintain a bitmask that tells apart valid transactions from invalid ones.
I have successfully create a Hyperledger Fabric v1.0 network locally by following the steps Building Your First Network and communicating to this network from my java application using fabric-sdk-java.
Here it created the certificates using cryptogen tools and is able to invoke/query chaincode through each of the peers which participating in the same channel.
My implementations is like:
I have four organisations Org1, Org2, Org3 and Org4 each having one peer.
When Org1 creating an asset A1 with quantity 100 using the chaincode C1, it has to share this asset among the peers like
Org2.peer0 A1: with quantity 40 Org3.peer0 A1: with quantity
30 Org4.peer0 A1: with quatity 20
And remaining 10 only will be
available for Org1.peer0
All these peers joined in the same channel channel1.
My requirement is
If Org1 try to query the data for Org2 : error If Org1 try to query
its own data: return the Asset with the corresponding quantity.
Currently it is allowing to query all the data from all peers in the channel. In order to keep it hide the asset of one organisation from other, what is the best possible way?
I think that the source of your confusion due to the fact that you mixing the application logic with the business contracts logic which is usually implemented in chaincode.
Say you would like to establish Fabric network among 4 different parties and you need to define a rule which defines how you will split/distributed the asset among those participants. Now, let's put aside the peers. In your chaincode you encode notion of the asset and probably the notion of the users to avoid confusion let's call them persons. So you have 4 persons: Alice, Bob, Charlie and John and business rule which says that once Alice submit an asset it has to be distributed according to 40%, 30%, 20% and 10% respectively.
Next, to continue with say Alice works at Org1, Bob at Org2, Charlie at Org3 and John from Org4. Now you can implement a chaincode which will apply business rule based on whoever submits the transaction. Moreover you can implement ACL based on the submitter identity, hence to prevent from Bob query for balance of the let's say John.
The legitimate question will be why do I need 4 peers to implement such simple logic. As you can have only one peer with chaincode deployed, channel which configured for all 4 orgs and all you need is to send transactions proposal to invoke the chaincode.
The caveat in this approach is pretty obvious you need to decide which org will host and run this peer and the chaincode, therefore as all 4 orgs doesn't really trust each other they would like to host they own peer and invoke chaincode against theirs own peers. And in order to prevent each org to trick each other and reduce the influence of adversarial/non-deterministic behavior they will agree on endorsement policies which actually will make sure that peers of other orgs also receives same results as you during the simulation.
Now back to your question, peers are used to simulate transaction against current state and sign on the results, send results back to the client which aggregates endorsements based on policies and submits results to the ordering service which cuts blocks and deliver them to the peers, which will validate correctness of transactions in the block and eventually commit them to the ledger updating state.
Therefore your chaincode should encode notion of clients/users/persons among which you will distribute assets, those users could be mapped back to the client application (real world users), which might be enrolled into different organizations, hence having different certificates signed by appropriate org CA. Finally you will be able to leverage GetCreator API of the chaincode to understand which client invoked the chaincode and apply business logic and access control based on business logic you defined.
Sorry for making my answer too long, but to summarize. Your application/service will be based on two tiers: first one is the application tier - mapped to the user of org, second tier is the peer which holds the ledger and deployed chaincode - to simulate and execute transactions. Hence you will have 4 peers and 4 clients which will submit transaction to the peers and your logic will be based on the client identities rather on the peers.
Hope my explanation will make sense to you ;)
Let's say I have two chaincode in Hyperledger Fabric, ChaincodeA and ChaincodeB.
Some events in ChaincodeA will have to change state in ChaincodeB, for example, change its balance. If invokeChaincode() used in ChaincodeA to invoke some logic in ChaincodeB, which calls putState() to change ChaincodeB's state, any race condition could happen when getting consensus? What's the best practices on handling this?
While invoking a chaincode you do not change the state you only simulate transaction execution based on the current state. Only once transaction placed into the block by ordering service and reaches the peer where it has to pass VSCC and MVCC checks it gonna be eventually committed. MVCC will take care of possible race condition. Transaction execution works as following:
Client sends transaction proposal to the peer
Peer simulates transaction sign the results and put them into signed transaction proposal
Client has to repeat step #2 based on expected endorsement policies
Once client collected enough endorsements he send them to the ordering service
Ordering service cuts the block and order all transaction
Block delivered to the peers
Peer validates and eventually commits the block
As I understated two chaincode deployed on two different channels. chaincodeA want to call method of chaincodeB. As per specification its possible but only for read operation.
https://godoc.org/github.com/hyperledger/fabric/core/chaincode/shim#ChaincodeStub.InvokeChaincode
can you please share code how you are calling another chaincodeB from chaincodeA?
I have been reading the documentation on how HyperLedger Fabric's project is implementing a open source BlockChain solution: https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md
I have seen that PBFT consensus algorithm is used, but I do not understand how blocks are mined and shared among all Validating Peers in the BlockChain network.
Hyperledger Validating Peers (VPs) do not mine blocks and do not share the blocks between them. Here is how it works:
A transaction is send to one trusted VP.
The VP broadcasts the transaction to all other VPs.
All VPs reach consensus (using PBFT algorithm) on the order to follow to execute the transactions.
All VPs execute the transactions "on their own" following the total order and build a block (calculating hashes mainly) with the executed transactions.
All the blocks will be the same because: the transaction execution is deterministic (should be) and the number of tx in a block is fixed.
According to Hyperledger Fabric 1.X
User through Client SDK send the transaction proposal to Endorsing Peers.
Endorsing Peer check the transaction and make endorsement proposal of transaction(with read/write set (previous value/Changed value)) and send to again client SDK.
Client SDK wait for all endorsement, once it get all endorsement proposal it make one invocation request and send to Orderer.
Orderer verify invocation request rent by client SDK by checking Policies defined(Consensus), verify the transaction and add to the block.
According to configuration defined for block, after specified time or number of transaction it form a Hash of block by using transaction hash, metadata and previous block hash.
The blocks of transactions are “delivered” to all peers on the channel by the Orderer.
All committing peers verify the endorsing policy and ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. After this all the transactions in the block and update the ledger with new block and current state of asset.
Ledger Contains
1) Current state Database(Level BD or Couch DB)
2) Blockchain(Files)(Linked blocks)
Read the transaction flow of hyperledger fabric
Check image for reference
Hyperledger is an umbrella of blockchain technologies. Hyperledger Fabric, mentioned above, is one of them. Hyperledger Sawtooth also does not use mining and adds these consensus algorithms:
PoET Proof of Elapsed Time (optional Nakamoto-style consensus algorithm used for Sawtooth). PoET with SGX has BFT. PoET Simulator has CFT. Not CPU-intensive as with PoW-style algorithms, although it still can fork and have stale blocks . See PoET specification at https://sawtooth.hyperledger.org/docs/core/release s/latest/architecture/poet.html
RAFT Consensus algorithm that elects a leader for a term of arbitrary time. Leader replaced if it times-out. Raft is faster than PoET, but is not BFT (Raft is CFT). Also Raft does not fork.
With unpluggable consensus, another consensus algorithm can be changed without reinitializing the blockchain or even restarting the software.
For completeness, the original consensus algorithm with bitcoin (and does use mining) is:
PoW Proof of Work. Completing work (CPU-intensive Nakamoto-style consensus algorithm). Usually used in permissionless blockchains