Over the past several years blockchain has been expected to greatly impact the way assets are exchanged and to reduce the operational costs to banks and other entities in various industries.  As is often the case, the hype surrounding a potentially transformative technology has out-paced the ability to quickly deliver on these expectations.

This is no fault of the technology itself or those who work tirelessly on maturing this technology to achieve its promise.  However, it is this promise that has led many financial services firms to invest time and resources into numerous blockchain projects over the past few years.  Despite the number of projects, consortiums and firms involved in the development of solutions, blockchain still has unsolved issues particularly around privacy and latency.

For example, the transaction speeds currently possible using blockchain is a serious issue for an industry that is accustomed to much better throughput using legacy technology.  Privacy is another issue for the financial services industry that is required to comply with regulations, such as the General Data Protection Regulation (GDPR), which will affect the EU in May 2018 to increase the protections on the privacy of client data.

What is the current state of Blockchain?

There are two divergent paths that the industry is taking.  On one hand, there are the Bitcoin folks that believe in the beauty of blockchain and are trying to maintain the vision that Satoshi Nakamoto, the mysterious founder of Bitcoin had when he developed the crypto-currency.  Ethereum, a rival to Bitcoin, is an open-source platform that has attracted many Fortune 500 companies and led them to establish the Enterprise Ethereum Alliance.  Among the common benefits of these blockchain platforms is the ability to exchange assets without a third-party intermediary.  Like Bitcoin, Ethereum also utilizes the concept of “Proof of Work.” Both Bitcoin and Ethereum use miners to achieve consensus which is required before a transaction is written into the blockchain ledger.  This consensus methodology requires vast computing power and helps to create the current latency issue. 

However, one major difference between these two platforms is the ability to accommodate smart contracts.  Ethereum provides smart contract support but there have been several early failures where smart contract implementations have cost investors millions of dollars as their Ether, the crypto-currency associated with Ethereum, have been locked forever in virtual wallets or stolen by hackers.  The immutability of the blockchain, a benefit of the technology, also makes it virtually impossible to retrieve the assets after such events.

On the other hand, there is perhaps a more pragmatic segment of the industry that recognizes the current limitations of the technology and the constraints of industries, such as financial services, which has led them to take a different approach.  Unlike Bitcoin and Ethereum, platforms such Quorum, Hyperledger Fabric and R3 Corda are private ledgers.  While their approach does not maintain the vision of Satoshi, they do strive to overcome some of the issues that limits a public blockchain from wider acceptance and use.  By maintaining consensus on a transaction level as opposed to the ledger level, such as Bitcoin and Ethereum, the transactions maintained on a private ledger can remain private and are only shared with the parties to the transaction.  This approach is better suited for industries such as financial services.  This approach is also important when examining the implementation of smart contracts.  By requiring consensus on a ledger level as opposed to the transaction level, as I will explain later, the ability to execute a smart contract between two parties becomes more challenging.

What is a smart contract?

A smart contract is tamper-proof computer code written in one of several programming languages that reads and writes data to a distributed ledger.  It could be compared to a database stored procedure. From a business point of view, a contract is defined as a formal and legally binding agreement, however, smart contracts are neither smart nor generally legally binding.  An exception to that may be smart contracts implemented on the Corda platform integrating legal prose.  The purpose of the smart contract code is to execute tasks within a distributed ledger.  Smart contracts meant to automate steps within a business process to improve efficiency and reduce operational errors. 

The great promise of Blockchain has led to misconceptions concerning smart contracts

The introduction of smart contracts has generated great fanfare and has created many expectations.  However, some of these expectations on what is feasible, for example, on a public Ethereum based distributed ledger are based on misconceptions or misunderstanding of the technology.  The reality of smart contracts running on a blockchain is that they can only exist within the distributed ledger and cannot execute outside of the blockchain. 

One implication of this is that a smart contract cannot pull data from an external source. For example, if we were looking to build a solution to automate the settlement of interest rate swaps it would be necessary to retrieve the published interest rates on various fixing dates to calculate the floating rate side of the swap agreement.  A smart contract alone could not perform this function.  However, Ethereum developers have created oracles, trusted services, which are designed to respond to events on the blockchain, retrieving the necessary data and by using a hash (ID) and a key writing the data for use by a smart contract.  To maintain consistency with the “Proof of Work” consensus model the concept of multi-signature transactions has been developed.  This provides for multiple third-parties to split the approval process.  This may be used as a solution for consensus, but it also creates the potential for additional latency and worse in a scenario where the multiple parties do not agree, and the execution of the smart contract may be delayed.  

This limitation also has an additional implication as it affects how payments could be performed outside of the blockchain.  As in the example concerning external data, smart contracts cannot interact directly with the outside (off-chain) world.  Thus, payments cannot be executed outside of the ledger.  Similarly, the solution of a trusted service, such as a bank, that monitors the blockchain and executes payments outside of the ledger has been developed.  Again, the multi-signature transaction model could be utilized to achieve consensus, but it is not without challenges.    

An important thing to keep in mind is that the public Ethereum blockchain is maintained by miners who through their work reach consensus which allows transactions to become part of the immutable ledger.  This requires every node to verify each transaction to avoid the blockchain from failing.  What the oracle does by being trusted using the hash and key avoids the need for each node to verify the transaction but only the oracle’s permission to execute it.  The oracle is a solution that extends the development of smart contracts on the Ethereum platform but unfortunately also introduces additional security and latency concerns. 

The issue of privacy as it relates to smart contracts on a public Ethereum based distributed ledger entails another misconception.  Financial transactions based on private contracts are highly confidential.  It is the expectation of parties in such a transaction that the information on these transactions would remain secret.  However, among the advantages of a public distributed ledger is the transparency that it provides.  Obviously, the requirement for privacy and the transparency provided by the technology are at odds.  The ability to hide the information contained in a smart contract from other parties is still limited when each node in the network ultimately maintains a copy of the ledger.

How can a private permissioned implementation of blockchain overcome these challenges?

There are major design differences between these public and private platforms.  While a private ledger may violate Nakamoto’s vision they do provide a more pragmatic approach to deliver the promised efficiencies and cost savings.  By utilizing Proof of Work as the consensus methodology, public ledger solutions suffer latency in transaction execution.  Whereas private ledger solutions that utilize Proof of Stake or Proof of Authority attempt to overcome this issue by reaching consensus on the transaction level.

One interesting development in 2017 was Quorum which is an open source private ledger built on Ethereum and co-developed by JP Morgan, a member of the Ethereum Enterprise Alliance, and an Ethereum startup called EthLab.  This solution integrates both public Ethereum and a private ledger which may herald the future vision of blockchain.  It recognizes the need for a private ledger for certain use cases, such as financial transactions, yet maintains interoperability with the public ledger as well.   To maintain privacy only parties with the appropriate key can view the private transactions. 

Now let’s consider Hyperledger Fabric, also an open source implementation that differs greatly from public blockchain platforms such as Bitcoin or Ethereum.  The platform is designed to be modular which provides for an approach to build more complex applications integrating different actors into a business case.  Perhaps the most important difference is the method of consensus.  By allowing consensus to be achieved through multiple methods it provides the ledger the ability to reach consensus on a transaction level and based on the relationships between the various nodes in the network.  It also avoids the need for mining and some of the issues with latency and scalability.  The importance of this feature also provides the platform the ability to assign distinct permissions to different nodes.  Thus, allowing for the ability to assign permissions to specific smart contracts and to allow for different nodes to play different roles within the process.  In Fabric, smart contracts are written as chaincode, which controls the transactions executed on the ledger.      

Finally, we will consider R3 Corda, another private permissioned platform that is designed specifically for the financial services industry.  Like Fabric, Corda utilizes Java as the smart contract development language.  Like other private ledgers, Corda resolves the issue of privacy by reaching consensus at the transaction level as it is designed to allow only those nodes that are parties to a transaction to share and reach consensus on a specific transaction. Unlike other private ledgers, consensus on Corda is reached based on two factors including validity, where all signatures are checked, and uniqueness, using special notary nodes, which avoids the potential for double-spend i.e. the selling of the same asset twice.  In terms of smart contracts Corda provides an additional feature of integrating legal prose by maintaining a link between the smart contract and the legal language of an actual contract and adding enforceability.  This feature was utilized in the proof of concept work with ISDA on swap master agreements.  Corda also allows for the definition of specific regulator nodes that have specific permissions which also a unique feature and important to consider for any highly regulated industry such as financial services.   

Summary

Over the past several years Blockchain has grown in prominence and has become more recognized as a potential game-changer for many industries including financial services.  Whether we are considering blockchain in a way that maintains the vision of the Bitcoin creator Satoshi Nakamoto using Ethereum or perhaps a more pragmatic approach using solutions such as Hyperledger Fabric or R3 Corda clearly the technology, including smart contracts provides great promise for the future of financial services.  I believe that 2018 will bring continued incremental advances to the technology.  While we will see an increasing number of implementations of private ledgers across various industries we will also see many organizations reconsider approaches to implementing blockchain.

One direction that enterprises may turn is toward Quorum the open-source private version of Ethereum that JP Morgan co-developed and announced in 2016.  JP Morgan released an interbank payments platform based on Quorum in October 2017.   This approach of integrating the popular public ledger, Ethereum, with the benefits of a private ledger are at the very least intriguing.  The growth in membership of the Ethereum Enterprise Alliance in 2017 underscores the interest blockchain technology has earned.  The progress this alliance has on developing standards will also be worth watching. 

Another trend to watch in 2018 is the consolidation of a fragmented marketplace.  Enterprises will make decisions on which platforms they will decide to continue developing production solutions.  Interoperability with other blockchain solutions and participants will become an increasingly important consideration.  I would expect that the open source solutions that have the most mature ecosystem would stand the best chance for success.

Finally, the new year should also bring the more pragmatic solutions to the forefront, which should bode well for platforms such as Hyperledger Fabric and R3 Corda, as well as, those vendors that can deliver solutions to some of the blockchain challenges that exist today.