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.
Related
I have searched so many sites blogs but not getting what exactly the difference between public and private transactions in Quorum Blockchain?
Public transactions in Quorum Blockchain are exactly same as they are done in ethereum.They modify only the public state of the blockchain.
Whereas the private transactions are done by specifying an extra feild privateFor along with other feilds. in which we give the constellation public keys of nodes for which the transaction should be privateFor.
In private Transactions only pthe rivate state of the respective nodes for which the transaction was done is modified.
And you cannot modify both public and private states in quorum in the same transaction.
Hope it gives you a starting point see here for more
https://github.com/jpmorganchase/quorum/wiki/Transaction-Processing Seemed pretty clear to me -
Public Transactions are executed in the standard Ethereum way, and so if a Public Transaction is sent to an Account that holds Contract code, each participant will execute the same code and their underlying StateDBs will be updated accordingly.
Private Transactions, however, are not executed per standard Ethereum: prior to the sender's Quorum Node propagating the Transaction to the rest of the network, it replaces the original Transaction Payload with a hash of the encrypted Payload that it receives from Constellation/Tessera. Participants that are party to the Transaction will be able to replace the hash with the actual payload via their Constellation/Tessera instance, whilst those Participants that are not party will only see the hash.
The result is that if a Private Transaction is sent to an Account that holds Contract code, those participants who are not party to the Transaction will simply end up skipping the Transaction, and therefore not execute the Contract code. However those participants that are party to the Transaction will replace the hash with the original Payload before calling the EVM for execution, and their StateDB will be updated accordingly. In absence of making corresponding changes to the geth client, these two sets of participants would therefore end up with different StateDBs and not be able to reach consensus. So in order to support this bifurcation of contract state, Quorum stores the state of Public contracts in a Public State Trie that is globally synchronised, and it stores the state of Private contracts in a Private State Trie that is not synchronised globally. For details on how Consensus is achieved in light of this, please refer to the section on Consensus.
Public transactions at like regular Eth transactions, whereas Private ones seem to be a way to limit the number of network entities that can successfully execute a smart contract within the transaction. For an analogy, consider the internet and http vs https websites. When you use http anyone in the network (well, anyone between you and the remote site) can snoop your traffic and know what you're doing. In https, only the destination site and you can know what you're doing. Both traffic types are carried on a public network and some data flowing between parties can be seen, but whether that data makes sense to everyone who looks or only some people who have the right access, is the difference. Same for Quorum trans- everyone can see and act on a public contract, only certain people can see and act on a private contract. It establishes smaller groups of people that know something secret, within a larger population
I am trying to understand how PBFT(practical byzantine fault tolerance) applied in block chain. After reading paper, I found that process for PBFT to reach a consensus is like below:
A client sends a request to invoke a service operation to the primary
The primary multicasts the request to the backups
Replicas execute the request and send a reply to the client
The client waits for f + 1 replies from different replicas with the same result; this is the result of the operation.
This is how I understand how it is applied in block chain:
At first, the elected primary node wants to write transaction A to chain, it will broadcast transaction A to other nodes.
Any node receives the transaction checks if the transaction legal. If the transaction is thought as legal, the node will broadcast a legal signal to all of nodes in this round of consensus.
Any node that receives equal or greater than f + 1 responds will write the transaction to the its own chain.
Here are my questions:
For malfunctioned nodes, if they keep failing to write block into its chain, they will hold a different chains with healthy node. In next consensus, the existing chain will be picked up at first. How do nodes know which one is the correct chain?
In step 1, the elected node send transaction to other nodes. Does "other nodes" means all nodes in the network? How to make sure if all nodes included in the consensus because there is not a centralized agency.
How do nodes know which one is the correct chain?
For tolerating Byzantine faulty nodes, It needs at least 3f+1 nodes in the network. PBFT is one of the algorithms which can tolerate Byzantine failure. So PBFT can tolerate up to f Byzantine nodes.
f number of malicious nodes can be tolerated if you use PBFT. If there are f number of malicious nodes which keep failing to write block into its chain, resulting in inconsistency with correct nodes, then one can figure that the same chains from rest 2f + 1 nodes are correct. (Correct nodes always output exactly same data to the same request in same order).
Does "other nodes" means all nodes in the network? How to make sure if all nodes included in the consensus because there is not a centralized agency.
In PBFT setup, identities of all nodes should be established. To do that, there should be central authority to determine whether a node can join the network or not. (Important: central authority only engages in identity management, not the algorithm itself)
Why this is needed? It's because PBFT works by voting mechanism and voting is not secure when anyone (including malicious node) can join the network. For example, a proposed value by the primary only can be recorded to all nodes in the way of state machine replication, which it means that there needs at least 2f + 1 agreed matching messages for the value to be accepted to the correct nodes.
Without the trusted identity management, Sybil attack is possible. And this is the main reason why PBFT is not for the open blockchain which allows any node can freely join or leave the network.
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.
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