Both, Hyperledger Fabric and BichainDB offer the possibility to have a private, permissioned blockchain database. With their concepts they try to address the main disadvantages of public blockchains like lack of privacy and lack of performance (low throughput etc).
What are the main differences between the two technologies?
If you try out example application of both frameworks, you will quickly notice that BigchainDB is easier to start with. Hyperledger Fabric involves a lot of more knowledge to master it.
Fabric knows different kinds of nodes (peers, peers additionally being endorser nodes, orderer) and thereby allows a very flexible setup, depending on the consortium design and organisations themselves. BigchainDB has one kind of node that can be deployed. Also every involved organisation gets one node of course.
Fabric has richer capabilities to model assets and all kinds of transactions. One transaction kind can always be implemented by a custom processor function doing whatever is needed to query or modify the state of the ledger. BigchainDB only knows CREATE and TRANSFER transactions on every defined asset. You can create something (that may be also divisable, e.g. amounts of tokens) and can transfer them completely or partly.
Both seem to have pretty low level APIs. Fabric has more APIs and config models that need to be mastered. But Fabric is being complemented by frameworks such as Composer (with all its nice libraries involved, like playground and rest-server) that really improve the programming model. As far as I know there is nothing like that for BigchainDB, also because it is pretty simple from the start.
Consensus: BigchainDB uses Tendermint which is Byzantine Fault Tolerant. Fabric does PBFT which is Practically Byzantine Fault Tolerance, based on the idea of Miguel Castro.
In general I would say that Fabric is intended to be used for complex business use cases. BigchainDB is simpler and nice for assets that can be divided (financal stuff like coins/tokens maybe).
Related
What are the advantages of hyperledger-fabric compared to a private Ethereum network? According to what I've read, Ethereum seems to be more like a general-purpose blockchain network whereas hyperledger-fabric can be more business-oriented but so far the features offering that advantage are not very clear to me.
Fabric is a Hyperledger project. It is an enterprise-grade distributed ledger that allows the development blockchain solutions
with a modular architecture. It has a permissioned architecture,
support modularization, pluggable consensus, and supports smart
contracts(aka ‘Chaincode’ in case of Hyperledger Fabric).
Various functions in the fabric are pluggable, and it also allows the use of any language to develop smart contracts. This functionality
is possible because it is based on container technology (Docker),
which can host any language.
As of now smart-contract in the blockchain run on an order-execute environment where the consensus protocol validate and order
transactions and broadcasts it to all the peer nodes in the network,
each peer node then sequentially executes the transaction. Most
blockchains today run on this order-execute blockchain environment.
The issue in this order-execute environment is that the smart contract
running here needs to be deterministic otherwise a consensus might
never be reached. To solve this issue, smart contracts have been
written in non-standard languages like Solidity with which the
non-deterministic operations are eliminated. However, this hinders
blockchain large scale adoption as smart contracts need to be written
in an altogether new language and it may lead to programming errors.
Moreover, as all transactions are only executed sequentially,
performance and scale are limited.
As Fabric eliminates the non-determinism issue, it has become the
first blockchain to enable the use of standard programming languages
to write smart contracts. In the 1.1.0 release, the smart contracts
will be written in either Node.js or Go; in the subsequent releases it
is envisioned that the platform will support other popular programming
languages like Java.
As widely known, the public blockchain network runs on Proof-of-Work concept and the transactions are executed on every node. Every
transaction and code that is implemented is visible to every node in
the network. This means neither the smart contract stays confidential
nor the transaction data which is processed. This means we have
exchanged the privacy of the contract and data for the public
consensus concept of PoW.
This lack of privacy is problematic for businesses. For example, in a supply chain business, some partners might be offered additional
discounts as a means of solidifying business. If everyone in the
network is able to see the contract and transaction, it won’t be
possible to do business – everyone will ask for the discounted rates!
Hyperledger Fabric as a permissioned blockchain offers privacy and confidentiality through its channel architecture. With Fabric, one can
establish a “channel” between the subset of participants who should be
granted the right to access a set of transactions. Like a network
overlay, only the nodes that participate in a channel have the access
to the chaincode (smart contract) and transaction data. This helps to
preserve confidentiality and privacy and builds trust in the network.
To enhance the privacy and confidentiality aspect, Fabric is offering
support to keep the data private and is developing zero knowledge
proofs (ZKP).
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.
Hyperledger Composer is a platform for accelerating the development process of Business Network Application. Why is it deprecated and what are the alternatives to composer for development of BNAs?
According to IBM, there are following three problems with Hyperledger Composer:
Composer has been designed from the start to support multiple blockchain platforms, not just Fabric - but this design has come at a cost. This design has meant that there are two completely different programming models - the Fabric programming model (chaincode) and the Composer programming model (business networks). This has caused significant confusion to users, with them needing to make a "choice" between the two programming models, with very few similarities between the two. In this particular case choice has been a bad thing, with many users opting not to use the "optional" part past the initial exploration or POC stage.
This design has also made it a lot harder for us to adopt and expose the latest Fabric features. For example, one of the questions we are constantly getting at the moment is "when can I use the Fabric v1.2 private data feature with Composer?". Whilst we've taken some steps (getNativeAPI) to assist with this problem, it is extremely difficult for us to keep up with and aligned with the latest features in Fabric when we are trying to maintain a design that keeps us blockchain platform independent. This has meant that users have understandably stopped using Composer and instead have reverted to developing with Fabric.
Finally, those of you that have used Composer will likely be fans of our simple, easy-to-use APIs (JavaScript and REST) for building applications that interact with a blockchain network. There is a lot of code behind the scenes to enable these APIs that doesn't really belong in Composer. What we have ended up doing is glossing over the underlying, low-level Fabric APIs instead of pushing improvements directly into these Fabric APIs. Today it takes ~50 lines of code to submit a transaction using the Fabric APIs, whilst in Composer it takes ~5 lines of code, and that's wrong - Composer's value should not come from just making Fabric easier to use.
Please read this for details.
The only problem with Composer is that IBM, et al abandoned it. Composer was (to an extent kind of still is) an effective way for users of Fabric to proof of concept (POC) business solutions for prospective customers -- and for users wanting to justify internal budgets to attempt to deploy projects internally. Using real-world business logic.
Composer should be the business logic stack that sits on top of Fabric and allows users to deploy without having to get down into the weeds.
I don't need to know that I need an orderer or CA for every org -- but I do need to know that I have 6 orgs who will participate in my network, two of them need to communicate using private data on a separate channel from the others and I do need to know what my business use cases rules are. An automated tool or script should allow me to launch an internal network **locally* and go from there. Yes, I will need to know fabric details or have someone on hand that does to be able to tweak my networks -- but Composer let me POC these.
There is no -- as in zero -- equivalent for Fabric -- in fact there is no tool to allow one to easily clone fabric samples for their own use and easily plug in their own network / org settings.
And the IBM VS Code plugin tool is garbage if you're wanting to setup an internal, standalone network without going to the IBM cloud. Really? Seriously?
Without Composer -- or a tool like it -- investing in Hyperledger Fabric is a huge financial & resource gamble and time sink. Period. The code changes almost weekly, there are significant bugs, the community is reticent to fix what at times are glaring documentation issues and address hardware sizing issues. Not to mention the cost to assign engineers and software architects to test what is not-yet-ready-for-prime-time software. Forget the amount of time that is needed to just get familiar with the documentation and fabric components to be able to architect business-grade networks.
Regarding the points made in the answer above:
There should be two distinct programming models because the BNA approach works from a business deployment point of view. To say that having a Composer stack with it's API on top of Fabric "confuses" users is like the old saying "if the customer is too stupid to know how to use the deeply technical product the customer is too stupid" -- that's fundamentally wrong.
I shouldn't have to refresh my knowledge of combustion engines every time I get into a vehicle and press the start button -- I know where I have to go, how I will get there and know how to operate the vehicle to do so. And if I want to tweak or otherwise modify the vehicle, its engine, electrical system, etc. I get out the equivalent of fabric documentation and learn to use those tools or hire a mechanic that already knows how to use them.
And the design did not make it harder to adopt and expose the latest features of Fabric -- what the development team failed to do was to implement those features in Composer in lock step with releases of Fabric. This was a dev team deployment issue and not an end user issue. And to say -- not imply, say -- that the community didn't step up to the plate was a load of crap. If IBM wanted to support it, it could have - it has the personnel, financial and global resources to do so.
Within real-world settings the business perspective of blockchain / distributed ledger viability for enterprise applications is less than enthusiastic -- in fact it's doubtful at best. The number one compliant we get from prospects globally (NA, EMEA) is no one can adequately demo this. No kidding -- showing a prospect via a terminal window that car ownership can move from one user to another is going to solve their business needs? Really? Via a terminal window no less.
For us to POC a complex use case and be able to back of the napkin demo it we now have to write entire fabric apps or hope we can cobble through fixing a fabric samples example -- and in the process work through the bugs in samples.
We've spent hundreds upon hundreds of hours building out POC use cases only to have Composer go by the way side, Fabric version x not work with the just released Fabric version xx, have prerequisite software versions change or issues with god forbid Raft or Kafka that haven't been fully tested prior to "alpha" next greatest thing Fabric release. etc., etc, etc.
And to the writers last point above -- the value of Composer should absolutely be making Fabric easier to use for basic network stand up and POCs. No one is suggesting that getting into the weeds with Fabric is a bad thing -- but from a BUSINESS point of view having something like Composer to POC before committing to projects it's essential.
Will we continue to work with Fabric and hope that the development team catches up with real-world business needs -- probably. All those IBM and other training sessions for composer we've put employees through for the most part have been a waste.
So, from a team who is trying so very hard to justify what is good about Hyperledger and Fabric -- please don't just sack something like Composer in the future. Because we're not going to invest in personnel and train them if this is just the next big thing to go by the wayside. I have 15 teams deployed with prospects globally working prospective use cases and implementations -- trying to tweak and push customer-centric use case demos to them has been Hyperledger Fabric hell.
One persons rather small opinion. GR
I think the reasons are clear from the previous comments, but for your last question one option hundreds of devs are taking is using Convector. Convector is a Hyperledger Labs project that was created before Hyperledger Composer was deprecated but that looks similar to developers. It follows a model controller pattern (similar to Composer assets and transactions) however it compiles natively to Fabric code and does not create a runtime.
Code created with Convector can be taken to production and include all sorts of helpers like an API generator, a development environment bootstrapper (one command to create a local network), decorators for making models more predictable, unit tests by default (CI/CD friendly), tens of code samples and real-life projects to use as reference.
Convector has a community of hundreds of devs, some of them migrated from Composer rather easily, others it is the first tool they get to know for Fabric. The main difference about why Convector won't go away anytime soon even if it looks and feels similar to Composer is its decoupled architecture and capability to use and run natively with Fabric.
If you'd like to join the community there people will help you migrate from Composer to Convector. You can join here.
Here's a blog post mapping concepts from Hyperledger Composer to Convector.
Small recap about Convector:
Looks familiar to Hyperledger Composer.
Same code can be taken to production.
Run natively and scales natively with Fabric.
An ecosystem of tools: unit tests, developer environment, API generator, etc.
Great and friendly community in Discord.
--
Disclaimer: I work with Covalent, the developers of Convector. Convector is a free open source Apache 2.0 group of projects.
I was reading lot of articles on blockchain and almost everyone has some different understanding of blockchain.
Is there any accepted definition of Blockchain by any community?
In few articles I read:
Blockchains are Decentralised while DLTs are not.
All blockchains are DLT but not all DLTs are blockchain. It added "if transactions get stored in blocks then it is a blockchain else it is not"
From above statements-
Is Decentralisation must for a Blockchain?
Or it is just a Immutable Distributed Database? which can be centralised or decentralised?
I would refer you to the first blockchain application, Bitcoin, which describes the "chain of blocks" in the original Bitcoin Whitepaper.
Blockchain
The term “blockchain” is often overused, that can have different meanings in different contexts. Blockchain technology has 3 major components that together really make it an innovation. Strictly speaking, a blockchain is just a data structure similar to a linked list. Blocks of data reference their previous block by including their digital fingerprint or hash in their block of data. If a previous block is modified, then all the following hashes will be different and it is easy to detect if the data has been tampered with. Even more importantly, is that this establishes an order to when events took place, in the case of Bitcoin, these events are transactions. The final piece is a consensus mechanism that allows participants on a publicly distributed network to all agree on a chain of blocks.
Consensus
A consensus mechanism extends the blockchain data structure by providing rules (agreed to by network participants) that enforce how blocks are accepted by the network as a whole. For example, with the proof-of-work consensus, there is an agreed-upon amount of work that must be done before a block is accepted as valid (its hash must meet a maximum value threshold). The lower the threshold, the more work must have been done (on average) to calculate the block hash. Providing a valid block hash becomes proof of work. This can make it much more difficult to modify past blocks, as the same amount of work must be done in order for the network to accept it as valid, thus distributed consensus can be achieved. This is why “blockchain technology” was invented, to achieve distributed consensus without relying on a third party. “Blockchain technology” is not really that interesting without the proof-of-work component and so it depends on what your definition of “blockchain technology” happens to be.
In conclusion, by this definition of blockchain, it doesn't make sense to use blockchain in a centralized environment (it is for distributed consensus).
One of the best writings on centralization and decentralization is an article by Ethereum creator Vitalik Buterin.
https://medium.com/#VitalikButerin/the-meaning-of-decentralization-a0c92b76a274
In this article he explains how even the most decentralized systems are also centralized to some extent.
Let's firstly make it clear that what is decentralization.
Decentralisation is the process by which the activities of an organization, particularly those regarding planning and decision making, are distributed or delegated away from a
central, authoritative location or group. Concepts of decentralization have been
applied to group dynamics and management science in private businesses and organizations,
political science, law and public administration, economics, money and technology. -- WikiPedia
So basically, there's no central, authoritative person or group or whatever to make decisions or plans in a decentralized system. According to this, I personally would prefer to separate it into two essential levels of a blockchain system.
In terms of the blockchain system(software and hardware) itself, it is decentralized. Because it is based on a distributed computer system, and it also has consensus algorithm (POW, POS, DAG etc.) to make sure each node/party in the system can reach to consistency.
In terms of governance, it can be decentralized or centralized. A typical centralized blockchain system is the private blockchain, since it is governed/managed by a single group or organization. While, obviously, a public blockchain is decentralized on the other hand.
Blockchain is a distributed ledger of Information. The main Concept was taken from the paper of Digital Time Stamping by Stuart Harber. The idea behind blockchain is to remove the centralized System so the decission power is taken from single Entity. Now if you want to make it centralised you are basically doing a trade off of the Basic properties of blockchain.
If you make the blockchain centralised one of the key feature is the consenses where other nodes verify the trnsactions so in centralised System the whole work is done by one node and we can assure that if that node is trustworthy node.
Block-chain is a distributed, decentralized, public ledger.
I'm currently working on a POC using hyperledger fabric + composer. I am somewhat confused when it gets to the consensus mechanism between orderers. From what i understand reading the documentation, hyperledger currently only supports SOLO and KAFKA. My understanding of SOLO is that the network only exists out of a single ordering node and no network consensus is reached between orderers (only 1 exists).
But this doesn't make sense to me; my gut tells me it must be possible to add multiple orderers without the use of KAFA / Zookeeper and that hyperledger has another mechanism to reach consensus between these two. The documentation regarding this is somewhat spotty and all over the place if i try to google it so i'm hoping someone can shed some light on the matter.
If no consensus mechanism exists between orderes besides a centralised one then what is the point of a distributed ledger platform?
The primary usage of SOLO ordering is for development mode, where you would like to test functionality without a need to span complex distributed consensus solutions. Moreover, note that consensus is a pluggable mechanism and could be replaced with anything you'd like, for example there is a recent proposal to use SmartBFT as an additional ordering service. Very similar to this you can add consensus mechanism of your own.
Currently if you need to distributed and highly available solutions for consensus there is a KAFKA based ordering service.
The Raft-based consensus protocol was added in Hyperledger Fabric v1.4.1, which simplifies deployment and adds decentralization to OSNs. It removes the additional dependency of Kafka/ZooKeeper needed to run a fault-tolerant network.