Open interoperability and the future of enterprise blockchains
[gpt3]rewrite
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 understandably sparked a new wave of criticism of the entire concept. These attacks are often unfair: contrary to popular belief, there are several highly successful projects that deliver real value day in and day out, across multiple platforms. But one of the attacks requires a thoughtful response: Enterprise blockchain networks tend to be deployed as separate networks for each application, rather than large-scale shared networks, as is popular with permissionless chains. It turns out that there are good technical reasons for this, but the critics are right to point out that it obliges us who build such networks to explain how they should cooperate 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 going? 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 see each project from two perspectives.
First, each enterprise project is typically its own stand-alone network, solving a real and valuable problem: supporting high-value transactions, typically between banks and regulated financial institutions. This means that deployment takes time and that they are subject to strict rules and obligations to ensure that they work and do not undermine stability. As a result, they can often lack the same freedom of movement as public or permissionless decentralized contracts. So they are usually built and operated, at least initially, as their own networks.
Second, however, they were not intended to be stand-alone networks. Rather, the ‘end vision’ is that they connect to each other, solve different problems, but still retain the ability to openly and freely interact with other blockchain networks worldwide, regardless of the platform they are based on.
The industry is certainly starting to move the needle on interoperability. Take Fnality and HQLAX, for example – two separate blockchains running on the Enterprise Ethereum and Corda platforms respectively, which successfully interoperated with each other for cross-chain repo swap settlements last year. Or the Hyperledger Cacti Project – a multi-faceted interoperability platform that is gaining attention.
But perhaps we should also take a step back. Is there really any reason why different networks use different technologies and thus need to solve the interoperability problem? And what exactly is the business driver anyway?
First, the technical angle. Blockchains operate 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, for example – have different strengths and weaknesses. So different projects have legitimate reasons to use different technologies. And since consensus is designed to work naturally, 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 connect the networks in a reliable and secure way.
Forge the path to interoperability
From a business perspective, the need for interoperability comes very naturally from the need to solve two specific problems:
1. Asset bridge – Asset bridging occurs when a user wants to move an asset from one ledger to another. This is usually achieved through burn-mint or escrow-mint mechanisms, where each network behaves in tight synchronicity, coordinating between depositing or burning the digital asset on one network and minting the same asset on the other network. Whenever an asset is ‘bridged’ from one network to another, there is a need to securely immobilize the asset on the source network in lock-step with its reappearance on the destination network. With this in mind, it is crucial that such bridge construction is carefully designed and tested. The need to ensure that the asset exists in exactly one place at all times – and that the immobilized asset cannot be taken harmfully – is critical.
2. Atomic exchange – Sometimes – and this is surprisingly common in the corporate environment – there is a need for it Exchange assets that exist on different networks. For example, I may 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 different networks, where each asset never leaves its own network. The exchange must be “atomic”: both one-way transactions must either complete or clearly fail in their entirety. In this case, a “failure” of the exchange can be seen as a feature and not a bug, as this eliminates the dangerous and potentially costly result of only part of the transaction completing.
One chain at a time
The long-term vision of the enterprise blockchain industry is not – and was never meant to be – dominated by a small number of market players. Rather, it is better thought of as an interconnected “network of networks” across multiple DLT platforms.
In addition to a technological challenge, successful and secure interoperability needs open and active collaboration – not just within ecosystems, but across them. By working together and leveraging firms and individuals with market and technology expertise, we can achieve the ultimate end goal of enabling market participants to control their assets across different networks securely, seamlessly and in a streamlined manner.
Follow me on Twitter or LinkedIn.
[gpt3]
