The future of enterprise blockchain depends on the ability of different networks to work together seamlessly in a standards-based, open way.
The recent high-profile demise of some enterprise blockchain projects triggered an understandable new wave of criticism of the entire concept. These attacks are often unfair: contrary to popular perception, there are multiple highly successful projects delivering real value day-in day-out, on multiple platforms. But one of the attacks demands a thoughtful response: enterprise blockchain networks do tend to be deployed as separate networks for each application, rather than on large-scale shared networks as is popular with permissionless chains. It turns out there are good engineering reasons for this, but the critics are right to point out that it obliges those of us building such networks to explain how they are going to interoperate with each other, with as little friction as possible.
From ‘Nice To Have’ To Necessity
Having worked in enterprise blockchain for nearly a decade, one of the questions I often get asked is: where is this all heading? I think the best answer is that we are witnessing the emergence of an open, connected network – of networks.
A useful way to think about this is to view each project from two perspectives.
First, each enterprise project is typically its own standalone network, solving a real and valuable problem: supporting high-value transactions, typically between banks and regulated financial institutions. This means deployment takes time and that they are subject to stringent rules and obligations to make sure they work and don’t undermine stability. As a result, they may often lack the same freedom of movement as public or permissionless decentralised contracts. So they are typically built and operated, at least initially, as their own networks.
Secondly, however, they were not intended to be standalone networks. Rather, the ‘end vision’ is that they connect with each other, solving different problems but nevertheless retaining the ability to openly and freely interoperate with other blockchain networks across the world, irrespective of which platform they are based on.
The industry is certainly beginning to move the needle on interoperability. Take Fnality and HQLAX, for example – two separate blockchains running on Enterprise Ethereum and Corda platforms respectively, that successfully interoperated with each other for cross-chain repo swap settlement last year. Or the Hyperledger Cacti Project – a multifaceted interoperability platform that is gaining attention.
But we should perhaps also take a step backwards. Is there really any reason why different networks use different technologies and hence need to solve the interoperability problem? And what, exactly, is the business driver in any case?
First the technical angle. Blockchains function based on unique rules, known as protocols, which include a method for reaching network consensus on transactions in a secure manner. And different platforms – Corda and Hyperledger Besu, say – have different strengths and weaknesses. So different projects have legitimate reasons for using different technologies. And since consensus is designed to work natively, transactions to other networks often cannot be verified through the protocols of the existing blockchain and so we need a way – an interoperability protocol – to link the networks in a reliable and secure way.
Forging The Path Towards Interoperability
From the business perspective, the need for interoperability emerges very naturally from the need to solve two specific problems:
1. Asset bridging – Asset bridging occurs when a user desires to move an asset from one ledger to another. This is typically achieved through burn-mint or escrow-mint mechanisms, where each network behaves in tight synchronicity, coordinating between the escrowing or burning of the digital asset on one network and the minting of the same asset on the other network. Any time an asset is ‘bridged’ from one network to another, there is a need to securely immobilise the asset on the source network in lockstep with its re-appearance on the destination network. With this in mind, it is paramount that such bridging is carefully designed and tested. The need to ensure the asset exists in precisely one place at any time – and that the immobilised asset cannot be nefariously taken – is of critical importance.
2. Atomic swaps – Sometimes – and this is surprisingly common in the enterprise setting – there is a need to exchange assets that exist on different networks. For example, I might agree to send you a digital asset if and only if you send me payment for it. An atomic swap is the simultaneous exchange of two digital assets, each on distinct networks, each asset never leaving its own network. The swap must be ‘atomic’: both one-way transactions must either successfully complete or clearly fail in their entirety. In this case, a ‘failure’ of the swap can be seen as a feature and not a bug, as this eliminates the dangerous and potentially expensive outcome of only one leg of the transaction completing.
One Chain At A Time
The long-term vision of the enterprise blockchain industry should not – and was never intended to be – dominated by a small number of market players. Rather, it is better thought of as an interconnected ‘network of networks’ on multiple DLT platforms.
As well as a technology challenge, successful and safe interoperability needs open and active collaboration - not just within ecosystems, but across them. By working together and tapping into firms and individuals with market and technological expertise, we can reach the ultimate end goal of empowering market participants to control their assets across different networks securely, seamlessly and in a streamlined way.
