Agreeing to Disagree: Interoperability in a World Without Compromise

I made a mistake when we designed Corda. I thought the attractions of an Ethereum mainnet-style ‘shared global network’ were so obvious that enterprise blockchain projects would follow the same model. But it turned out that every successful project wanted to run its own separate network. Looking back, they were right to do so! But it means we needed a new approach to interoperability. And two major milestones in 2023 will deliver it. 

Richard G. Brown, CTO at R3, 2023

Isn’t it amazing how well the Ethereum mainnet works? All those independent applications co-existing and interacting. A veritable Lego box of possibility that innovators can endlessly assemble and reassemble to solve hitherto unanticipated needs. Indeed, the entire basis of the DeFi revolution was the ability for contracts written by different people to ‘snap together’ seamlessly. We call this concept ‘composability’, and it is an under-recognised source of Ethereum’s success. 

When we designed Corda our aim was to achieve something similar for firms whose constraints – regulatory, privacy, performance – meant they couldn’t use a permissionless network but who nevertheless saw the benefits of doing business on a globally shared ledger, in synchrony with their trading partners. 

Corda has supported different contracts interacting directly with each other from the very first release in November 2016. And it’s why we established the Corda Network Foundation soon after to build a global Corda Network onto which these different applications could be deployed. 

But we soon began to notice something that we found quite vexing: every project wanted to have its own private ‘section’ of the Corda Network. They absolutely did not want some random third parties coming along and using their application in ways they hadn’t anticipated. We saw the same thing happen with the other enterprise blockchain platforms too.  

At first, I thought this was merely a problem of education. There were subtle privacy considerations that made it attractive to run standalone Quorum or Hyperledger Fabric networks, but Corda was explicitly designed to avoid these issues. Perhaps our customers just didn’t realise? 

I spent a lot of time explaining to customers why I thought they were wrong and wrote lengthy blog posts explaining what bad things happened if you weren’t prepared to share a network with other projects. Here’s an article from that time: 

I must have spent so many hours patiently explaining to my best customers that they were wrong about the future. They mostly found this quite annoying. 

Now, I’m not completely stupid. I did realise that telling a customer who asked for ‘X’ that they were mistaken and should actually be asking for ‘not X’ is an unconventional approach to relationship management. But there was also a vitally important engineering reality at stake: the Ethereum-style seamless application composability relies – in a fundamental way – on having all in-scope applications running on the same network. 

This insight – that ‘composability’ is extraordinarily valuable but works best when everybody is on the same network – was so important that I even went so far as to coin phrases, like ‘Universal Interoperability’, to explain to users of ‘enterprise blockchains’ why they had to get on board with the idea of running their applications on shared networks. This was self-serving on one level – only Corda could safely operate in this manner. But the fact it was true didn’t matter: customers absolutely did not want to do share networks. 

This triggered a lot of soul-searching and analysis. Why would projects be willing to share a network in the adversarial world of public crypto, but not be willing to share a network in the more controlled and regulated world we were building? 

I think there were two main reasons:

1. First, there is the need to get very comfortable with risk and uncertainty: if you deploy a contract to a shared network you do have to accept that it will move some way out of your control. Somebody might use it for things you haven’t anticipated. Somebody might find a bug. Maybe they will exploit this bug. This is not a theoretical concern. These things happen, repeatedly, on public networks. Like all the time. Yet the benefits that arise from having a shared ecosystem of contracts on the same network evidently exceed the scary security costs that go with it in the permissionless case. But users of permissioned networks didn’t see it the same way, at least not in the early days.   
    
   
2. Secondly, the direct implication of being on the same network as other parties is that you’re subject to the same rules as them too. You all have to agree on a huge number of arcane things: what is the minimum version of the protocol you’re allowed to use? How large is the largest permissible transaction? Who gets to decide if transactions have been confirmed or not? If there’s an identity verification service, who runs it? 

The answers to these questions can have far-reaching implications. If you’re on the cutting edge you may have to wait until a product feature, you need can be activated. If you’re a slower mover, you could find yourself forced to do a disruptive upgrade merely to stay in business. What happens if the identity verification service makes a mistake? Can you sue them? Can somebody sue you? Having your business strategy dictated by people over whom you have no power or influence can be scary place to be. 

Yet these questions of collective governance are unavoidable when running on a shared network, and everybody may have their own preferences as to the correct answers. Everybody has to find a way to agree.  On the successful permissionless networks, somehow, miraculously, they do! Yes – there is the occasional dispute, that sometimes leads to a schism within the community. But it’s interesting how rare such situations are in practice. 

What we found in the enterprise space, however, was that the dynamics are completely different. And so, each enterprise blockchain project – on any of the major platforms – has typically deployed to a separate network. 

This wasn’t a problem at first. My fears of chaos didn’t come true. This was because most projects were 100% focused on getting live, onboarding users and delivering value. Unlike public networks where DeFi became an end in itself, with composability as the enabler, private networks took a different path, focused on first making each individual project successful in its own right. 

But we’re now at the point where these projects, using a variety of open platforms, do need to be able to interact with each other. And they need to do this without risk of vendor lock-in or building platform-specific walled-gardens. Is their decision to deploy to different networks going to bite them, and do so big time? Happily, no! And this is thanks to two distinct projects, both of which will deliver real impact this year, and both of which are relentlessly focused on driving open, trusted interoperability. 

The first project is a new interoperability protocol focused on the needs of regulated networks. This work has been trailblazed by several firms at the forefront of getting real-world enterprise blockchain platforms to work well together. HQLAx, running on Corda, and Fnality, running on Hyperledger Besu, an Enterprise Ethereum platform, were the first projects to reach the point where they needed to connect their applications. HQLAx is a sophisticated regulated digital asset network used by large financial institutions, and Fnality is a private-sector Central Bank Digital Currency (CBDC) platform. Each of them solves a pressing problem for large banks. But neither of them has an end-to-end solution for some of the problems these banks are trying to solve. For example, some HQLAx customers want to settle their trades in a high-quality cash instrument, such as the one provided by Fnality.  

This creates a need for a very specific type of interoperability: ‘atomic’ transactions between the two platforms. This is not a typical problem that anybody needs to solve in the permissionless space, since contracts typically only interact with contracts deployed on the same network. There was no direct prior art anybody could build on, so their engineers prototyped a solution. Earlier this year, tech firms including R3 and Adhara, joined the effort. This project has now reached the point where we are contributing our learnings to the broader Hyperledger interoperability initiative. A really powerful example of practitioners in the industry, facing real business problems, engineering a solution and donating it to the community for broader benefit.  

And the second project is the Next Generation of Corda itself. We never gave up on the dream of true seamless composability of enterprise blockchain contracts. The challenge set to the engineers building Corda 5 was: can we deliver the high-fidelity composability so beloved by users of permissionless networks, but do it in a way that works across differently governed networks, and which can be used to compose valuable enterprise solutions from existing applications? 

The design rests on an interesting insight that applies to those wanting to connect enterprise applications together: usually both parties in a transaction are represented on both networks. This opens up a design space that seems to have been previously overlooked and has allowed the Corda 5 team to come up with a composability solution that can span networks. It is to my knowledge unique. We’re going to trial it in a forthcoming release of Corda and, once we’re sure it works, we’ll work with the industry to extend it to any enterprise platform. We’re pretty sure that the concepts are universal. 

In 2018, I wrote that: 

“The win comes when we break down silos; when we enable data and assets to move without friction; when we avoid duplication; when we eliminate reconciliations and unnecessary integrations.” 

Richard G. Brown, CTO at R3, 2018

But my vision depended on everybody running on the same network. Five years later, thanks to the diligent work of the Corda engineers and unprecedented industry-wide cooperation, we have two complementary solutions coming to market in 2023 that deliver this promise but without forcing you to deploy your applications on networks you don’t control.