Choosing the best blockchain platform for your business from 4 famous open source projects
In today’s global environment, where some countries have been forced by the current medical crisis to stop non-essential parts of their economies, the situation seems quite dire, to say the least. Hopefully, there will also be a silver lining at the end of all this, and we will all emerge stronger through our collective efforts.
Certainly, everyone is becoming acutely aware of how fragile the world economy is, with all its global supply chains. Many elements of those chains (for example the global supply chain of essential goods) are owned by large entities, or totally centralised. For that reason, people are turning their heads (at least when speaking about IT) towards various open source projects that are promising to bring decentralisation to the supply chain and, with that, a high degree of resilience to disruptions.
Even if we ignore the current situation, staying relevant in the rapidly changing technological evolution should still be on the minds of every tech business leader out there from startups to large corporations, especially when it comes to blockchain/DLT technology. Therefore, if you are a business leader who is concerned about not losing relevancy or simply want to understand when and where different processes should be more decentralised, you will want to make an informed decision about using blockchain to benefit your business.
To help with your decision regarding that, in this article we will look at 4 open source blockchain/DLT projects, starting (in no particular order) with Hyperledger Fabric, then moving on to Corda, then Quorum and finishing with Substrate.
The main considerations include: ease of programming (smart contracts), throughput (for example transaction throughput), app footprint (like memory footprint), scalability, data privacy (the ability to store encrypted data) and, last but not least, support (either community support or official support).
1. Hyperledger Fabric (incubated by the Linux Foundation)
The name Hyperledger refers to the overall umbrella project of open source blockchains and related tools, started in 2015 by the Linux Foundation and hosting software contributions from companies such as IBM, Intel, SAP Ariba, and others. The Hyperledger brand name has various frameworks under its umbrella that can be found here. We will focus on one such framework called Hyperledger Fabric.
First of all, I would like to say that I see Hyperledger Fabric more like a fast DLT (Distributed Ledger Technology) platform, not a blockchain, or at least not according to my definition of a blockchain — for me a blockchain is a decentralized and immutable distributed database, where truth is determined by a consensus mechanism, like voting made by participants or PoW hashing, so that no central authority arbitrates what is true which translates into a system that deals well with faults and malicious actors. On the other hand, the standard Hyperledger Fabric architecture cares more about uptime (the transaction validation system is Crash Fault Tolerant first and foremost) and doesn’t do a great job resisting malicious actors.
Like many other commercially-focused DLTs, Fabric is a permissioned DLT.
If you are wondering how hard it is to develop a brand new smart contract for Fabric, things couldn’t be more easy. With Hyperledger Fabric, it is possible to pick from a wide range of languages to develop your smart-contract (called chaincode), including: Go, Java, JavaScript and TypeScript and maybe Python as well, in the future. What this means is, if you are a developer, you can quickly start building your chaincode in one of those languages mentioned above or if you are a business/team leader, you don’t need to invest any extra money for hiring Solidity devs or for upskilling your current dev team. For that reason, in terms of ease of programming, Hyperledger Fabric is the best.
That being said, it is very important to note that every smart contract lives inside its own Docker container (yes, Hyperledger uses Docker as its Virtual Machine, not the EVM or JVM or anything like that). This can be the main limiting factor of this project when it comes to app footprint, specifically memory footprint because of the large RAM overhead for each container, which limits the number of distinct contracts to just a dozen chain chaincode contracts on a normal system.
There is no built-in cryptocurrency in Hyperledger to prevent spam or to overcome the halting problem of infinite loops in state changing transactions. You might ask, if for some reason the smart contract execution doesn’t terminate (becomes frozen or something similar to that), what’s preventing the entire chain from freezing? Well, if the transaction does not execute within the configured timeout (by default ten seconds) the chaincode container will be killed by Hyperledger Fabric. Just to be sure the smart contract can be killed, one can make the containers bound to just one CPU, for example, but this means the overall execution of every piece of chaincode may be slower than necessary.
Another interesting thing to note is that, unlike Ethereum or other systems, chaincode smart contracts cannot communicate with each other. This potentially limits functionality.
Hyperledger Fabric uses two types of consensus mechanism: traditional crash fault tolerant Resource Aggregation for Fault Tolerance (RAFT) protocol or a byzantine fault tolerant (BFT) consensus protocol.
Looking at the first consensus option, RAFT, since this consensus mechanism is Crash Fault Tolerant, so when it comes to scalability it’s easier to scale nodes than in BFT systems meaning one can easily set up a DLT with super high transaction throughput, somewhere in the order of magnitude of thousands of transactions per second, but this can only really be done for consortium projects where all members already know and trust each other to some degree.
When it comes to data privacy, everything is OK here, as Fabric offers the ability to create private data collections, which allow a defined subset of organisations on a channel the ability to endorse, commit, or query private data.
Finally, last but not least, there is a lot of support, and here I am talking about community support. There is a lot of community activity that seems to happen on Stack Overflow or Reddit, however, there isn’t the same level of dev activity like in Ethereum. There are a lot of tutorials available describing how to setup your own Fabric network that either super high-level relying on basic setup scripts or really deep into the tech where the write-up assumes you are a DevOps expert especially when it comes to configuring all the crypto materials needed for a brand new network. This was once a complex process orchestrated through Hyperledger Composer in previous versions, which is no longer possible because Composer was recently deprecated. Therefore the barrier to entry is now slightly higher.
So, in conclusion, Hyperledger Fabric is perfect for when all your transaction logic can be handled by one or two smart-contracts and when you want to have low latency and a high throughput for the chain, and aren’t afraid to read through a lot of guides to get started.
2. Corda (by R3)
Corda is a DLT system built from scratch in Java by R3, a US company co-founded in 2015 by 40 of the world’s largest banks, but now comprising over 300 companies in their ecosystem. It is therefore understandable why the majority of current Corda-related news and developments focus on financial services applications.
Unlike almost all the other blockchain clients that tend to take inspiration and even code from other projects such as Ethereum, it only has a few aspects of it that are taken from Public Blockchain software, the majority are new.
There are two versions: the private Corda Enterprise, which is out of scope for this article, and the open-source Corda project. The two are said by R3 to be near identical in most aspects.
In terms of ease of programming, as in programming smart-contracts, it is worth mentioning that if you don’t have expert-level experience in Java or if you don’t have a team of Java devs at your disposal, Corda is really not for you. Smart contracts in Corda are named CorDapps and take the form of a set of JAR files (Java archive files which act like executable Java programs) containing class definitions written in Java (or with the new libraries, in Kotlin as well).
With regards to the throughput, there is no information about a specific number of transactions per second. I can only estimate a very large number of transactions would be possible. When a user creates a transaction, this transaction will eventually go to a coordinating node called a notary node, or a notary cluster designated to prevent “double-spends”. A network can have several notary clusters, because they are all pluggable, and the interesting part is the fact each notary can implement a variety of consensus algorithms. This particular architectural decision means Corda is unlike other blockchains or DLT solutions currently available.
Like in Hyperledger Fabric, you can have a consensus mechanism like RAFT or a new BFT called BFT-SMaRt. For that reason, if we were to start benchmarking a Corda network that uses RAFT, I am sure we would achieve thousands of transactions per second.
Unfortunately, Corda requires a lot of tuning, because the CorDapp contract is something that depends on CPU and network management being as close to the metal as possible, which is because it is not virtualized enough. This has its good side, as it has a low memory or app footprint.
This requires a lot of work done in the deterministic JVM sandbox provided but, fortunately, in terms of support, there is a lot of community support on Stack Overflow and Slack.
When it comes to data privacy, this is built in. Every piece of data stored is encrypted properly, the encryption is done in such a way that only the parties included within the transaction can decrypt it. Things get a bit more complicated when there are a lot of parties that want to share only certain things, therefore the need of something called channels. Thus, if you know the channel where a chaincode made by someone else is deployed, you can make your new chaincode talk to it, but only on that particular channel. If you are calling a chaincode on a different channel, you are limited to read only.
With regards to scalability, it is easy to add any number of nodes, thus the network being very easy to scale.
So it appears that Corda is good for fast enterprise projects where the rest of the codebase that already exists is also written in Java/Kotlin, or parties are willing to adapt to these.
3. Quorum (by JP Morgan)
Quorum is an Ethereum-based blockchain (and here I am talking about the GoLang flavour of Ethereum), that has been developed to provide various industries with a permissioned implementation of Ethereum.
Quorum was forked from the main Ethereum Go (Geth) repository more than two years ago by a team of developers managed by JP Morgan who at that time had experimented with another project called Juno. At the moment, it looks unclear how the future ownership of the project will evolve, because there are currently ongoing negotiations to merge Quorum with the startup ConsenSys.
Because of the amount of public information out there about Geth and Quorum, I would definitely give it a thumbs up when it comes to community support.
I can’t really say Quorum satisfies the ease of programming requirement because I am aware not everyone knows how to code in Solidity (Quorum is EVM based). The good news is that the tooling is comparatively excellent. That’s because Solidity is a very well documented language, and there are even plugins for VSCode and Atom.
In terms of data privacy, well, it is all up to you, as smart contracts can be either public (i.e. visible and executable by all participants in the network) or private to one or more network participants.
If we compare the throughput to other Ethereum chains we can make a few simple calculations. Block size by default is 3.7G units of gas which is significantly higher than the 8M gas default on other private Ethereum solutions. The default block time is 1 second but in fact the gas limit is so high that consuming it all would take longer than the block time. Based on this, we can conclude that the actual practical limit should be at least as high as a few 1000s of transactions a minute (more extensive testing would be needed though). Similar to Fabric or Corda, there are two possible consensus mechanisms supported, RAFT (the default consensus mechanism) and Istanbul, a form of BFT. Therefore, if we go with the default option of non-BFT RAFT, the transaction throughput can be even higher.
In terms of app footprint, as in mainly memory footprints, I would say that the memory consumption is quite low and one can compare it to Ethereum. Extra memory is needed though for the overhead of working with private transactions.
Of course, Quorum has the unique property of high scalability because the project is based on the Geth Ethereum client, therefore any scaling solutions from Ethereum MainNet could be easily added in later.
In conclusion, if you know Solidity or if you have at least one Solidity dev in your team, Quorum is the perfect option for you to build something quick, something that doesn’t necessarily need to be super fast.
4. Substrate (by Parity Tech)
Now, as the old saying goes, it is good to save the best for last, let’s look at Substrate (maybe not necessarily the best, but certainly the most intriguing one).
Substrate, made by Parity Tech (the same company that made the Parity Eth client), is not a blockchain per se. You can think of it as being like Wordpress where you can add certain templates or build a few templates yourself and get your own website that meets all of your requirements and is different from any other website out there, but still able to interoperate with them. If you want to build a new project using Substrate, all you have to do is implement a very small number of hooks in your code and then, almost immediately, you have your custom blockchain client for your favourite OS.
When it comes to ease of programming (programming smart contracts, of course), I must say, it is not that easy. It looks like there are two options: first one is to use the EVM module, which is good if you know Solidity or you have a Solidity dev; and second option is to use ink! module which uses the Rust programming language but that might be even harder because it seems Rust developers are in short supply. In fact, Parity Ethereum is the world’s second largest Rust codebase in existence, explaining the team’s choice here.
Therefore working knowledge of Rust and/or Solidity is required to be able to do any significant customization or adaptation of Substrate.
Because of how new this is, transaction throughput is unknown. My guess is that because of the fact that all smart contracts will end up compiling down to WASM (Web Assembly) if they are written in Rust and, because of how fast the underlying WASM interpreter runs, I would say that it might be at least a few times faster than Quorum as an example. Note that there are various mechanisms substrate allows you to introduce in order to limit bad user behaviour that would slow down the network (e.g. configurable transaction fees and storage fees).
The fact that you get to write your own code in one of the performant programming languages out there (Rust) means a much improved app footprint.
In terms of scalability, I have really good news here. As substrate is a framework for building blockchains, you have a lot of potential for scaling using various mechanisms. Single Substrate blockchains can scale horizontally by joining the future Polkadot network, should they wish to. Substrate allows you to write a custom fork choice or use a “Hybrid” consensus mechanism, using the combination of the classic AURA Proof of Authority consensus from the old Parity client, the new BABE non-BFT block generator, or even a Proof-of-Work algorithm for block generation + GRANDPA for finality.
In terms of scalability, as Substrate is a framework for building blockchains, you have a lot of potential for scaling using various mechanisms. Single blockchains can scale horizontally, by joining the Polkadot network should they wish to. Or you can build your own private polkadot-like ecosystem, something that will end-up looking like a blockchain of blockchains. Building parachains will also solve the problem of data privacy but you can also use Zero Knowledge Proofs with libraries made by Zkcrypto.
Finally, in terms of support (community support mainly), it’s now easy easy to contact the Substrate team through the public Riot chat, or if not, you can find a lot of materials on Awesome Substrate or on StackOverflow.
I am not sure if I want to recommend this solution to small businesses just yet. All I can say for sure is the fact that this is quite new and very open for experimentation. I really recommend using Substrate in your project if you feel a bit adventurous, but if you are not willing to experiment, stick with one of the other platforms presented above.
In conclusion, when it comes to rating the best platform, I personally think we should not choose only one, as solutions should be built according to the specified business model, or the size of your organization. Perhaps, in the future, banking organisations will settle on banking-inspired Corda, B2B businesses will move to platforms that run on commercially-sponsored chains like Hyperledger Fabric or Quorum, whereas B2C businesses will move to chains like Substrate. But only time will tell.
