There are multiple possibilities for distributed ledger technology. This introductory article compares Corda, Hyperledger Fabric, Quorum, Ethereum and Bitcoin, relative to them fighting it out in a battle to determine what would be best suited to the use case of processing distributed transactions in the insurance domain. The considerations include data privacy, scalability and ease of programming.
Spectacular increases in the value of the Bitcoin cryptocurrency brought blockchain technology to the mainstream media, leading to widespread attention. Bitcoins are processed on their own public blockchain technology, called the Bitcoin network.
The Bitcoin network is unsuitable for building an insurance application since it is not a general-purpose environment for blockchain. The Bitcoin network is narrowly focussed on running programs that detail transactions using the bitcoin cryptocurrency.
The Ethereum network (hereon referred to as “Ethereum”) is a public blockchain that gives a much more flexible programming environment than that of the Bitcoin network, thanks to Ethereum featuring smart contracts. Smart contracts are programs written in a high-level programming language that runs on a distributed ledger technology.
In the case of Ethereum, smart contracts get compiled into bytecode then deployed to the Ethereum blockchain for execution. The vast majority of Ethereum smart contracts are written in a programming language called Solidity that was invented for that very purpose.
Ethereum smart contracts have an associated computational cost, which is paid for using a cryptocurrency named Ether. Cloud computing costs money, right? Programmers refer to this cost on Ethereum as “gas”.
The primary problem with building an insurance application on Ethereum is data privacy: all data is shared with all members of the network. As an insurer, would you want rival insurers knowing the details of the policies that you sold? That would allow your rivals to find out your customers and undercut your price at renewal.
Some distributed ledger technologies emerged seeking to fix the data privacy problems of Ethereum and these are introduced in the following section.
Quorum, Hyperledger Fabric and Corda are each referred to as being an enterprise blockchain. These are private networks — access to them is restricted to selected parties — with features designed for business enterprises, including known identities of network participants.
Secondly, data privacy is provided by enterprise blockchain — in contrast to the lack of data privacy that the Bitcoin network and Ethereum have. Each of Quorum, Hyperledger and Corda take a different approach to provide data privacy, as explained later in this article.
Third, regarding performance, the inherent design of Bitcoin and Ethereum mean that the transaction rates are very low, making these technologies not scalable enough for insurance processing. The enterprise blockchain networks have substantially higher transaction rates.
Public & pseudo-anonymous versus private & identified
With regards to a production environment, the Bitcoin network and Ethereum network each power a single public network. In contrast, Corda and Hyperledger power numerous networks in production.
Each network built on Corda, Quorum or Hyperledger is like a private party; an independent authority decides who to approve for membership of the network — with the party analogy, it is like a highly selective doorman choosing who to admit.
This contrasts with the pseudo-anonymous networks for Bitcoin and Ethereum. Say that you wished to do business with Insurance Company ABC Limited. On the Bitcoin network or Ethereum, ABC Ltd will be identified by alphanumeric characters, in a format such as:
- 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy (Bitcoin)¹ or
- 0xb794F5eA0ba39494cE839613fffBA74279579268 (Ethereum)²
But since these are pseudo-anonymous networks, there is no way built into the technology itself to assert that it genuinely is owned by ABC Ltd. Ask yourself:
- would you be comfortable sending substantial funds in a technology that lacks a built-in way to prove a company’s identity?
This is analogous to the limitations of most bank transfers, such as using banking’s SWIFT global network: the underlying banking technology itself doesn’t provide a way to validate that a given bank account number is associated with a particular company or vice-versa³. Therefore, man-in-the-middle fraudulent attacks are possible in SWIFT bank transfers, Bitcoin transfers and in Ethereum transactions.
In contrast, on Corda, Quorum or Hyperledger, this fraud risk is dealt with. To gain membership of a private network, a KYC (know your client) process is manually done by humans checking files such as company incorporation document, passport for a company director, proof of business address, etc. Upon successful completion of a KYC process, a digital certificate would be issued for Insurance Company ABC Limited, of which they exclusively hold the private key. Therefore, transactions signed by that particular private key can only have originated from ABC Ltd. Secondly, given a company’s name (Insurance Company ABC Limited) — plus, for Corda, the company’s city and country — these technologies themselves allow a lookup⁴ of that company’s associated node on the private network. It’s reassuring to know who you are doing business with.
Quorum provides data privacy by offering private transactions by separating public and private state and providing a peer-to-peer encrypted message exchange. Technically, private data is not stored in Quorum’s blockchain: only a hash of the private data is stored in Quorum’s blockchain.
Quorum is a variant, called a “fork”, of the Ethereum codebase; when the Ethereum codebase changes, Quorum will eventually get updated, too. Quorum was created by the investment bank JP Morgan and exists as an open-source project with contributions from developers around the world.
The Ethereum concept of gas remains in the Quorum codebase, however, the pricing of it has been removed. Effectively, Quorum has free gas; this works only because Quorum does not run in a public network, therefore there is not the need to provide economic incentives to people who most likely are not associated with a given transaction to pay for cloud computing to process that transaction and others (“mining blocks”).
IBM contributed the code for Fabric blockchain to an open-source initiative in 2015. That initiative is called the Hyperledger project and it is run by the Linux Foundation, a renowned non-profit open-source technology consortium.
Hyperledger Fabric is a blockchain that achieves data privacy via “channels”, which enable private communications between two or more network members. Conceptually, the overall deployment of a particular Hyperledger Fabric network is like one giant channel (i.e. to broadcast data to everyone) whereas private communications consist of subsets of this overall network. Each subset, called a channel, is like a miniature blockchain network. For example, there could be a channel exclusively for broker B and insurer N to privately transact with one another and there could be another channel exclusively for B, N and reinsurer R to privately transact with one other. You can imagine how rapidly the number of channels could grow.
Indeed, the operational limitations of the channels approach were highlighted in 2018 when the SWIFT banking cooperative published the findings from its proof of concept for Nostro reconciliation using Hyperledger Fabric:
“In order to move to full production, more than 100,000 channels would need to be established and maintained, covering all existing Nostro relationships, presenting significant operational challenges.”
Moreover, software development company MonetaGo decided to migrate away from Hyperledger Fabric and onto Corda:
“As we looked at the different scalability pieces of Hyperledger, we saw that it could get challenging, at least at the current throughput of Fabric. So we started doing some testing on Corda and realized, at least in this specific case, it made a lot of sense.”
— Jesse Chanard, MonetaGo CEO (2019), quoted in Blockchain-for-Banks Startup Switches From Hyperledger to R3’s Corda
Insurers want to create reports on aggregated slices of insurance claims data — because this is an essential part of optimising their claims process. An insurance company’s IT staff would be a lot less productive writing such reports using Hyperledger than with Corda, because Hyperledger uses a database⁵ (CouchDB or LevelDB) that does not support the widely known database query standard, SQL. In contrast, Corda supports SQL queries on its data due to using a relational database⁶.
Corda is a distributed ledger technology created by R3, a technology company founded in 2014; R3 gained prominence in 2015 when a consortium of banks joined the initiative.
Corda has an emphasis on data privacy by sharing transactions only on a need-to-know basis. Let’s say that there are a hundred companies from the insurance sector on a private network running Corda. If insurance broker B sells a policy on behalf of insurer N, then only these two parties have access to the data of that transaction. The other 98 companies do not even receive that data in their Corda nodes⁷. Therefore, in this insurance example, there will be no single node on the Corda network that has access to all the transaction data. The complete database — the union of all transactions by all participants over all time — only exists in a highly fragmented form, split across the various insurance companies’ Corda nodes of the network. That’s a good design in terms of data privacy.
Moreover, this is a huge boost to performance, as linear horizontal scalability can be achieved thanks to not having all data being shared with all members of the network. In short, each Corda node only needs to incur the computing overhead of processing a tiny fraction of data; in Bitcoin and Ethereum, all nodes must incur the computing overhead of processing all recent data.
There are two variants of Corda: an open-source version, free for personal and commercial use, and a closed-source (paid) version sold by R3 called Corda Enterprise, which is backwards-compatible with the open-source variant. Enterprise adds a range of features, including high-performance computations at a large scale.
Comparison of selected distributed ledger technologies. All of these are open source.
Blocksure’s DLT journey
At Blocksure, our journey to create a next-generation platform for the insurance industry took us from Ethereum to Quorum and ultimately we settled on Corda.
In June 2016, our initial R&D was on Ethereum, but we soon identified weaknesses:
- Lack of data privacy
- Low scalability
- Poor throughput
In November 2016, we began building a proof-of-concept on Quorum. However, from that work, we observed that Quorum:
- Was buggy
- Had slow transactions
In October 2017, Blocksure migrated from Quorum to Corda. We observed the following benefits of Corda versus Quorum / Ethereum:
- Much faster transactions
- Our developers found coding smart contracts in Kotlin to be more productive than coding in Solidity
- Corda is built on Java technologies (Kotlin is Java-compatible), thus benefitting from the huge Java-based ecosystem of tools and libraries, and there are a lot more Java developers out there who can be hired (and cross-trained on Kotlin, because at Blocksure we chose to use Kotlin rather than Java itself), than Solidity developers
Interoperability between the various initiatives and platforms within the Corda space is a goal for Blocksure. We are working in partnership with other significant industry players to design an interoperable landscape for insurance processing on Corda.
It is also fair to say, for the technical reasons given in this article, that the insurance industry has reached a consensus in choosing Corda as the most appropriate distributed ledger technology for insurance processing.
Choosing the correct distributed ledger technology for your use case has numerous considerations, spanning data privacy, performance, ease of programming, and public versus private networks.
Since summer 2018, Blocksure has been in production with a next-generation platform for the insurance industry, built upon Corda. Before reaching production, we had to overcome numerous challenges and issues with competing distributed ledger technologies, Ethereum and Quorum.
 Blocksure Limited and its staff have no association with this Bitcoin address. The address is referenced in this external article from bitcoin.com, in which you may read the details of the three legal formats of Bitcoin addresses.
Blocksure Limited and its staff have no association with this Ethereum address. The address is referenced in Wikipedia (at time of writing), in which you may read more details on the format.
 For most countries’ banking infrastructure, in bank transfers, the recipient name field is simply plain text, without any validation applied on it by either bank. In your next bank transfer, type Donald Duck into the recipient field; your transfer will still work just fine. Exploiting this weakness is critical for bank transfer fraudsters, who convince their victim to use the fraudster’s bank details rather than that of the intended recipient. This technology weakness is due to be resolved in the UK in 2020.
 X.500 network name is the parameter used to lookup members of a Corda network. The lookup approach by Quorum is a query by the organisation ID (“org id”) and the Quorum documentation’s example ID uses “INITORG” rather than “ABC Ltd”. An enrollmentID (aka enrollId) parameter is used to represent a company’s name in lookups of members of a Hyperledger Fabric network.
Corda builds upon relational databases. Open-source Corda offers PostgreSQL, H2 and SQL Server; Corda Enterprise supports PostgreSQL, SQL Server, Azure SQL and Oracle. This article justifies in detail why R3 designed Corda to use a relational database (hence, SQL queries are supported) instead of a NoSQL database.
 Note this variant of the use case. In the event of the insurer using a reinsurance company for (part of) this policy, and that reinsurer also being on the network, then the policy data in Corda becomes shared with three parties: broker B, insurer N and that particular reinsurer.