Last updated 2 months ago


Quorum is an enterprise blockchain platform based on Ethereum and spearheaded by JP Morgan Chase.

Because of its origin as a project from a major financial institution, it is no surprise that Quorum is viewed as a blockchain platform particularly suited for the financial industry. Quorum, like Ethereum, is open source. Further, by maintaining its status as a minimal or lightweight fork of Ethereum, Quorum’s creators and maintainers hope to quickly leverage the advances in Ethereum from time to time.

Quorum is designed to develop and evolve alongside Ethereum. Because it only minimally modifies Ethereum’s core, Quorum is able to incorporate the majority of Ethereum updates quickly and seamlessly. Source.

An obvious question is: Why use Quorum at all? Or, why not simply use Ethereum?

Though based on a permissionless platform such as Ethereum, Quorum is targeted specifically at the enterprise and therefore at permissioned networks looking to adopt distributed ledger technology. Further, JP Morgan has been able to inject Quorum with important performance parameters related to privacy and transactions processing. These strengths make Quorum an attractive option for organizations and consortia keen to exploit Ethereum’s power of smart contracts but uncompromising when it comes to privacy and throughput.


Make It Private or Take It Public

Quorum, because of its Ethereum origins, naturally supports transactions that are visible to all participants of a network. But the importance of transactions, which are visible only to certain participants on a network can’t be overstated. After all, we are talking of financial institutions and businesses as possible adopters here.

In addressing this need for private transactions, the Quorum team has not had to reinvent the wheel. Quorum simply extends Ethereum’s basic transaction model by now including a privateFor parameter that specifies the public keys of intended recipients. Simply put, privateFor is not a new transaction type but a label.

It bears mentioning that public transactions in Quorum are not equivalent to public transactions on an Ethereum network. Ethereum transactions are visible to all who join the network, which any one can. Quorum public transactions, however, are more aptly termed ‘common’ or ‘global’ and are visible to all participants in the permissioned network. Private transactions, further, restrict the transaction visibility to only a specified group of participants .

This public-private dichotomy also applies to the world of smart contracts. In Quorum, as in Ethereum, you can use Solidity to write smart contracts. These contracts, unless specified using the privateFor parameter, would be viewable and executable by all participants on the network.

In summary, Quorum makes the process of turning one’s network and smart contracts into a public or private one quite straightforward. What’s also worth considering is that companies can leverage the vast pool of Ethereum developers available worldwide to develop smart contracts on their Quorum network. The availability of such a talent pool is expected to speed up development time.

A Raft (or IBFT) to Consensus Shores

Ethereum relies on a PoW consensus mechanism to protect the network from attacks. While known for its reliability, PoW consumes massive amounts of power. In a permissioned network, however, using PoW compares to getting a bazooka to swat a fly. Perhaps there are easier, faster, and less energy-intensive ways to achieve consensus in a network where participants are known, where it’s highly probable that nodes may fail, but not as likely that nodes will turn Byzantine.

If you have read the section on Hyperledger, remember that they too grappled with the best way to achieve consensus in a permissioned model. For that matter, any permissioned network would have to confront such questions before deciding on what consensus mechanism to use.

In Quorum the choices offered are an etcd implementation of Raft and IBFT. By default Raft is used to provide a consensus mechanism that is Crash Fault Tolerant, and IBFT is its Byzantine Fault Tolerant counterpart.

Raft is recommended for a situation where all parties in a network are trusted and follows a leader-follower model. As mentioned earlier in the section on Hyperledger, achieving consensus in the presence of Byzantine nodes is a relatively time consuming process. This is because of the number of encrypted messages that need to be passed back and forth to tackle any Byzantine node. In the absence of a Byzantine scenario, however, Raft delivers faster block times and transaction finality.

IBFT, on the other hand, is used in situations where you want to run a network despite the presence of mutually distrusting nodes. Consider a scenario where you are forming a consortium that includes competitors. The possibility of a competitor-owned node being compromised or tuning malicious cannot be ruled out. ‘Don’t trust, but verify’ is the refrain that comes to mind here, and Quorum offers IBFT for such scenarios. For a detailed performance benchmarking study comparing Raft and IBFT on Quorum, refer to:

Quorum Geths Performance

A common thread across Quorum is its Go-Ethereum pedigree. As mentioned before, the advantages of standing on the shoulders of Ethereum is that Quorum’s developers can quickly leverage the advancements introduced in Ethereum. Another advantage is the access to Ethereum’s pool of smart contract developers. But what about transaction speed?

Ethereum currently hovers around 15 transactions per second, something that is far from suitable for most businesses, let alone financial ones.

But Quorum does things differently and in the right direction. First of all the very fact that Quorum is a permissioned network implies that that there are a lot fewer nodes as part of the network; and not every node needs to validate every transaction. For instance, private transactions need to be validated only by nodes that are part of the private network. And even if we are talking of public transactions, it only refers to all the available nodes on that Quorum network. Moreover the choice of consensus mechanisms, whether its Raft or IBFT as opposed to Ethereum’s PoW, contributes to faster block times and transaction finality. One benchmarking study, in particular, has found Quorum, to quote from its white paper, is therefore ‘able to process dozens to hundreds of transactions per second, depending on system configuration; enough to support institutional volumes’ .

Use Cases

SUKU to the Rescue

The supply chain industry has been routinely touted as one where blockchain technology can have a significant impact. What was once a simple endeavour from local farms to households not too far away has now become a journey spanning thousands of miles in some cases involving suppliers, government authorities, contractors, logistics providers, retailers, and finally households. In short, the current state of a complex supply chain is a perfect hotbed for lack of transparency, lack of traceability, and superfluous administrative costs as a result of piles of paperwork.

SUKU, a blockchain-based supply chain platform, is determined to change all that. In SUKU’s own words, it ‘is a blockchain-based ecosystem that aims to make supply chains more efficient, transparent, and secure by offering a supply-chain-as-a-service platform to enterprises.’

SUKU’s supply chain platform relies on both Ethereum and Quorum. Whilst the public Ethereum will be used for deploying smart contracts, Quorum will be used as the platform for transactions where privacy is important such as bid and ask offers.

The Game Is On

With its origins in the world of banking, who could have thought Quorum being applied to an industry as flashy as the gaming industry. But that’s exactly what’s happening at Microsoft’s game publishing business.

Ernst & Young (E&Y) and Microsoft have launched a content rights and royalties management system based on Quorum. This system will be rolled out in a phased manner, starting first with Microsoft’s own game publishing division. But E&Y and Microsoft believe that this platform will be useful to any business ecosystem that relies on licensing of rights and a payment system that is based on royalties. If that’s true, then the massive book publishing and music industries are obvious suspects.

Through this system, multiple parties, namely, the distributor, developer, and publisher will have real-time visibility into the same set of transaction data. This is expected to provide rich insights for all parties to respond better to market demand (or the lack thereof). Further, powered by smart contracts, the system will calculate and disburse royalty positions real-time leading to faster transaction speeds and vastly improved liquidity to all parties concerned.