What are the fundamental differences between the two? I come from an Ethereum background and am fairly new to Hyperledger Fabric. I've heard people talk about "channels" in the Fabric ecosystem and it sounds quite similar to the concept of sidechains. It'd be awesome if someone could clarify the differences between the 2 (if they exist).
Since Etherium is a token-based blockchain, my understanding of sidechains is that they allow tokens to be transferred between the main ledger and a "child" ledger (the sidechain). Since Hyperledger has neither a native token nor the concept of "child" ledgers, I don't think they are really analogous to channels.
Hyperledger channels allow for private communication between a subset of peers on the network. Only those peers on the channel receive transaction data for the channel. Even if separate channels are not required, a single channel must still be defined, then all peers communicate on this channel. In this way, there is no main ledger in Hyperledger, as each channel effectively acts as a separate ledger.
Related
I have a problem with understanding why Hyperledger Fabric (HLF) uses blockchain structure.
I know that in Bitcoin blockchain structure ensures big security due to PoW algorithm and longest chain rule, but what are advantages of using a blockchain structure in HLF?
It seems to me that in Hyperledger Fabric, instead of the blockchain structure, there could be one transaction history log and network could work in the same way - I bet I'm wrong, but I haven't been able to find an explanation yet.
I would be grateful for the clarification of this issue.
I think a lot of questions you have in your mind comes from the overlapped definitions of DLT and blockchain.
DLT:
A DLT is simply a decentralized database that is managed by various participants. There is no central authority that acts as an arbitrator or monitor. As a distributed log of records, there is greater transparency – making fraud and manipulation more difficult – and it is more complicated to hack the system.
All of this could well be familiar because it’s written about the features of blockchain as well.
Blockchain:
Blockchain is nothing else but a DLT with a specific set of features. It is also a shared database – a log of records – but in this case shared by means of blocks that, as the name indicates, form a chain. The blocks are closed by a type of cryptographic signature called a ‘hash’; the next block begins with that same ‘hash’, a kind of wax seal. That is how it is verified that the encrypted information has not been manipulated and that it can’t be manipulated.
DLT platforms that are not blockchain provide immutability too, but it's just the way Hyperledger Fabric provides this characteristic which makes it a blockchain framework.
Every blockchain framework, be it the Ethereum, Bitcoin, etc all store the transaction information in blocks, where each block is linked to its predecessor by a hash and provides immutability.
Corda is very much similar to Hyperledger Fabric, but it is said to be both a blockchain and not a blockchain. Architecturally, it's very much similar to Hyperleder Fabric, but with only a key difference which makes Hyperledger Fabric a blockchain framework, and Corda a DLT.
I'll try to answer your question by emphasizing on the point that why Corda is not a blockchain.
Why is Corda a blockchain, and not a blockchain?
A Transaction in Corda is cryptographically linked (chained) to the transactions it depends on. Just like Bitcoin, but the range of concepts that can be expressed is far wider.
Transactions in Corda are processed by having each participant in the transaction execute the same code deterministically to verify the proposed updates to the ledger. Just like Ethereum, but the languages you can use are high-level and productive, like Java, rather than obscure ones like Solidity.
Transactions in Corda are shared only with those who have a need to know. Just like channels in Fabric but designed in from day one and fully integrated into the programming model.
Transactions in Corda are confirmed through a process of consensus forming using one of a range of algorithms, including Byzantine Fault Tolerant algorithms. Just like any other blockchain, but with the unique features that a Corda network can support multiple different consensus pools using different algorithms.
So, for all intents and purposes, Corda is a blockchain. And yet… there’s also an utterly critical difference.
Unlike the platforms mentioned above, Corda does not periodically batch up transactions needing confirmation — into a block — and confirm them in one go. Instead, Corda confirms each transaction in real-time. No need to wait for a bunch of other transactions to come along. No need to wait for a “block interval”. Each transaction is confirmed as we go.
Now coming onto your question why Hyperledger Fabric (HLF) uses blockchain structure? The answer is simply because they chose to.
References:
https://www.bbva.com/en/difference-dlt-blockchain/
https://cointelegraph.com/news/what-is-the-difference-between-blockchain-and-dlt
https://www.corda.net/blog/corda-top-ten-facts-7-both-a-blockchain-and-not-a-blockchain/
To keep the record immutable, Hyperledger Fabric uses blockchain structure. So by using Hyperledger Fabric, you can get an immutable record of all the transactions which is tough to temper with fraudulent activities.
Suppose you buy an valuable asset and you are the current owner of that asset. Now it is very hard for others to temper that records or change your ownership without your permission as Hyperledger Fabric uses blockchain structure to keep the record immutable.
I am working on how to develop a blockchain app using Hyperledger Composer. Since I have just begun with Hyperledger Fabric so I am pretty confused over Some Points-:
1) What are assets, participants and transactions.
2) What is the meaning of the symbol '-->' used for some variable.
3) Why do we need .bna file.
I am new to this concept so please bear with me as I have tried with documentation but it confuses me even more.
An asset is anything of value, whether physical or virtual.
A participant is a person or organization participating (taking part) in the blockchain network.
A transaction is an operation submitted by a participant to modify the blockchain. It could be transferring or modifying the amount of an asset. It could be recording an event. In any case, it modifies or creates a value in the blockchain network's ledger (also known as world state).
We are looking to implement a hyperledger-fabric solution and I'm stumped by this fundamental question. How is a hyperledger solution architected if not all participants are able/willing to host a peer node?
Our users are divided into 2 groups - payers and providers. Most of our providers are willing and have the IT infrastructure required to host a peer node. Many of our payers are/do not.
From the perspective of a payer participant how can I trust the system if I'm not a peer and don't have my own copy of the ledger? What options might we have in setting up a hyperledger environment that allows them to participate?
Apologies if I have missed the point or some documentation that describes this scenario but links to it would be most welcome.
The easiest "trust assumption" is for groups which don't run peers to trust a specific member who is running a peer. For submitting transactions, it really does not matter if you run a node or not ... you would likely care about the endorsement policy in effect to make sure that there is not one all powerful member with a peer, but other than that you submit to multiple peers for endorsement anyway. For querying data, as mentioned you might have affinity / trust for one particular member, you might select a random or majority set of peers and do a "strong read". A query is still an invoke so you can actually query multiple peers in the same call.
In Ethereum, we cannot define/add new responsibilities for miners unless we modify/change miners' code.
Question: In Hyperledger Fabric, can we define/add new responsibilities for/to miners by using system chaincodes? or the system chaincodes are only for certain purposes (e.g. defining policies, validation)?
edit: this edit is done after the 1st answer has been provided.
miner or nodes or peers or orderers
There is no mining or miners in Hyperledger Fabric.
As #Jworthington stated, there are no miners in Hyperlegder. You need to take a step back and understand the core difference between Public Blockchains (Ethereum) and Permissioned Blockchain (Hyperledger, Corda).
To be fair, calling Hyperledger a blockchain is a bit of a misnomer. It is a distributed legder, and does not require the action of miners to reach consensus.
Both platforms work with the concept of nodes, with differing functionality. They are both similar in that nodes host versions of the world state/ legder. In ethereum , you have miner nodes, which are full nodes, with the additional responsibility of validating transactions via Proof of Work. In Hyperlegder, nodes function either as clients (to connect with the Fabric network), peers ( copies of the world state, validate or endorse transactions) and Orderer.
When you write chain code, you craft the rules that dictate the validation of transactions by the orderer. This is installed on peers and instantiated on each of the channels. You install the chain code on peers you want to endorse transactions (using the Lifecycle System Chaincode).
Endorsers simulate and endorse transactions using the Endorsement System Chaincode (ESCC), while committer peers validate transaction using the Validation System Chaincode (VSCC).
Hope this helps.
A couple of questions on channel:
Characteristics of a channel:
besides partition does the channel have the characteristic of hierarchy - meaning, if I have 3 channels can I arrange them into a hierarchy structure, channel a contains channel b and channel b contains c?
Management of channel:
sort of related to above question;
what is the best practice to manage all channels under one peer/user,such as, CRUD? In my mind this concept of channel seems to be a great idea but could possibly become out of control quickly - the impact on scalability, performance, storage and data segregation of the network.
Is there any details around the roadmap of how to manage the channel in both the micro and macro sense?
These are Hyperledger Fabric questions, as Composer does not manage channels (you deploy a Composer business network archive TO an existing channel).
Channels are essentially separate ledgers. They allow you to manage a single Fabric, that supports multiple ledgers across different subsets of your peers.