Interoperability between blockchains is important. In a survey conducted during a pilot of the Canton Network, the 45 leading financial organizations that took part agreed. 100% of participants responded that the interoperability of blockchains and assets is either ‘very important,’ or ‘extremely important’ to drive the next phase of adoption and value from blockchain and smart contract technology in capital markets.

In the real world, we have activities that span multiple blockchains: the classic example being the exchange of assets for cash in a Delivery versus Payment (DvP), where assets and cash are on different blockchains. These blockchains can be public, private, layer 1’s, layer 2’s, or any combination of these. Without interoperability, blockchains are isolated silos with utility limited to what can be done within each.

The Canton blockchain supports all kinds of interoperability, and can interoperate with other blockchains in the same way as everyone else. In addition, Canton’s protocol addresses the connectivity limitations of other chains with a unique approach to interoperability that enables multiple Canton blockchains to transact atomically without having to compromize on threshold issues around privacy or sovereign control over your business and data. I’ll say more about that later.

But regardless of technology choice, there are different kinds of interoperability and different types of connectivity, which come with different tradeoffs. We need to understand these and make sure that we implement solutions that use distributed ledger technology (DLT) in transformative, value adding ways. Otherwise we run the risk of re-creating the old way of doing things, just with some DLT added into the mix.

There’s a lot of hype, and possibly a fair amount of misinformation, around the idea of interoperability between blockchains. So let’s start by deciding what we mean by interoperability. Here are three broad definitions on the approaches we see in the market today:

• The ability to integrate. In other words to expose an API, receive a message or similar, such that it is possible to perform reads and writes across systems. I’ll call this integration interoperability. All blockchains support this, so at this level they are all ‘interoperable’.
• ‘Crafted’ atomic transaction interoperability. The ability to perform atomic transactions across chains for a specific scenario through the crafting of a bespoke solution. An example is a token transfer service that allows a token to be burned on one chain and minted on another.
• ‘Generalized’ atomic transaction interoperability. The ability to have a generalized approach to performing atomic transactions across two or more systems, without the need to craft a solution for each scenario. This is what we are aspiring to and has the most value. From a technical perspective, it means that only business logic needs to be codified, and that transactional atomicity “just works”, regardless of business logic complexity or the number of parties involved. From a business perspective it removes risk (such as settlement, counterparty and liquidity risk). Equally importantly though, it means that new systems with new applications can be “plugged in” to an ecosystem and simply used, without significant development effort.

Blockchain aside, we’ve been integrating computer systems with APIs and messages for decades. If achieving true atomic transaction interoperability between systems were possible through APIs, message-based systems, or bridges, then wouldn't we have cracked it by now?

It’s important to remember that blockchains are just computer systems that you communicate with via messages and APIs. In that critical respect they are no different to the systems of today. Blockchains do not have some special property that makes generalized atomic transaction interoperability between them possible, nor does third-party tooling bring it. Building a solution on a blockchain will not give you crafted or generalized atomic transaction interoperability with other blockchains, even if you share the same technology stack or use some third-party tooling. It will give you another system to integrate with using APIs and messages.

While crafted atomic transaction interoperability is appealing because it's akin to how we plug systems together today, it erodes one of the core value propositions of blockchain technology - namely to have a distributed ledger where all participants are guaranteed to be in sync. We already have whole industries, software categories, and service providers dedicated to systems integration. The capital markets industry is full of complex processes around data transfer and reconciliation. Crafting interoperability between blockchain systems will ensure that this complexity, need for reconciliation and inherent risk in the system remains at large. The digital asset ecosystem is a rich tapestry of different protocols and approaches. There is absolutely a place for this type of integration to bridge different ecosystems. But to unlock the full value and potential of the technology, achieving generalized atomic transactions is the only way to deliver on the promise. Only the Canton protocol achieves this.

But what about bridges?

Bridges offer cross-blockchain messaging, they coordinate calls to the APIs of different blockchains. To build a bridge you have to:

• Agree on protocols and messages between blockchains bilaterally
• Rely on implementations on both sides matching and being correct
• Safeguard with reconciliation and exception handling.

Tooling from numerous providers can assist in relaying messages between blockchains, but ultimately these tools are all different forms of bridges. In many ways they are similar to the service buses of the non-blockchain world.

In addition, bridges often introduce new counterparties (and hence risks) for relaying and verification. They are highly complex and error prone (more risk). If you are in any doubt about this then just search online for “blockchain bridge hacks”.

Bridges are a long way off generalized or even crafted atomic transaction interoperability. They can, with effort, help deliver crafted atomic transaction interoperability, in much the same way that this can be achieved today with traditional systems and a service bus.

A common misconception is that a bridge won’t be needed between chains that share the same technology stack, but this is only true of Canton and no other blockchains. To give some examples, you need a bridge in all these cases: Besu - Polygon; Fabric - Avalanche Private Subnet; Corda - Ethereum; Canton - Ethereum; Corda - Corda; Besu - Besu; Polkadot Parachain - Polkadot Parachain; Avalanche Private Subnet - Avalanche Private Subnet.

But what about HTLC?

Maybe you’ve heard great things about hash timelock contracts (HTLC). Aren’t they the magic that makes cross blockchain, generalized atomic transaction interoperability possible?

HTLC’s are widely used in DeFi, because they allow crafted atomic transaction interoperability in specific low trust scenarios such as two parties exchanging Ethereum and Bitcoin. HTLCs solve the problem of needing a trusted third party in a cross-chain transaction between two participants. But that is a different problem to providing generalized atomic transaction interoperability with arbitrary smart contracts and an arbitrary number of participants.

In addition HTLCs rely on bridges to work and therefore are subject to the same challenges, risks and hacks. Even though in theory they remove the need for trusted third parties, their implementation can be complex and often ends up needing one (typically to run bridge components). If your process has a trusted third party then you probably don’t need the additional complexity of HTLC.

How is Canton different?

The Canton protocol was built from the ground up to overcome the problem of interoperability between separate blockchain instances. This is achieved by supporting interoperability between different Canton instances at the protocol level, without giving up privacy or control - a unique capability - rather than having to bridge between the APIs of separate instances. This unlocks generalized atomic transaction interoperability, not just between two instances, but between as many instances as needed. Smart contract code only specifies business logic, there is zero bridging or interoperability crafting code, and the protocol guarantees transaction atomicity.

There are many reasons why regulated organizations may want to run their own instances and leverage interoperability between them, rather than putting everything on a single shared chain. Fundamentally though it usually comes down to:

• Control: who participates, who governs, what are the service levels, what are the costs, is there independent ability to scale?
• Privacy: who sees what?
• Regulatory compliance: does this meet regulatory requirements?

Summary

With the exception of Canton, generalized atomic transaction interoperability between different blockchains is not possible. This challenge is just a manifestation of a problem we have faced for decades in the non-blockchain world. If that challenge were easy to solve, we would have done so many years ago.

Getting close to crafted atomic transaction interoperability is possible, but it takes effort to deliver for each scenario, and gets really complex if there are more than two endpoints involved. Tooling may help us but this tooling is similar to the service buses of old and should not be mistaken for a solution for generalized atomic transaction interoperability.

Integration interoperability sets the bar so low that all blockchains can be said to be interoperable, but if we define interoperability at this level it has no meaningful value.

When building blockchain solutions, we need to be aware of these realities. Sure, we can do crafted atomic transaction interoperability, in much the same way as we have done for decades with traditional systems. We must be careful therefore not to think that blockchains and their associated tooling make interoperability easy. If we make that mistake, we run the risk of doing nothing more than replacing old systems of record with blockchains, whilst retaining all the complexity of API and message based integration that we had before.

To find out more about the Canton Network, download Capital Markets take Flight, which provides further insights into how 45 leading organizations from across the Capital Markets industry demonstrated generalized atomic transaction interoperability in the industry's most comprehensive pilot to date.