More and more companies have become interested in blockchain technology. The promise of this technology is big: increased transparency, reduced dependence on intermediaries, reduced fraud and many others. There are a multitude of articles on the future of blockchain; however, they tend to be too abstract. In my view, there is not enough down-to-earth, specific use cases with concrete implementation examples. After all, when we choose a database technology, for example, all we really care about is how it can improve our business, not how it could disrupt the entire fabric of society.
In the following series of articles, I will look at different blockchain products in the context of a single use case. The use case assumes implementation of a private blockchain by a group of organizations to store and share data.
Private blockchains are not nearly as immutable and trustless as public ones (e.g. Bitcoin and Ethereum). However, this doesn’t mean there are no benefits to running a private blockchain, because sharing and replication of data is a common need in an enterprise setting. So here we’ll explore some of the most popular solutions enabling this and their benefits and drawbacks. But first, we’ll start with a look at our use case.
For the sake of ease and clarity, let’s consider an oversimplified version of a real life scenario from the finance industry. Once this simple use case is understood it is easy to extrapolate it to more complex scenarios.
Here are the parties in this scenario:
It’s easy to see how there is a need to share transaction data among these 3 parties. We intentionally don’t consider moving actual money using the blockchain, since this is a well known use case. Instead, we’ll focus on a simple use case of transmitting data objects with the following fields:
There are several requirements to this information flow:
In the following series we’ll explore how different blockchain technologies allow for implementation of this scenario and whether or not there are any advantages over traditional approaches. However, to have something to compare against, let’s first look at some of the conventional approaches to solve this.
Currently, such a scenario could be implemented in many different ways. Here is a non-exhaustive list of solutions from simplest to more sophisticated:
Since blockchain is essentially a distributed ledger with the inherent ability to sync data among nodes, at first glance it makes sense to use it for this use case. In short, it looks like this: each party runs a local blockchain node (an application running in the background) that is synced with other nodes and is able to send and/or receive trade data in near real-time. Such a setup is called a “private blockchain”, since this network is run by a limited number of entities that have exclusive access to it.
In the first part of the series we’ll look at Quorum, a blockchain solution developed by JP Morgan. In the future articles we’ll look at Hyperledger Fabric, BigchainDB, Tendermint and others.
Quorum is a fork of Ethereum code base that adds a different consensus protocol, encrypted storage and permissioned access to a standard set of Ethereum features, such as distributed ledger and Smart Contracts. In addition, it provides Constellation protocol to exchange encrypted messages. Why not just use private Ethereum chain? For this purpose, Ethereum has 2 major drawbacks: a) anyone can connect to the network; b) all data inside smart contracts is visible to all nodes. Quorum solves these, albeit at a cost of moving some data transfer and storage off-chain.
You can find implementation details in Quorum’s wiki. In short, the private transactions work as follows: each node has both a public and a private key. When party A sends a private transaction to party B it goes through these steps (I omit some implementation details for the sake of simplicity):
Private transactions in Quorum
The reason why we can’t store the full transaction on-chain is because, by definition, each node has an exact copy of the blockchain. Therefore, if we store it on-chain it will be visible to everyone. The workaround is storing only the hash on-chain and the rest off-chain. Hash doesn’t allow us to reconstruct the transaction data; however, it allows us to validate that transaction data is correct (if data is changed — its hash will be different and will not match the on-chain hash). This is how we get immutability and privacy at the same time.
Full example code can be seen in the github repo. The solution is quite simple and has the following components: Smart Contract, Private Transactions and New Trade Notifications. Let’s look at each of them.
Smart Contracts is a feature of Ethereum that allows you to publish a program on blockchain. You can then execute its code by issuing a transaction. A smart contract can store data “inside of itself” and have a logic determining who can modify and view its data along with other functions. When nodes receive a transaction referencing a smart contract’s method they execute it and record data changes, if any, in the blockchain.
Below is the shortened version of the TradeData smart contract code. The contract has the following features:
contract TradeData is mortal {
struct Trade {string internalTradeID;uint utcTimestamp;string traderName;int sizeBig;uint priceBig;string counterparty;string client;}
event NewTradeEvent(uint tradeID);
function addTrade(string internalTradeID, uint utcTimestamp, string traderName, int sizeBig, uint priceBig, string counterparty, string client) public returns(uint) {...}
function getTradeByID(uint tradeID) public constant returns (string, uint, string, int, uint, string, string) {...}
function getLastTradeID() public constant returns (uint retVal) {...}
}
(you can view complete contract code here)
As discussed earlier, unlike the pure Ethereum implementation, Quorum allows users to send private transactions. This includes transactions that modify a contract’s state. This is done by adding privateFor: [“RECEPIENT_PUBLIC_KEY”] parameter to the transaction payload. A state that is added via a private transaction is only visible to parties specified in privateFor. This makes it easy to share trades with just one client and not all clients.
Nodes can subscribe to be notified as soon as new trades appear in the blockchain. A node only receives a notification if it is allowed to view the corresponding trade. That’s how the custodian can monitor when a new trade comes in and can process it.
Although Quorum doesn’t appear to be fully production-ready at the time of writing, its architecture is quite simple and makes sense. Being based on Ethereum, it inherits all its nice features such as smart contracts, Solidity contract language, wide developer adoption, and easy-to-use JavaScript API.
Given that it is a free open-source technology, it is easy to see how in the future it could become a compelling alternative to traditional proprietary data sharing solutions. Such solutions can often be expensive, error prone, hard to maintain and scale. An open-source standard implementation would facilitate data sharing among companies without the need for multiple custom integrations.
Now that we’ve displayed a real-life application of private blockchain technology, we’ll take the same use case and look at HyperLedger Fabric implementation in the next article. Comments, questions or suggestions? Feedback is welcome and appreciated.