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.
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:
- Non-custodial asset manager (hedge fund) makes investment decisions (trades). Non-custodial means they don’t actually hold a client’s money. Instead, after a trade is executed they send directions to a custodian that moves the money appropriately.
- Custodian. Usually a large and trusted finance institution that holds a client’s money and executes transfers on behalf of the hedge fund. Custodian needs to know about each trade to distribute payments to counterparties.
- Client(s). Invests into the hedge fund. Each client needs to view trades in their own account, but not other clients’ accounts.
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:
- TradeID
- Trade Timestamp
- Trader Name
- Trade Size
- Trade Price
- Counterparty Name
- ClientID
- Other metadata can be added as well, including other fields specific to that trade type, e.g. option expiration date, etc.
Requirements
There are several requirements to this information flow:
- Deliverability: Each trade, without exception, should be reported to the custodian. Non-delivery of instructions to the custodian can trigger serious adverse consequences (e.g. a default on a trade).
- Validity: It is important that only valid information is delivered to the custodian.
- Immutability: The log of trades should be preserved at all times and never altered.
- Security: Only authorized parties should be able to view and send trade data.
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.
Conventional approach
Currently, such a scenario could be implemented in many different ways. Here is a non-exhaustive list of solutions from simplest to more sophisticated:
- The hedge fund could manually send trade info in an email. An employee of the custodian then reads these emails and inputs the data into the custodian’s database.
- The hedge fund uploads a file with trades to the custodian’s secure FTP where it gets picked up by a script which then imports them into the database.
- The hedge fund executes the custodian’s secure API call to submit trade data.
Blockchain approach
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
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):
- Generate a new symmetric key and encrypt the transaction using this key.
- Generate SHA3–512 hash from the encrypted transaction.
- Encrypt the symmetric key from (1) using party B’s public key.
- Transmit the hash from (2) on-chain, then transmit the transaction and the symmetric key (both encrypted) to party B off-chain.
- Party B decrypts the symmetric key using party B’s private key then generates a hash of the encrypted transaction, confirms that it matches the on-chain hash — to make sure that transaction data is correct.
- Party B fully decrypts the transaction using the symmetric key from (5).
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.
Implementation
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 Contract
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:
- Ability to add a new trade using the addTrade method. Only the owner of the contract, in our case the Hedge Fund, is allowed to add new trades.
- Ability to retrieve Trade object by ID.
- Ability to receive a notification when a new trade is added.
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)
Private Transactions
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.
New trade event
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.
Conclusion
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.