Not all business blockchain platforms are alike. To succeed they need to reimagine business computing.

Lessons from the world’s largest multi-year collaborative Blockchain research programme

If you’re not part of the blockchain bubble, you probably think people in the blockchain world are all mad! Especially those of us in the enterprise space. How on earth could we believe a technology, originally built by a group of idealistic anarchists to solve a problem no financial institution actually has, could possibly be relevant to the challenges facing those trying to build and maintain complex IT infrastructures across the world?

In this article, I explain how the work we’ve done at R3 over the last two years with hundreds of senior technologists from dozens of leading financial institutions has led me to some fundamental conclusions:

  • The promise of blockchain technology is real: new business solutions will soon be deployed which can eliminate huge amounts of cost, redundancy, error and needless reconciliation across entire business ecosystems, as well as opening up previously hidden new revenue opportunities. I provide concrete examples below.
  • This will be achieved by applying the fundamental blockchain insight: “I know that what I see is what you see”. This is the key to helping us move from a world of isolated, custom, inconsistent IT infrastructures in each firm, to one based on shared business logic, securely shared data, and common processes.
  • The new IT architecture that is needed to capture these opportunities is one that converges the complex world of application servers, messaging engines, workflow managers and databases into a unified, secure and private design that works seamlessly within and across enterprises.
  • But not all blockchain platforms are alike: Only some designs will be architecturally suited to the challenge.
  • Our research has revealed several key characteristics that are needed to succeed. An enterprise blockchain platform must:
    • Provide an integrated application, messaging, workflow and data management architecture.
    • Build on an existing technology “mega-ecosystem” to maximise skills and code reuse.
    • Eliminate unnecessary data “silos” to unlock new business opportunities by allowing real-world assets to move freely between all legitimate potential owners.
    • Embed legal entity-level identification into the programming model to enable legally enforceable and secure transactions.
    • Support inter-firm workflows for negotiating updates to the shared ledger to support real-world business scenarios.
    • Enable the inevitable move to the public cloud without requiring high-risk technology bets.

For the last two years, I’ve been privileged to lead an intense research and development effort amongst the membership of the most vibrant consortium the financial world has seen. Hundreds of senior technologists from dozens of companies have worked with R3’s engineers to identify where blockchain technology can make a difference in large enterprises and also how it needs to be designed to achieve this potential.

This work has convinced me that the judicious application of key blockchain principles is key to rescuing the world’s banks and other large companies from the corner into which they have painted themselves after decades of investment in previous generations of technology.

In particular, we could be looking at the holy grail of enterprise software: convergence of application servers, messaging engines, workflow managers and databases in a way that works seamlessly within and across businesses.

The result is a model that delivers on the promise of blockchain in the enterprise: a world where applications can be securely developed and deployed across trading partners, enabling them to transact securely and accurately and without endless reconciliation, inconsistent data, and duplication. It is why we are now able to think about building or replacing payments systemssyndicated loans processing systems, asset issuance and custody systemsFX matching business processes and much more.  And these are just examples from the banking sector being addressed by just one platform, Corda, which itself turns out to be applicable far more broadly, in areas as diverse as healthcare and identity management.

But our belief is that it is only by converging previously diverse technologies that we can dramatically simplify how companies develop, deploy and manage applications that manage their business relationships with each other.

Here’s what I mean. Through one lens, a blockchain is like an application server: it hosts business logic and ensures it runs at the right time and for the right reasons. But a blockchain is also like a messaging engine: it allows people and, importantly, their computers to exchange information and ensure that the right information gets to the right places in the right order – and to do so between companies as well as within. And some blockchain platforms also have characteristics of workflow managers; they help coordinate the activity of different parties across time and space to achieve some business outcome. And, of course, they can be akin to databases.

If we could somehow devise a platform that built on this insight and delivered a platform that could combine the function of these hitherto diverse technologies, and could do so in today’s adversarial security environment, with the necessary levels of privacy, and in a way that was easy to use and could reuse rather than replace what already exists, imagine how much simpler our future enterprise IT landscape would look!

But building a platform that combines these separate concepts is easier said than done. There’s a reason existing vendors haven’t already built something that delivers on this vision.  In what follows, I’ll share the output of the last two years of our work, which confirmed to me that, by judiciously weaving together existing technologies and key advances from the blockchain world, it is indeed possible. I highlight some of the specific, key design choices you need to make in order to achieve this convergence and hence unlock the massive opportunity to transform the IT estates of existing companies.

I will refer at times to a key output from our work: the open-source Corda platform. We developed it in parallel with the research effort I describe above and, as a result, it benefited from a huge amount of expert input from across the R3 membership. No other enterprise blockchain platform has enjoyed remotely the same level of expert input. But I also refer to other enterprise blockchains where contrasts are helpful, paying particular attention to one that has come to prominence of late, Quorum, because it makes some very different choices and hence acts as a useful comparison point. This is intended to help make some of the points concrete and draw readers’ attention to areas of legitimate disagreement.

The ideal enterprise blockchain is a next-generation application server…

First and foremost, the opportunity that blockchain technology presents to enterprises is the ability to write applications that are shared between those who use them to transact. The key idea is this: rather than you and all of your trading partners each writing an expensive application to manage your participation in that trading network, you write it once. We thus share the cost and effort, whilst each running our own instance of the application in order to maintain our own books and records.

But to enable this vision, we concluded from our research that we need features that are unavailable in traditional application servers but which are common in the blockchain world. One such feature is cryptographic chains of provenance for all data in the system. When freely sharing relevant data with your trading partners, you must take nothing on trust but verify all proposed updates to the shared application state. This is also why all consensus-critical code on the platform needs to be digitally signed so you know that the code that is running is the code that should be running.

And we need to enable as much reuse of skills and existing technology as possible: you don’t save money by throwing away all the existing technology you have or by forcing all your staff to retrain! So you should be able to write applications in languages that have as large a population of developers as possible. Working with our diverse membership, we concluded that Java is by far the most widely deployed language across the business world and so we focused on that ecosystem. There are almost ten million people in the world who have these skills. But we also found that large enterprises hunger to bring their infrastructures right up to the contemporary cutting edge, so support for techniques such as reactive programming, approaches like functional programming and new languages like Kotlin and others are also required.

In short, the ideal application server for the modern era is one built for security, productivity, data integrity and cost minimisation.

But don’t all enterprise blockchains do this? Actually, no. To see that, we can compare the approach we took with Corda – the result of our two year journey – with a competing blockchain platform such as Quorum.  Although superficially similar to Corda in the way it describes itself it is, in fact, a relatively small fork of an existing public blockchain platform called Ethereum – which was designed to solve a completely different set of problems. Quorum inherits all of the associated advantages and disadvantages as a result.

For example, rather than supporting a full range of modern and mature languages to suit different needs, for which there are abundant skills and existing libraries, as Corda does through its support for the Java Virtual Machine, Quorum only supports languages that run on something called the Ethereum Virtual Machine. The EVM is a young, purpose-built virtual machine maintained by a community primarily focused on executing cryptocurrencytransactions and associated business logic. No mainstream languages run on the Ethereum virtual machine. This raises obvious questions around skills and integration with heritage systems. But it also opens up serious new risks for those who try to apply Quorum to real-world business problems. For example, the most popular language for writing applications on Quorum has been repeatedly shown to be impossible to use safelysuffering from countless bizarre language features that have led to people losing real money.

Not all enterprise blockchains are alike.

The ideal enterprise blockchain is also a next-generation messaging platform…

However, as I argued above, the exciting realisation during our research effort with our member banks was that good blockchain platforms are also inspiration for how to rethink enterprise messaging systems. Messaging systems are used by big companies to link computers and applications to each other securely and reliably.

The need for this becomes acute when you talk about deploying shared applications betweentrading partners. The applications running on different firms’ nodes need to be able to communicate. We need all parties to be securely identifiable and to be able to communicate with each other near-instantly over the internet or private network, addressing each other by legal name.  It’s not good enough to take existing enterprise messaging platforms that let you communicate with an address or a queue; you need to be able to talk to a named legal entity, anywhere in the world.

In our work with the diverse group of technologists from across our membership, we identified that the way to achieve this was to take existing technologies – in this case, TLS, X.500 and more, and make them consumable and accessible to today’s application developers. It seems obvious when you think about it yet no mainstream platform offered it in this way until we supported it in Corda. It was necessary to weave insights from the cryptography community, where public key infrastructure is well understood, and the banking community, where financial networks between identifiable peers are common, to come up with the idea of “send to legal entity” as the natural and obvious way to communicate between parties.

A separate finding from our work was that large institutions are institutionally allergic to anything that looked like it could create new islands of connectivity.  They needed a platform that would allow multiple independent Business Networks to operate within a single global namespace – perhaps something we could call a Compatibility Zone.  No more tolerance for isolated silos of communication and data distribution (unless you want it of course…). And this turned out to be key for the delivery of the holy grail: true representation of real-world assets on a shared network, with no artificial barriers to exchange or transfer, which I talk about more below.

Achieving this level of seamless interoperability across multiple business networks, whilst retaining flat, transparent, legal-entity-level addressing is hard. But I think we’ve achieved it with Corda.  And it’s something that is lacking in platforms like Quorum, where network membership is defined in text files which must be copied to each node, and where behaviour is undefined (or, rather, may have “adverse effects”) if they don’t match perfectly.

Identity and legal-entity addressing can’t be an after-thought in a text-file: they need to be designed in from the start.

The ideal enterprise blockchain is also a next-generation workflow manager…

When I worked with clients in my previous jobs, I would find they deployed workflow management tools, also sometimes called “Business Process Management” platforms, inside the organisation to control and optimise the flow of work between people and systems.

But all too often these systems would stop at the edge of the firm.  The “other side” was treated as a black box.  And yet, it is in the interaction between firms that the risk and cost creeps in.  Did they receive the message? Are they working on it? Did they understand it and process it correctly?

Do they see what I see?

This isn’t actually something that existing blockchain platforms provide much help for. And yet it is a real need even for some simple cryptocurrency transactions such as implementing an escrow arrangement or telling somebody how to pay you! In essence, for every meaningful transaction on a blockchain platform, there is usually an out-of-band negotiation flow that needs to take place.  Just like in real business.

And as we worked through countless use-cases during our research, what emerged was a need to make it easy for developers to write this back-and-forth business logic for the collaborative negotiation of a deal or construction of a transaction.

We discovered a need for an inter-firm workflow automation technology where developers don’t have to worry about any of the complex technical work necessary to orchestrate such co-operation at scale across a global network. In particular, it needs to be possible to define business processes that flow between, within and across firms, yet which can be coded in a simple and natural programming style, where you can express what each party in a transaction should do and have that work automated within and across your firms.

Unfortunately, developing something so ambitious would be hard if implemented from scratch. So it provided further weight to our emerging belief back then, a certainty today, that a successful blockchain platform for the enterprise has to build on the work of an existing, massive ecosystem, where it can reuse as much existing infrastructure and code as possible.

If we now turn to the specific case of Corda, we were able to take cutting edge technologies from the Java ecosystem and add some seriously clever engineering by the R3 engineering team to deliver something unique called the Flow Framework. In particular, recent advances in automatic checkpointing of business logic, with restore across system restarts, means developers can write what looks like entirely normal straight-line logic and yet, behind the scenes, a complex international workflow is being orchestrated. The first time you use it, it feels a bit like magic.  This is an example of why it’s so important to build on the foundations of an existing and robust ecosystem, such as that provided by Java, whilst at the same time bringing the programming model and tools right up to the contemporary cutting edge.

The ideal enterprise blockchain is also a next-generation asset ledger…

A repeated theme from our work with members was that the real wins come when the new enterprise blockchain applications become systems of record for real transactions.

This means they need to provide legal certainty.  Application developers need to link their contract code to associated contract legal prose to give certainty about how disputes will be managed.  But, for this to work, one must go further. Just as a successful enterprise blockchain identity layer needs to be based on legal names, the actual nodes – the machines running the business logic – also need to be clearly associated with a specific legal entity.

Such a framework, provided by the legal prose, identity-driven messaging and legal entity association with nodes, means that contracts signed on platforms that support it can be legally binding if you choose. It’s a prerequisite to being safely able, at scale, to support direct issuance of assets and the direct formation of contracts.

It means that a bank or other firm can issue assets (cash, equities, even commercial paper or syndicated loans) on to the ledger and have them be directly owned and seamlessly transferred to other members of an appropriate business network in near-real-time and with settlement finality.

And make no mistake: that is a hard trick to pull off.  For dematerialised assets to have full utility, they must be easily transferrable to any and all legitimate potential owners: isolated islands won’t do. So it turns out that this also has strong implications for the most fundamental aspects of the design: how data on the blockchain is managed, distributed and evolved, which I describe more below.

The issue we found during our research was that if you get this wrong, you risk trapping assets in silos, where they can only be transferred amongst members of a preconfigured list or through the involvement of third-party market-makers, or by asking the issuer to impose friction by cancelling and reissuing them.

It’s a tough problem to crack, as the link above makes clear in its analysis of another platform. The criticism in that link also applies to Quorum: they both suffer from this stranded asset problem and it means apps you write for those platforms will almost certainly have to be extensively rewritten in the future when those platforms are redesigned to correct these shortcomings. A costly prospect.

It’s one of the reasons we were so focused on delivering a version of Corda with “API Stability”: members and other developers told us loudly and clearly that they highly valued knowing they wouldn’t have to redesign their apps in the future

And the ideal enterprise blockchain is also first-of-a-kind decentralised database…

At the heart of the enterprise blockchain vision is the idea that, if two or more parties are transacting with each other, then they should all have an identical copy of the associated data.

“I know that what I see is what you see”.

To achieve this, we have to ensure that all parties have fully validated that their shared state was indeed calculated correctly.  At heart, it is this that distinguishes blockchains from what went before: we don’t take things on trust; we verify.  And to verify we need to run the logic for ourselves. We have to check the provenance of data.

What we want is, in effect, a globally shared database, but where each party only has the rows of the database that pertain to transactions they’re part of.  So we need to make sure that you receive the rows you need and if anybody tries to change any of them, they can only do so if the rules are followed and that you get to sign off on it and/or get notified afterwards as appropriate. To get an idea of how this works under one architecture, see this simple analogy.

The design we concluded that best achieves this is one that builds on and heavily extends and generalises ideas that originated in Bitcoin rather than Ethereum. This model, which Corda adopts, encourages developers to think of the fundamental units of information in their business problem and how they can evolve over time in isolation. Corda then adds the powerful flows I described earlier to orchestrate their updates via transactions that specify precisely which data units – “state objects” – are being referenced, created or replaced.

This approach allows for arbitrarily rich scenarios and sophisticated negotiations and business processes to be modelled with ease, whilst allowing the system to tell precisely who needs to receive what data, when, whilst revealing nothing more than is needed to prove provenance.

Other platforms take a different approach, based on an Ethereum-like model.  They typically start with the idea of an “everybody sees everything” full broadcast blockchain, representing a globally shared computer, and go fractal in order to correct for the privacy issues that result: they spin up tens or hundreds or thousands of separate mini shared-computers, one for each group that wants to transact in privacy. This approach can work but our analysis, confirmed by later experience, was that, for real world scenarios, it gets very complex, very quickly.

In the case of Quorum, each “confidential contract” can be thought of as a mini Ethereum universe that is visible only to the participants in that contract. This idea of millions of mini-blockchains works for some scenarios, but as I described in this post the approach, used by some other platforms too, fails completely if you ever need to support asset mobility. As soon as you need to prove provenance of one piece of data in a confidential contract to somebody else, you have to show them everything in that contract. Game over: you either lose privacy in the hunt for provenance or your assets are stranded, with their provenance impossible to be demonstrated to outsiders.

And… the ideal enterprise blockchain must also be designed for the cloud

The world doesn’t stand still. The enterprise software market in 2017 is different to the market in 2000…  In particular, most new applications that get deployed in the future will run in the cloud, increasingly in a public cloud.

So this was inevitably a hot topic of debate throughout the consortium’s deliberations over the last couple of years: how can we support application developers who need to write applications that will form legally binding contracts and be the basis of their audited books and records yet which will run on other people’s computers in a potentially hostile environment?

We considered the obvious options: zero-knowledge proofs, homomorphic encryption, secure hardware and more, and combinations of them all.

Our first conclusion was that the answer needs to be multi-layered: deterministic sandboxes, signing of all code and transactions, everything underpinned by legal-entity-level addressing, support only for a well-understood and tested managed runtime (in Corda’s case, the JVM, which we heavily lock down) and so forth.

But we also made a decisive choice: when weighing up risk, availability of skills, time to market and a collection of other factor, we concluded that the right initial approach is first to support hardware security technologies and, Intel’s SGX technology in particular.

This allows users to deploy Corda applications to other people’s computers (ie on public clouds) in a way that prevents those operators from interfering in transaction verification or accessing historical transaction information yet with no material limitation on the business logic that can be run. And we found that making this work well required it to be designed in from the ground up, which we did.

We concluded that this approach contrasted favourably with a higher-risk one being taken by platforms such as Quorum, who are recommending today the use of zero-knowledge proofs. Zero-knowledge proofs are a very fine piece of engineering and mathematics. They’re almost certainly part of the future of privacy in the long-term on blockchains – and Corda is designed to adopt them when they have matured.  But, today, the story is different.

First, and as Mike and Kostas in our engineering team discussed at CordaCon in September, the world of Zero Knowledge Proofs is young, very few people have skills, it is almost impossible to know what one of these things actually does when written and the security assumptions they rely on are unproven. Indeed, the “zk-SNARK” technology being promoted in February this year by the inventor of Ethereum is now being challenged by something new, called zk-STARKs This is a promising sign of a vital research community, rapidly advancing a young field.  But it’s a risky foundation upon which to build enterprise solutions before it has matured more.

Secondly, the integrity of the financial system rests on the idea of atomicity: related activities should either all happen or not happen at all. Inconsistent, half-complete exchanges just won’t do.

This requirement was hammered home to us by our members during the design process for Corda and so the ability to do complex atomic “payment versus payment” and “delivery versus payment” transactions is a fundamental part of the architecture.

Unfortunately, Quorum, which needs to use zero-knowledge proofs to achieve acceptable privacy in their system cannot, according to their own documentation, achieve delivery-versus-payment:

… the POC solution will not support cryptographically-assured DvP (i.e. atomic exchange of assets). This is because ZSL currently has no means of supporting shielded DvP-style functionality.”

This is why it’s so important to distinguish between the generic promise of enterprise blockchain technology and the practical reality of specific implementations.

Thirdly, we need to remember at all times that this whole emerging industry is about consensus, about being sure your counterparts really do see the same things you do and that you agree on all important data, when it happened and in what order.

But we learned from our members that how you reach this consensus may need to differ based on the business context: maybe you’re trading amongst a group of peers who you know well: you may each need to participate in the decentralised consensus forming process by running a node as part of a consensus cluster and reach consensus quickly and with finality amongst yourselves.  But, perhaps for some other line of business, you’re transacting with people all over the world and you want an independent, decentralised group of impartial observers to timestamp the transactions and help you reach agreement about ordering. That must also be supported: you need to be able to use a fully byzantine-fault tolerance decentralised cluster of consensus nodes, operated by mutually distrusting entities. And a successful platform needs to support all these modes – and more – and, here’s the key part: on the same network, at the same time!

So when we designed Corda, we engineered it so that you’re not forced to pick one consensus model and expect everybody to accept a one-size-fits-all for every transaction they perform on their blockchain network. That would be the road to disconnected, isolated blockchain networks… and the fast lane to stranded assets.

Why I believe Corda is the future of enterprise software

This piece began by outlining what I consider to be some of the critical findings of our journey so far. And we’ve embedded as many of them as possible into the design of the platform we jointly defined with this unprecedented consortium of institutions and the hundreds of technologists who so willingly gave their time to help us get it right.

It’s why I am so careful to stress that all enterprise blockchain platforms are not the same.

There is a reason Corda looks different to platforms like Fabric and Ethereum.  It’s because we’re not merely trying to take public blockchain technology – designed for a completely different purpose – and force it inappropriately into the enterprise. 

Instead, we’re doing something altogether more exciting and ambitious: we’re building the future of enterprise software. We’re tapping into one of the largest technology ecosystems ever seen, the Java ecosystem, and building on the work of countless thousands of skilled engineers to deliver an enterprise blockchain that’s designed directly to solve real problems faced by businesses today.

It’s why I believe the Corda enterprise blockchain is the future of enterprise software.

Indeed, firms like FinastraCalypsoHPE and others discovered Corda for themselves after reaching similar conclusions as us about what the right design for a consensus system between identifiable parties in a regulated environment needs to look like and our large and growing roster of partners, including Microsoft and Intel, is a testament to the momentum.

Perhaps I shouldn’t be surprised: we were immensely fortunate to have the deep and insightful input of literally hundreds of senior technologists from across dozens of the world’s largest companies help with the design. I hope one day to be able to list each and every one of them.

Indeed, I hope we will look back on Corda in a few decades as one of the largest and most successful collaborative design efforts in the history of enterprise technology!

Finally: a note on terminology. In this post I used the word ‘blockchain’ to describe Corda.  I tried for a long time to retain engineering purity (“Corda is very much like a blockchain and has chains of transactions but, strictly speaking, it doesn’t batch them into blocks – it’s real-time – so we probably shouldn’t call it a blockchain!”) But the reality is that the market uses the term Blockchain to describe all distributed ledger technologies, including ours. So I’m not going to fight it any more…!

Introducing Corda 1.0

Corda’s “API Stability” promise is an industry-first and means you can build on Corda with confidence. The roadmap for large-scale DLT deployment is now clear: it’s time to make your choice.

Corda 1.0 is here!

Corda – the world’s only distributed ledger platform designed and built from the ground up to record, manage and synchronise contracts and other shared data between trading partners – reached a critical milestone today: version 1.0 and, with it, core API stability.

API stability marks the point at which Corda’s contract with application developers is made firm: you can develop your applications on Corda 1.0 and, as we continue to enhance and mature the platform, you can upgrade with confidence, safe in the knowledge that the core APIs won’t change underneath you.

This is a critical landmark on the industry’s path to widespread adoption of enterprise blockchain technology and DLT and it is a promise that no other competing platform has made.

Build on Corda with confidence.

But why does this matter?

It matters because Corda solves a hitherto intractable problem in commerce.

The problem is easy to state and hard to solve. Every major firm around the world has built systems to manage their relationships and contracts with their trading partners. And each of their trading partners has done the same. Information is recorded by each of them multiple times, in multiple places, in multiple different ways and the information just never lines up properly. Each system is different. Each system has different bugs. And it costs an immense amount of money to keep them in sync and deal with the problems that arise when they’re not.

And this means that business leaders simply can’t move as fast as they need to in today’s world.

Here are some examples of the problem:

Corda is the only distributed ledger platform designed from the ground up to solve these problem by addressing the root cause.  With today’s version 1.0 release, we tell the world’s developers that it’s time to make your choice: build on Corda’s stable core API and create the next generation of distributed applications!

I wrote in 2015 that the wave of innovation that had been catalysed by Bitcoin was actually two phenomena: the emergence of decentralised crypto-assets and an entirely new way of solving a hitherto intractable problem in finance and commerce more generally. With Corda 1.0, this second blockchain revolution is now upon us.

With Corda, multiple parties who don’t fully trust each other can nevertheless collaborate to manage their shared data and this can have big implications for commerce.   It means we can envisage a future where I can look at my books and records and know, for sure, that what I see is what you see.

And if I can do that then we can transact in confidence, making business decisions in real-time, automating our joint activities with certainty: the promise of smart contracts. Facts recorded by the ledger can be regarded as authoritative rather than “shadows” of authoritative data held elsewhere, enabling settlement to take place directly across the platform.

Commerce without friction.

This is the opportunity Corda was designed for and, with Corda 1.0, the world’s developer community now has access to an open-source platform with a solid foundation that will take you with it as it continues to mature.

Corda’s unique design is the result of an intense period of research, development and design that included hundreds of senior technologists from across the global financial system, and the open source community, who have been actively engaged with Corda since we open-sourced it in November 2016.  Indeed, it was through our open source community that we discovered that Corda is applicable to far more than just finance! We’re seeing use-cases in government, insurance and beyond.

And, by working with experts and leaders at our extensive list of partners at firms such as Microsoft, HPE, Cognizant, Calypso, our community gains from the collective wisdom and shared learning that comes from a true collaborative community.

So why did the initiatives above (and so many more) choose to build on Corda, in many cases, switching to Corda after evaluating other technologies? We hear several reasons repeatedly given:

  • “My business problem is all about keeping records in sync with my trading partners and automating the activity that surrounds them.”
  • “My business dealings are complex; agreeing new terms requires negotiation… I need to be able to communicate back and forth with my trading partners.”
    • Corda’s unique flow framework makes it really simple to automate workflows between parties without writing complex event-driven code or dealing with asynchronous callbacks. No other platform has anything like Corda’s flow framework. The flow framework is what makes this decentralised, confidential netting solution so powerful.
  • “I need to integrate with existing systems easily.”
    • Corda writes its data directly into a relational database for you to query and uses well-understood and time-tested integration tools such as message queues (MQ) to move information around. Corda is built to integrate..!
  • “I need to deliver my solution quickly.”
    • Corda is designed for developer productivity. Developers can write their apps in Java – which over seven million developers know and the platform has been engineered for a thoughtful and delightful developer experience. This is enterprise software that developers actually like to use!
  • I don’t want to have to build the solution myself.”
    • Corda has a thriving ecosystem of software vendors and consultancies who have independently discovered the platform and are choosing to build their applications and delivery practices around it. Our partner team can introduce you to a firm who can meet your needs.
  • “I don’t want to be left on an evolutionary dead-end if I adopt DLT early.”
    • With Corda 1.0, you know your future is protected; you can upgrade to new versions of Corda and your applications won’t need to be extensively rewritten. What’s more, with 1.0, R3’s successful funding round, Corda’s large and growing open-source community and our extensive network of partners, Corda is now established as one of the few general-purpose DLT platforms that will still be standing when the market consolidates.
  • “I need my business dealings to be private.”
    • Corda is designed only to share data with those with a legitimate need to know – just the information needed to allow them to validate the provenance of facts on the ledger and no more: provenance with privacy. And Corda is designed from day one to work with Intel’s SGX privacy technology as it rolls out.

Get started with Corda today

So, if you haven’t already, now is the time to jump in to the Corda community and on LinkedIn.  The whole team is on slack.corda.net and you can get started here!

What Slack Can Teach Us About Privacy In Enterprise Blockchains

“Channels” in Hyperledger Fabric don’t work the way you think they do…

Corda and Fabric have very different approaches to delivering privacy. In this post, I compare the models, explain why Corda works the way it does and why I think the Fabric privacy model is flawed. It turns out this can have real-world costly business implications.

But first… let’s set up some intuition.

If you’ve ever used the popular messaging tool, Slack, you might recognise this message…

Slack

If you add a new member to a private channel in Slack, you have two choices: share your entire history or start a fresh, empty, channel. This works for interpersonal comms but it turns out it doesn’t work nearly as well for the “trust but verify” world of enterprise blockchains. 

This message reveals a fundamental truth: if you’ve shared lots of information in private with some people – on Slack or in an email thread, perhaps – then you have to be very careful about adding somebody new to that group, especially if you care about controlling what they can and can’t see. Remember that time you added somebody to a long “reply-to” chain, only to realise there was something at the bottom that you really didn’t want them to see?!  Undo! Undo!! Undo!!!

Famously, there’s no “undo” button on a blockchain, so we have to get things right first time.

In this piece I’ll explain how Fabric’s privacy design turns out to be very similar to Slack channels. However, it also turns out that a model that works superbly for Slack doesn’t work as well in the world of enterprise blockchains for some very common use-cases.

But first, some history.

When we began our architectural journey at R3, we examined a large number of platforms. We concluded that none met our needs and we embarked on the project that culminated in Corda, the industry’s only finance-grade enterprise blockchain platform.

One of the platforms we included in that initial evaluation and rejected as unsuitable for the broad range of needs of sophisticated financial institutions was the first version of the Fabric platform.

But that was then… and a lot of time has passed. It’s always valuable to revisit past decisions in the light of new evidence and, since Fabric has just reached an important milestone, now is a good time to look again.

One of the key changes since 2015 is the introduction of something called “channels”, intended to address the severe privacy shortcomings in the initial design. It turns out that Fabric channels are very similar to an idea we had considered and rejected as too limiting at the start of the design process for Corda.

In this post, I explain why we rejected this design for Corda and what I think some of the key problems will prove to be.

As we know, early blockchain designs sprayed data around the network and everybody received and processed every transaction. This is how Bitcoin and Ethereum work and it is, of course, a fundamental part of how they work.   It’s the right design for those public blockchain platforms.

But that design, which is perfect for those platforms, is just not appropriate for most problems in today’s enterprise world. So the first version of Fabric, which broadcast data globally like many other platforms of the time, had to be extensively redesigned.

The new solution adopted by Fabric is called “channels”. The idea is effectively to let you set up many, many “mini blockchains” – each of which is called a “channel”.  So you and I may share a channel. Perhaps Alice, Bob and Charley share another one. And maybe Alice, me and Ivor share another one.  It’s as if there are many little private blockchains where members of a channel can see everything in that channel but nobody else can.

Simple, right? Elegant, right?

Unfortunately, no.

My biggest worry about the design when we first considered – and rejected – it for Corda is that assets will get stranded.

Imagine you issue a bond to an investor in a private channel between you and them. Remember: the whole point is that it’s private so you wouldn’t want anybody else in that channel. Why would you want them to know about your private deal?

And now you have that channel with your investor, you can use it to engage in some other transactions with them too.  Perhaps you use this bilateral channel to manage some records pertaining to some other deal you’re working on together.  Or maybe they’re also a customer of yours and you want to manage a complex order.  There will invariably be lots of different pieces of information in a channel – different deals, trades, records – all being managed together and commingled.  And this will be repeated across all the other bilateral and multilateral channels in which you participate.

And, because of the nature of the programming and consensus model used by Fabric-style blockchains, all information in a channel inevitably gets commingled with all other information in that channel.  There’s no easy way to extract just some pieces, with history and provenance… a channel is an all or nothing proposition. This is intrinsic to how these sorts of blockchains work and is a reason Corda uses a totally different architecture based on individual “states” representing specific shared facts, each of which can evolve independently.

A good way to think about this problem is as if a channel is like a break-out room at a conference… filled with whiteboards and sticky-notes on the wall. If you’re in the room, you can see and understand everything… but if you were to just take one piece of paper out of the room, it would make no sense to anybody else because they’d need the full history of everything that happened in the room and all the other papers to understand it.

Or, rather, I thought that was a good way to think about it until I sent an earlier draft of this article to some colleagues for review and one of them pointed out that this is precisely what happens when you manage private conversations in Slack!

If you set up a private channel in Slack and then try to add somebody else, they get to see everything that went before.  Or… you have to set up a brand new channel where they get no history, no context, no provenance.  It turns out the Slack app even has a perfect error message that describes this issue:

Slack

Slack knows why a channel architecture is problematic for a distributed ledger

So imagine you want to take a bond you’ve bought from the issuer in that channel and sell it to somebody else.  How would you do it?

  • Well…. you can’t invite them into the channel, because then they’d see all your other private information. A non-starter.  It would be like inviting them into your secret breakout room and hoping they didn’t look at things they weren’t supposed to.
  • And you can’t easily just extract the pieces of history needed to prove the history of that bond, because everything is commingled.
  • And you can’t simply tell them you own the bond. Why would they believe you? The whole point of enterprise blockchains is that each party verifies the information it is given. This is what distinguishes enterprise blockchains from databases, after all.
  • I suppose you could ask the issuer to cancel the issuance in your channel and reissue it in the new buyer’s channel.  But now we’re getting a little bit silly. This would be indistinguishable from simply managing the assets on the books of the issuer. It would defeat the point.

This is not just theoretical: it could have real-world impact.

If it is difficult to move assets between channels with provenance, one has to resort to cumbersome workarounds. Workarounds such as introducing “market makers” who sit between channels and maintain liquidity in both. But this has real costs: additional people to trust, additional fees, additional liquidity needs…

How is Corda different?

As I’ve written in other pieces, we spent a TON of time on Corda’s design: the data model, the fundamental conceptual framework and, critically, our solution to the thorny problem of how to assure privacy whilst allowing parties independently to validate chains of custody and other shared data… the essence of what makes a blockchain a blockchain and not just an expensive distributed database!

Our design addresses the problems in this article head on: data is shared at the level of individual deals or agreements or trades or contracts, with only the transactions needed to verify provenance being shared and no more.  On top of this we layer anonymization and other privacy-enhancing techniques. These techniques build on top of each other. The need to prove provenance never goes away but we do our absolute best only to share the data that is needed to satisfy the recipient.

What’s more, we also built Corda to be able to use Intel’s game-changing SGX technology – without any changes to apps and with Corda’s famous developer-friendly programming model.  So I was delighted that we could announce our partnership with Intel earlier this month.

I’m massively optimistic about the potential of blockchain technology to solve real problems in business. Just make sure you fully understand the pros and cons and different tradeoffs of each before making your selection: as always, one size never fits all.

Post-Script

I should stress that I have a boatload of respect for our friends at IBM – and elsewhere. I think channels are a poor architectural solution but I value immensely the collaboration we have via the Hyperledger Project (where we are both premier members) and beyond.  And I look forward to deepening this collaboration further.   There is more that unites projects such as ours than divides us!

And I should also point out that the Fabric team do know about these issues. For example, see this recent Stack Overflow question:

“How do we enforce privacy while providing tracing of provenance using multiple channels in Hyperledger v1.0?”

The answer is: “At the moment there is no straight forward way of providing provenance across two different channels within Hyperledger [Fabric] 1.0”.

And the answer goes on to reference a design document for a fix. That link is to a very long and complex design document. That tells me that the design problem may be pretty fundamental and can’t be fixed easily. But it’s good news that it is being looked at. We all benefit when platforms develop and evolve and I hope to see significant improvements in this area over time.

 

Update

2017-07-20

IBM’s Dan Selman has taken me to task about this post!  He correctly points out that I didn’t say too much about Corda’s design:

This is because I’ve written about it extensively elsewhere but he’s right: I should have linked.  This video from our Developer Relations team gives a pretty good overview:

And the other videos are pretty good too!

What that video doesn’t say (but should!) is the key point: in real-life scenarios, the dependency tree for any given transaction is invariably a very small subset of the overall set of transactions and so this technique (lazy on-demand provision of just the directly-required dependency tree and no more) gives us the optimal balance.  It is enabled by the transaction design, where each transaction specifically specifies which previous state objects (“shared facts”, if you like) are being superseded.   Put another way: we explicitly declare which parts of the shared state are being updated (actually, replaced) and so we know precisely which proof needs to be provided by one party to another.

In the Slack analogy, it would be equivalent to being able to automatically “lift out” just the pieces of a shared conversation that were directly relevant to the new person you wanted to add to the chat, without also showing them parts of the shared conversation that they have no need to see.

A Simple Explanation of Enterprise Blockchains for Cryptocurrency Experts

And why R3’s Open-Source Corda platform is the one to watch…

We’re doing some really interesting engineering at R3 right now… We have Java running in Intel SGX… We’re hacking a JVM to make it deterministic… We’ve proved you can suspend threads of execution to a database and bring them back to life across restarts as if nothing happened… (We even got emojis to display cleanly on multiple different terminals….)

“It’s just so nice to finally see people doing software engineering in this space” (unsolicited comment at a recent conference I attended)

But why are we doing all this work? After all, public blockchains are red hot right now: prices reaching new highs, “Initial Coin Offerings” showing no sign of slowing and new innovations announced daily. Why is a strange firm called R3, which recently raised $107m to complete the build out of our open source Corda platform, heading off in what seems like a different direction? Aren’t we just building over-complicated centralized databases? Or solving a problem that nobody has?

To be honest, I thought the public blockchain community didn’t have much interest in our work… until Joel from our developer relations team visited San Francisco to deliver our Corda technical training. He had been nervous: many cryptocurrency ‘maximalists’ are West-Coast based… and he thought he would be in for a hard time.

Anyway… he needn’t have worried. The audience was the best he’d ever presented Corda to: uniformly respectful, engaged, questioning and inquisitive. And it made me realise: I’ve done a terrible job of explaining what we’re up to and why we’re taking the route we’re are.

What problem do enterprise blockchains solve?

I wrote about this in more depth when we first announced Corda but, in short, the story is simple:

  • In the beginning there was Bitcoin…
  • … and it was a revelation.
  • Not only because, for the first time ever, we had a censorship-resistant, confiscation-proof, scarce, digital bearer asset…
  • … but because the architecture that Satoshi built to give us this amazing gift taught us something we didn’t previously know. It taught us that:
  • It is now possible to build systems that are operated by multiple parties, none of whom fully trust each other, that nevertheless come into and remain in consensus as to the nature and evolution of a set of shared facts.
  • In Bitcoin, the set of shared facts are: how many bitcoins have been mined and what conditions govern how they can be spent?
  • Newer platforms, such as Ethereum, build on these ideas and expand the set of facts over which we’re coming into consensus; in Ethereum’s case: what is the state of a shared world computer?

As we know, Satoshi set a very high bar for Bitcoin. It works when you don’t know who most of the participants are and it lets miners come and go at will without anybody even knowing who they are.  Like I’ve long said, Bitcoin is a work of genius.

But a key point to stress is that those of us building enterprise blockchain platforms aren’t trying to build a better Bitcoin or even build a better Ethereum. (Why bother? They already exist!) Instead, the thing that interests us is the sentence above that I wrote in italics:

It is now possible to build systems that are operated by multiple parties, none of whom fully trust each other, that nevertheless come into and remain in consensus as to the nature and evolution of a set of shared facts.

This is tantalizing… because it suggests we could completely transform the economics and structure of entire industries. Not by introducing a new currency or decentralized governance model (that’s already being built out by the public blockchains, after all).  But by also massively improving the efficiency of what already exists.

If we knew that all parties were in sync, we could accelerate securities settlement, optimize supply chains, liberate assets stranded in one silo for productive use elsewhere and more.  Anywhere where trade is hampered because of inconsistent systems could be in scope for improvement.  In short, we now have at our hands a new approach to solving one of the trickiest problems in transaction processing: the reconciliation problem.

If we could be sure that one firm’s IT systems were in perfect sync with their counterparts’ systems, it is mindblowing to imagine how much error, risk, duplication, complexity and cost could be eliminated… and how many hitherto impossible transactions became feasible.

In other words: quite separate to the well-understood revolution ushered in by the advent of Bitcoin, an entirely different field also got a massive kickstart. Two revolutions for the price of one.

It doesn’t sound as exciting as a new world currency, to be sure. But it could, in its own way, be utterly transformational. And note: the solution I’m talking about is not the same as a distributed database. And it’s not the same as a fully centralized solution. And it’s not another cryptocurrency or public blockchain. It is something new entirely.

In short, there’s a reason why enterprise blockchain firms like ours look, talk and act differently to cryptocurrency firms and communities: we’re building on some of the same technology, but solving different problems. Problems like managing trade finance relationships, confirming trades and issuing and trading Commercial Paper.

But don’t fall into the trap of thinking all enterprise blockchains are the same. Because they’re not. The Corda introductory whitepaper and Corda technical whitepaper go into this in more depth. But I know you’re busy. So let’s look at just three aspects.

Architecture

First, architecture.  We set ourselves the challenge of building an enterprise blockchain that met the needs for the most demanding clients in business: the financial services industry. It’s why it’s the only enterprise blockchain designed to support interoperable business networks: we want ecosystems to be able to transact and to trade. And it’s why we built a platform that could easily talk to existing business applications and which businesses could actually deploy.

That’s why Corda runs on the Java platform, stores its data, immediately queryable, in a relational database and moves data using message queues.  This facilitates integration, keeps operations people happy in big companies and massively simplifies the design.  Mike Hearn has spoken about this at length.  It sounds so simple – so traditional – yet it’s unbelievably valuable. We scratch our heads every day asking ourselves why everybody else in the enterprise blockchain world left this opportunity wide open for Corda to take!

Contrast that with Fabric, part of the Hyperledger Project: written in Go, it uses a gossip network to spray data indiscriminately around the network, with a cumbersome “channels” abstraction bolted on to fix that problem. And rather than default to a SQL database, it offers a strange choice between a key-value store or a NoSQL document database.

JPMorgan’s Ethereum-fork, Quorum, is still a work in progress so it’s hard to comment but it has a talented team behind it. So I’ll just note in passing that the problem that Ethereum solves so well in the public blockchain world is very different to the problem that large institutions have. So it’s not immediately obvious why you’d use the solution to one as the foundation of the solution to the other.

Privacy

Secondly, privacy.  Corda’s design, from day one, was based on an atomic, need-to-know privacy model that enables multiple different business networks and transaction types to co-exist and interoperate at the same time. Truly an interoperable network of networks is being built out.

Fabric’s design is very different. It has had at least two entirely different privacy designs in its short life and the latest, “channels”, suffers from all the same problems as other coarse-grained approaches to privacy: you end up with lots of mini-global-broadcast blockchains that don’t talk to each other and in which assets will get stranded; the opposite of the vision to which we’re building. You might get away with this design in some simple cases but will then come unstuck when you try to extend the solution.

Quorum’s approach is more innovative but I think it still fundamentally suffers from this problem.

Corda is built for the future

Finally, Corda is built for the future. When we designed Corda, we looked at where the broader industry was going and tried to anticipate those trends.  That’s why Corda is designed to work naturally and seamlessly with Intel’s SGX security technology. It’s why you can write your apps in any JVM language and why we chose to write the base platform in Kotlin, one of the most exciting new languages around – a decision which was vindicated when Google made it a first-class language for its Android platform – and it’s why Corda is jam-packed with cool little developer-friendly features that other platforms simply don’t have, such as our support for reactive programming and support for continuations, which we can automatically persist across JVM restarts.

To be fair to IBM, Fabric is also built for the future. If you assume the future runs on a Mainframe 🙂

Learning More about Corda

Corda is currently in public beta, we’ve just shipped our latest milestone release and you can download our one-click live DemoBench tool to get started in no time.

Or if you’d prefer to look at or contribute to the code, head over to our GitHub repo: https://github.com/corda/corda.

The team does its work in public… join the conversation at slack.corda.net!

 

Finally: a note on terminology. In this post I used Blockchain and Distributed Ledger interchangeably.  I tried for a long time to retain engineering purity (“Corda has chains of transactions but it doesn’t batch them into blocks so we probably shouldn’t call it a blockchain!”) But the reality is that the market uses the term Blockchain to describe all distributed ledger technologies, including ours. So I’m not going to fight it any more…!

 

On Distributed Databases and Distributed Ledgers

Why can’t companies wanting to share business logic and data just install a distributed database? What is the essential difference between a distributed database and a distributed ledger?

Last month, I shared the thinking that led to the design of Corda, which we at R3 will be open sourcing on November 30; and Mike Hearn and I were interviewed by Brian and Meher of Epicenter last week. We’ve been delighted by the response and are looking forward to working with those seek to build on Corda, help influence its direction or contribute to its development and maturation;  there’s a lot of work ahead of us!

But one or two observers have asked a really good question. They asked me: “Aren’t you just reimplementing a distributed database?!”

The question is legitimate: if you strip away the key assumptions underpinning systems like Bitcoin and Ethereum, are you actually left with anything? What is actually different between a distributed ledger platform such as Corda and a traditional distributed database?

The answer lies in the definition I gave in my last blogpost and it is utterly crucial since it defines an entire new category of data management system:

“Distributed ledgers – or decentralised databases – are systems that enable parties who don’t fully trust each other to form and maintain consensus about the existence, status and evolution of a set of shared facts”

“Parties who don’t fully trust each other” is at the heart of this. To see why, let’s compare distributed databases and Corda.

Comparing Corda to a distributed database

In a distributed database, we often have multiple nodes that cooperate to maintain a consistent view for their users.   The nodes may cooperate to maintain partitions of the overall dataset or they may cooperate to maintain consistent replicas but the principle is the same:  a group of computers, invariably under the control of a single organisation, cooperate to maintain their state.  These nodes trust each other.   The trust boundary is between the distributed database system as a whole and its users.    Each node in the system trusts the data that it receives from its peers and nodes are trusted to look after the data they have received from their peers.  You can think of the threat model as all the nodes shouting in unison: “it’s us against the world!”

This diagram is a stylised representation of a distributed database:

 distributed-database

In a distributed database, nodes cooperate to maintain a consistent view that they present to the outside world; they cooperate to maintain rigorous access control and they validate information they receive from the outside world.

So it’s no surprise that distributed databases are invariably operated by a single entity: the nodes of the system assume the other nodes are “just as diligent” as them: they freely share information with each other and take information from each other on trust. A distributed database operated by mutually distrusting entities is almost a contradiction in terms.

And, of course, if you have a business problem where you are happy to rely on a central operator to maintain your records – as you sometimes can in finance it should be said – then a distributed database will do just fine: let the central operator run it for you.  But if you need to maintain your own records, in synchrony with your peers, this architecture simply won’t do.

And there are huge numbers of situations where we need to maintain accurate, shared records with our counterparts. Indeed, a vast amount of the cost and inefficiency in today’s financial markets stems from the fact that it has been so difficult to achieve this. Until now.

Corda helps parties collaborate to maintain shared data without fully trusting each other

Corda is designed to allow parties to collaborate with their peers to maintain shared records, without having to trust each other fully. So Corda faces a very different world to a distributed database.

A Corda node can not assume the data it receives from a peer is valid: the peer is probably operated by a completely different entity and even if they know who that entity is, it’s still extremely prudent to verify the information.   Moreover, if a Corda node sends data to another node, it must assume that node might print it all in an advert on the front page of the New York Times.

The trust boundaries – the red curves in the diagram- are drawn in a completely different place!

decentralised-database

In Corda, nodes are operated by different organisations and do NOT trust each other; but the outcome is still a consistent view of data.

To repeat, because this distinction is utterly fundamental:  nodes of a distributed database trust each other and collaborate with each other to present a consistent, secure face to the rest of the world.   By contrast, Corda nodes can not trust each other and so must independently verify data they receive from each other and only share data they are happy to be broadly shared.

And so we call Corda a distributed ledger, to distinguish it from distributed databases. A distributed ledger that is designed painstakingly for the needs of commercial entities.

Put more simply: you simply can’t build the applications we envisage for Corda with traditional database technology.  And that’s what makes this new field so exciting.

Corda: An Introduction

Announcing the Corda Introductory Whitepaper

The Wall Street Journal had a couple of good pieces this morning that describe some of the work we’re doing at R3 and our vision for the future of financial services.

Project Concord is our codename for the overall vision, with Corda as our underlying distributed ledger software.

I first wrote about Corda back in April and we demonstrated it in public for the first time a few weeks later.  Since then, we’ve been continuing to develop the code base in collaboration with our members, trialling it through an ongoing series of proofs-of-concept, prototypes and more advanced deployments, refining the design and maturing our thinking.

As part of this process, we wanted to share more information with the broader community about what we’re doing.  I’m pleased to announce the release of our first whitepaper on Corda: an introductory, non-technical overview that explains our vision, some design choices and outlines the key concepts underpinning the platform.  We’ll follow this up in the coming months with a more detailed technical whitepaper.

whitepaperThe whitepaper, which you can download here, explains how we set ourselves the challenge of starting with the financial industry’s pain points: duplicated, inconsistent data and business logic and redundant business processes – and asked ourselves if we could apply breakthroughs in distributed ledger and blockchain technology to solve them.

Our conclusion is that distributed ledger and blockchain technology represents a once-in-a-generation opportunity to transform the economics of data management across the financial industry. But there’s a problem because the blockchain and distributed ledger platforms that led us to this exciting moment were never designed to solve the problems of financial institutions and do not meet all our needs: we need tight linkage to the legal domain; we have an obligation to prevent client data being shared inappropriately and so can’t send all transactions to all network participants; we must integrate and interoperate with existing financial infrastructure; and more.

Corda is the outcome of the analysis we did on how to achieve as many of the benefits of distributed ledger and blockchain technology as possible but in a way that is sympathetic to and addresses the needs of regulated financial institutions. Corda is intended to be a contribution to the plurality of technologies that will be adopted in the coming years, one that is targeted specifically and with a laser-focus on the needs of financial institutions.

I hope you find the whitepaper interesting and illuminating and we would love to hear your feedback.

 

 

Introducing R3 Corda™: A Distributed Ledger Designed for Financial Services

UPDATE: The Corda introductory whitepaper is now available! And this blog post gives more context.

As reported in Bloomberg this morning, I’m delighted to confirm that R3 and our member banks are working on a distributed ledger platform for financial services: Corda™. I explain it on our official R3 blog and reproduce it here.

For the last six months, my team and contributors from our membership have been building a distributed ledger platform prototype from the ground up, specifically designed to manage financial agreements between regulated financial institutions. I am massively excited by the progress our team, led by James Carlyle, our Chief Engineer, and Mike Hearn, our Lead Platform Engineer, are making and I think the time is right to share some details.

Corda: A Distributed Ledger for Recording and Managing Financial Agreements

Corda is a distributed ledger platform designed from the ground up to record, manage and synchronise financial agreements between regulated financial institutions. It is heavily inspired by and captures the benefits of blockchain systems, without the design choices that make blockchains inappropriate for many banking scenarios.

Corda’s key features include:

  • Corda has no unnecessary global sharing of data: only those parties with a legitimate need to know can see the data within an agreement
  • Corda choreographs workflow between firms without a central controller
  • Corda achieves consensus between firms at the level of individual deals, not the level of the system
  • Corda’s design directly enables regulatory and supervisory observer nodes
  • Corda transactions are validated by parties to the transaction rather than a broader pool of unrelated validators
  • Corda supports a variety of consensus mechanisms
  • Corda records an explicit link between human-language legal prose documents and smart contract code
  • Corda is built on industry-standard tools
  • Corda has no native cryptocurrency

Corda’s design is the result of detailed analysis and prototyping with our members and will be open sourced when the code has matured further.

In the remainder of this post, I want to share some insight into our thinking.  Why are we building Corda?  Why have we made some of the design decisions we have?  When will the code be ready for others to examine and build upon? How does this relate to other platforms and projects?

A thought experiment

When I joined R3 from IBM in September 2015, I forced myself to stop and think.  The blockchain bandwagon was running at full speed, I’d just been appointed CTO of a project intended to bring blockchains to finance but there was a nagging worry at the back of my mind…  how could I avoid falling into the trap of believing all the hype?!

I imagined myself sitting in front of the CIO of one of our member banks some time in the future.  I imagined we had naively selected a “blockchain for finance” based on what was popular at the time and widely deployed a range of products and services on top of it. And I imagined we had believed the hype, had suspended our critical faculties and had omitted any engineering.  In this imagined scenario, I now found myself facing an angry CIO, who wanted to know why the system I had built had just failed calamitously. Why on earth did I build it the way I did?!

I concluded that an entirely inappropriate answer to that question would be: “because blockchains were cool in 2015”!  No. That simply won’t do.

The reality is that solutions based on selecting the design first and then trying to apply it to arbitrary problems never work out well.  Every successful project I’ve worked on started with the requirements, not some cool piece of technology, and I was determined to bring that discipline into our work at R3.

Remind me again why a system designed to replace banks is also supposedly their saviour?

And there is a second reason for this caution: the technology and finance industries collectively “decided” some time in early 2015 that “blockchain technology” was somehow the future of financial services.

Indeed, I am one of the most active proponents of precisely that claim. But the reason for blockchain technology’s importance is extremely subtle – and this subtlety is something that most people seem to have missed.

To understand this, we need to look at Bitcoin.

Bitcoin’s architecture, as I have often written, is a marvel.  Its interlocking components are one of those rare examples of something so elegant that they seem obvious in hindsight, yet which required a rare genius to create.

But what is often missed is that the cleverest part of Bitcoin isn’t actually its architecture; I think the cleverest part was to articulate the business problem.  We don’t tend to think of Bitcoin as being the solution to a “business problem” but it can perhaps be thought of as a wonderfully neat solution to the problem of: “how do I create a system where nobody can stop me spending my own money?”   Now, I can’t claim to know the mind of Satoshi and he certainly didn’t write the whitepaper in this way but it triggers a very useful thought-experiment.

In fact, once you write this ‘business problem’ down, the design drops out almost trivially!  (Almost…) You want always to be able to spend your own money? Then you can’t have a central point of control.  It could be shut down by the authorities.  You can’t even have a collection of validators with known identities as they could also be shut down with concerted effort.  Very quickly you realise you need a massively replicated consensus system and, if you don’t want to tie actions to real-world identities, you need something like Proof of Work to make the voting work.  You work the logic through and pretty much the whole design (the blockchain, the need for mining, block rewards, maybe even the UTXO transaction model, etc., etc.) drops out.  Of course, it does push a lot of work onto the users: confiscation of somebody’s bitcoins is easy if you know their private key… but let’s leave that to one side for now.

And this way of looking at it is important because it highlights how Bitcoin’s blockchain can be thought of as the solution to a business problem.    Satoshi Nakamoto didn’t wake up one morning wanting to “apply Blockchain to finance”.  Blockchain was the tool that was invented to solve a real problem.

So we have a conundrum, right?  If that’s the case, then what on earth is the argument that says blockchain has any relevance at all to banking?!

Indeed, last time I checked, banks have the inverse of my Bitcoin problem statement!

What is the defining characteristic of blockchain systems?

So I spent most of October sitting in a dark room (really! This was our first London office… a tiny four-person room in a shared working space in the City of London) questioning some of the most fundamental assumptions about blockchains.  What is it exactly that makes them interesting to banks?

Most people had already made the mental leap that the “bitcoin package” was unacceptable as a take-it-or-leave-it deal: proof of work is unnecessary for private deployments, for example.  But, as I looked around, all I could see was firms who had accepted everything else…  It seemed strange to me that, as an industry, we could tease apart one part of the “blockchain bundle” but then stop there.

I spent several of my earlier, formative years at IBM in a role called “technical sales”.  If you’ve ever bought technology from a large IT vendor, you’ll have met somebody like me.  We’re the people who visit clients with the sales rep and act as the technical expert: we explain how the product works, make sure we’re proposing the right solution to the client and ensure there is no technical barrier to closing the deal.

A lesson I learned very early in that role was: it doesn’t matter how hard you wish or how many client meetings you schedule or how aggressive the sales rep gets, if you can’t show how your solution is going to solve the client’s business problem then the deal almost certainly won’t close.  And those that do are the ones you’ll live to regret…

Fast forward a decade, and as I surveyed the blockchain landscape in October 2015, all I could see was excitable (and vocal!) firms touting solutions that made very little sense to me for the kinds of problems I was trying to solve.  I will confess to many moments of self-doubt:  maybe they were all sane and I was the mad one..?!

But I ploughed on: even if they are right that a “take it or leave it” blockchain design is the saviour of the financial industry, I’ll be doing our members a favour if I could explain why.

So we started picking away at what can perhaps be called the “blockchain bundle”:  the collection of services that blockchains provide to those who use them.

We concluded that a blockchain such as the ones underlying Bitcoin or Ethereum or any of the private variations actually provide at least five interlocking, but distinct, services.  And the right approach is to treat them as a menu from which to select and customise… different combinations, in different flavours, for different business problems.

CONSENSUS

The first, and most important, feature of blockchains – and the thing that is probably genuinely new in terms of scale and scope – is that they create a world where parties to a shared fact know that the fact they see is the same as the fact that other stakeholders see:

“I see what you see… and I know that what I see is what you see”

And, critically:

“I know that you know that I know”! 

And:

“I know that you know that I know that you know…”

And so on…

And it makes this promise across the Internet between mutually untrusting parties.  Sure: consensus systems and replicated state machines have existed for years but consensus systems at Internet scale, between untrusting actors, that work in the face of powerful adversaries? That’s a step forward.

In Bitcoin, the shared facts are things like: “What are all the bitcoin (outputs) that have not yet been spent and what needs to happen for them to be validly spent?”.  And the facts are shared between all full node users.

In Ethereum, the shared fact is the state of an abstract virtual computer.

But notice something interesting: there isn’t some law of nature that says the set of people who have to be in consensus is the whole world.  Bitcoin just happens to work that way because of its unique business problem.   If you don’t have Bitcoin’s business problem then be very wary of those trying to sell you something that looks like a Bitcoin solution.

VALIDITY

The second feature in the “blockchain bundle” is validity. Tightly linked to consensus, this feature is the one that allows us to know whether a given proposed update to the system is valid. It is how we define the rules of the game.  What does a valid “fact” look like in the system?  What does a valid update to that fact look like?

UNIQUENESS

The third feature in the blockchain bundle is its “uniqueness service”.   I can quite easily create two perfectly valid updates to a shared fact but if they conflict with each other then we need everybody who cares about that fact to know which, if either, of those updates we should select as the one we all agree on.  The “anti-double-spend” feature of blockchains gives us precisely this service and it’s hugely important.

IMMUTABILITY

The fourth feature in the “Blockchain Bundle” is often, if misleadingly, termed “immutability”: data, once committed, cannot be changed.

This isn’t quite true: if I have a piece of data then of course I can change it.  What we actually mean is that: once committed, nobody else will accept a transaction from me if it tries to build on a modified version of some data that has already been accepted by other stakeholders.

Blockchains achieve this by having transactions commit to the outputs of previous transactions and have blocks commit to the content of previous blocks.  Each new step can only be valid if it really does build upon an unchangeable body of previous activity.

AUTHENTICATION

The final critical feature in the “Blockchain Bundle” is authentication: every action in the system is almost always associated with a private key; there is no concept of a “master key” or “administrator password” that gives God-like powers.   This is quite different to traditional enterprise systems where these super-user accounts are prevalent and petrifying from a security perspective.

So what is the financial services business problem?

So why did I take us through this analysis?  Because it gets us to the heart of the distributed ledger domain: the thing that is genuinely new is the emergence of platforms, shared across the Internet between mutually distrusting actors, that allow them to reach consensus about the existence and evolution of facts shared between them.

So if that’s what this is all about, then what are the “shared facts” that matter in finance? What business problem would we need to have for any of this work to be of any use at all?

And this is the light bulb moment and the fundamental insight driving the entire Corda project:

The important “shared facts” between financial institutions are financial agreements:

  • Bank A and Bank B agree that Bank A owes 1M USD to Bank B, repayable via RTGS on demand.
  • This is a cash demand deposit
  • Bank A and Bank B agree that they are parties to a Credit Default Swap with the following characteristics
  • This is a derivative contract
  • Bank A and Bank B agree that Bank A is obliged to deliver 1000 units of BigCo Common Stock to Bank B in three days’ time in exchange for a cash payment of 150k USD
  • This is a delivery-versus-payment agreement
  •  … and so on…

The financial industry is pretty much defined by the agreements that exist between its firms and these firms share a common problem:  the agreement is typically recorded by both parties, in different systems and very large amounts of cost are caused by the need to fix things when these different systems end up believing different things. Multiple research firms have postulated that tens of billions of dollars are spent each year on this problem.

In particular, these systems typically communicate by exchanging messages: I send an update to you and just hope you reach the same conclusion about the new state of the agreement that I did.  It’s why we have to spend so much money on reconciliation to check that we did indeed reach the same conclusions and more money again to deal with all the problems we uncover.

Now imagine we had a system for recording and managing financial agreements that was shared across firms, that recorded the agreement consistently and identically, that was visible to the appropriate regulators and which was built on industry-standard tools, with a focus on interoperability and incremental deployment and which didn’t leak confidential information to third parties.  A system where one firm could look at its set of agreements with a counterpart and know for sure that:

“What I see is what you see and we both know that we see the same thing and we both know that this is what has been reported to the regulator”

That’s Corda.

How does Corda choose from the “Blockchain Bundle” Menu?

So now we understand the financial services requirement, we can look again at the “Blockchain Bundle” menu from above and outline the choices we’ve made.

CONSENSUS

A critical piece of the Corda philosophy is that our problem is to ensure that “I know that you see the same details about a shared fact that I see”.

But this does not mean that a third party down the road also needs to see it: our consensus occurs between parties to deals, not between all participants.

VALIDITY

Furthermore, in Corda, the only people who need to be in agreement about a fact are the stakeholders to that fact:  if you and I agree about something that pertains only to us then why should we care what some completely unrelated third party thinks?  And why would we even think of sending them a copy so they could opine on it? So, in Corda, we let users write their validation logic in time-tested industry-standard tools and we define who needs to be in agreement on a transaction’s validity on a contract-by-contract basis.

UNIQUENESS

Just like every other distributed ledger out there, we need to be sure that two valid, but conflicting, transactions cannot both be simultaneously active in the system.  But we also recognise that different scenarios require different tradeoffs. So Corda’s design allows for a range of “uniqueness service” implementations, one of which is a “traditional blockchain”. But it doesn’t need to be and, for our purposes, we also need implementations that make different tradeoffs under Brewer’s CAP theorem: in particular, some financial services use-cases need to prioritise consistency at the expense of availability in the event of a network partition.

IMMUTABILITY AND AUTHENTICATION

Here, Corda’s design departs very little from existing systems: our data structures are immutable and our building block is the exchange of digitally-signed transactions.

So Corda is very traditional in some respects – we directly apply the “authentication”, “immutability” and “uniqueness service” features of blockchains but we depart radically when it comes to the scope of “consensus” (parties to individual deals rather than all participants) and “validation” (the legitimate stakeholders to a deal rather than the whole universe or some arbitrary set of ‘validators’).

How is Corda Different?

Hang on?  Isn’t this the same pitch that every other blockchain firm is making? Not quite.

Notice some of the key things:  firstly, we are not building a blockchain.   Unlike other designs in this space, our starting point is individual agreements between firms (“state objects”, governed by “contract code” and associated “legal prose”).  We reject the notion that all data should be copied to all participants, even if it is encrypted.

Secondly, our focus is on agreements: the need to link to legal prose is considered from the start. We know there will still always be some disputes and we should specify right up front how they will be resolved.

Thirdly, we take into the account the reality of managing financial agreements; we need more than just a consensus system. We need to make it easy to write business logic and integrate with existing code; we need to focus on interoperability. And we need to support the choreography between firms as they build up their agreements.

Different Solutions for Different Problems

But… we should be clear.  We are not viewing Corda as a solution to all problems.  This model is extremely powerful for some use-cases but likely to be less well suited to others.  It’s why we continue to engage extremely deeply with all our partners who are working on complementary platforms in this space; we are not omniscient.  Moreover, there are still many significant design and research questions we have to resolve: there is still a great deal of work to do.

Furthermore, I have been deeply impressed by the quality engineering embodied in the many platforms that have passed through our labs and you will continue to hear about projects we are delivering on platforms other than Corda: different solutions for different problems is our mantra.  Indeed, those who have attended panels or workshops in recent months will have heard me saying this for some time now.

Corda does not seek to compete with or overlap with what other firms are doing:  indeed, we are building it because no other platform out there seeks to solve the problems we’re addressing.  That’s what makes this space so endlessly exciting.

What next?

In the coming weeks and months, you’ll hear more about Corda, about our initial projects and about its design.  We will also be gearing up to release the core platform as open source, possibly as a contribution to other endeavours.  Watch this space.

And… we’re still hiring: there is a great deal of work still to do!