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!

Towards Deeper Collaboration in Distributed Ledgers: Thoughts on Digital Asset’s Global Synchronisation Log

It’s now almost two months since we open-sourced Corda and I’m delighted by the reception it has received. In our rapidly growing community, we’re already seeing new users grow into leaders who help other newcomers get to grips with the platform.

And I am amazed by the number of inbound messages from users who have been impressed by the quality of Corda’s design and codebase – and who are already building significant applications and products on top of it. Indeed, as I write this, one of our member banks is running a global hackathon, with over 150 of their developers building on Corda and I’ve just returned from our Asia Members’ Conference in Hong Kong, where I sat through so many presentations about Corda projects I didn’t even know were happening…

If you’re not already on our Slack or participating in our discussion forum, you’re missing out!

But one additional benefit from delivering on our commitment to make Corda Open Source is that it means we can explore opportunities to collaborate with peers, competitors and partners across the ecosystem: identifying areas where our visions are aligned, where we see things the same way and where we might be able to reuse rather than needlessly reinvent.

A good example of the potential for firms who some might see as competitors (but who actually aren’t…) to collaborate was provided late last year in the form of an excellent whitepaper from Digital Asset: The Global Synchronization Log.  The paper helps clarify some really important aspects of distributed ledger design and shows a really deep understanding of the tradeoffs that are inherent in the design of these platforms.

The first time I read the paper, I was struck by how closely our two firms’ visions for DLT are aligned. As Mike Hearn has written, there are two fundamentally different ways to design a DLT –“UTXO” or “replicated virtual machine” – and it was very encouraging when I realised that our two firms, completely independently, had both concluded that the correct architecture for a significant range of important financial services use-cases is the UTXO model.

This bears repeating: two firms who, in R3’s case, had worked with a huge consortium of financial institutions on a groundbreaking year-long Architecture Working Group and, in the case of Digital Asset, had begun delivery of implementations for clients, had reached extremely similar conclusions about what the “correct” architecture should look like.

But, in reading the paper, it was also clear that we had made some different decisions, too.  And the interesting thing is that the differences are almost all related to choices we’d made about acceptable tradeoffs.  As I’ve often written, there are no perfect solutions in DLT; just tradeoffs. But I will also freely admit that we made some additions to Corda’s technical vision in the light of the paper!

So it’s time, I thought, to share my thoughts on what I think are the key points in the paper and outline how I think Corda could be a perfect way to implement the concept.

What is the Global Synchronisation Log?

At the heart of this space is a beguilingly simple vision:

DLT allows me to build systems where “I know that what I see is what you see”

That is: if a computer system that I own and run and which exists to serve my needs tells me something about a deal you and I have done, I want to know that the system you’re looking at, that you own and run and which exists to serve your needs, is telling you the same thing.

Before Bitcoin and blockchains and Distributed Ledger Technology there were only two ways of doing this, neither of them perfect:  1) we could build a centralised infrastructure and just agree to agree that whatever they say is the truth… consensus by authority, if you like or 2) we could build our own systems and then spend all our lives checking that they had come to the same conclusion about everything… consensus by reconciliation.

Bitcoin and the systems it inspired showed us there was a third way:  we could use advances in cryptography, consensus algorithms and other technologies to give ourselves near total assurance that our systems were in sync without having to employ armies of people to check.

But there was a problem… and this problem is at the absolute heart of everything that’s going on in the DLT space today: the solution invented by Bitcoin and refined through subsequent systems depends on all data being shared with all parties.  So you gain something amazing on one hand: an end to errors, duplication, inconsistency and associated risk. But, on the other hand, you create a privacy nightmare and a system that goes slower the more things you use it for.

This is precisely the conundrum that motivated the invention and development of Corda. We decomposed the building blocks of existing blockchain platforms and reassembled them in the light of the different threat-model we have, the different use-cases and different tradeoffs we are prepared to accept.

One of the key insights in our work was that, for our scenarios, we can separate transaction verification from the question of whether two verified transactions conflict with each other. I wrote about this when we first announced Corda in April last year.

We think the question of transaction verification should be down to the transaction participants: if one of them pretends that their smart contract produced a different answer to what it actually did then we’ll deal with it out-of-band; it’s a permissioned system and we know who they are…   They gain nothing by playing games like that.

But the question of which transactions actually get confirmed is a question for an independent observer; we need somebody we all trust to choose between two equally valid but conflicting transactions. At R3, we call this observer a notary but that’s just the name we use to generalise the role performed by miners in a traditional blockchain.

In so doing, we addressed many of the privacy and scalability issues of other platforms at a stroke.

But it’s a tradeoff, of course.  Because there’s something that a full public blockchain gives you that this approach doesn’t. Both approaches assure you that only valid transactions can get confirmed, but a full public blockchain also ensures that everybody gets to know when this happens.

But, of course, a traditional blockchain does this by using full broadcast, in the clear, of pretty much everything that happens. A privacy and scalability disaster.

So we had some very heated debates when we designed Corda about which tradeoffs were acceptable and which ones were not. And the GSL paper touches on all of them really succinctly.

Two of the more important debates were as follows:

  • If I send a full transaction to a notary (think ‘miner’ in a traditional blockchain), that could be a privacy leak: the notary gets to see all the data in the transaction. But if I only send the pieces of the transaction that the notary actually needs to see in order to decide transaction ordering then I could execute a “denial of state” attack by having the notary confirm an invalid transaction that “consumes” an input and stops a valid transaction from subsequently being confirmed.
  • If I send a transaction to a notary, how does it know which other parties to inform? I could execute an attack whereby I get a transaction confirmed but the other side doesn’t learn about it… that might allow me to selectively choose not to reveal it if it so suits me.

In Corda, we made the following observations. We said:

  • The “notary privacy versus denial-of-state” question is one that should be solved on a case-by-case basis. So we support “validating notaries” that need to see all data and “non-validating notaries” that just see the subset that allows them to make a confirmation decision. But we require the non-validating notaries record who sent them the transactions they sign so we know who’s to blame if anybody does try to do something nefarious.
  • But the notification issue is more tricky: recall, the full-broadcast solution used in “traditional” blockchains just won’t cut it. Indeed, that’s why, in Corda, there is no global broadcast, by design.  So if a notary is going to inform you that something happened, it needs to know who you are and how to reach you. But that’s also a privacy issue if you implement it simplistically. So users effectively need the right to decide who they trust more: the notary or their counterparties.

So now to Digital Asset’s paper.   What they propose is very reasonable.  In essence, they say the following:

  • The Digital Asset GSL model is comfortable with the risk of a “denial of state” attack. (As are we at R3 for many scenarios, by the way, because the mitigations are robust; but Corda’s default mode is to protect against this threat).
  • So this means it’s fine if the notary only gets to see the subset of a transaction that is needed in order to determine ordering/uniqueness.
  • But GSL users are entirely not OK if a transaction can be confirmed and yet all the affected parties don’t get to hear about it at the same time as the transaction submitter.

And the paper goes on to explain how they think that last problem should be solved.

In essence, they do the following:

  • They effectively add the identities of all the parties who should know about the transaction to the outside of the transaction. This is the part that the notary sees.
    • They don’t actually put the interested parties’ identities on directly – that would be a privacy leak – but that’s the effect; you can think of them as “tagging” the transaction with the list of everybody who needs to know about it.
  • But that’s not enough, of course. The notary doesn’t get to see most of the transaction contents, remember… so the list could be wrong and the notary wouldn’t know! So they go a step further.
  • They add an additional rule to the transaction verification logic: if the transaction doesn’t “tag” the right set of intended recipients then it isn’t considered valid.
  • So now you have something pretty cool: you can get a transaction that fails to tag the right people notarised just fine (the notaries are ‘non-validating’ in the DA model, remember). But the “attacker” gains nothing because the transaction itself won’t be considered valid per the rules of the system.  So whatever nefarious scheme you were plotting fails…
  • And if you do construct a valid transaction then the act of getting it confirmed is also the irreversible act of having the notary inform all affected parties. So a bad guy doesn’t get to withhold valid, confirmed transactions.
  • This approach binds the question of transaction validity to the question of notification of affected parties.  You can’t have one without the other.

So you achieve something useful: transaction contents remain visible only to those who need to see them, transaction verification is in the hands of those to whom they pertain, notaries don’t see what they shouldn’t and if a transaction gets committed all relevant parties get to hear about it.  For a good number of use-cases, that’s a decent set of tradeoffs.

So can Corda provide a solution for the GSL?

(Spoiler: YES!)

It turns out that Corda’s design already has every single one of the features needed to implement the GSL – apart from one, which we added specifically to address this requirement.

  • Corda’s notaries already log the transaction submitters when operating in non-validating mode so we already solve the “denial of state issue” just fine.
  • Corda already supports “transaction tear-offs”, the mechanism whereby only the relevant information is shared with third parties such as notaries, using Merkle trees.
  • Corda already supports the concept of “participants” – aka“tags” – a list attached to each transaction that identifies interested parties
  • Corda’s transaction verification engine already allows contracts to verify that the participant list is correctly populated.

So we already have the mechanism to bind the verification to the population of the notification list.  But the “out of the box” design does not then ensure the notification actually happens…  This was a deliberate choice based on prioritisation of requirements and (yet another!) tradeoff around privacy.

In other words, there was one missing piece, albeit a deliberate one.  But reading this paper made us convinced adding that feature made sense and so we’ve added it to our design and will be added to the codebase in a future milestone release. The thinking is captured in section 7.5 of our technical whitepaper, starting page 33.

Note that our proposed implementation is slightly different to the design sketched in the Digital Asset paper because we deliberately and famously don’t have a blockchain: so there is no data structure that participants can passively browse to look for transactions of interest. Instead, we use a push point-to-point messaging network.  So the notary will directly inform affected parties.

Open Innovation: 2017 is the Year Corda Goes Mainstream

One of the many benefits of working on an open source project is that it becomes so easy and natural to explore these sorts of concepts with other firms, through initiatives such as the Hyperledger Project; through discussion of each other’s papers, like here; and through coding and direct collaboration between developers: we’re very much enjoying working with one of Digital Asset’s developers in our public Slack group, for example.

We think Corda is shaping up to be a perfect architecture for implementing the Global Synchronization Log concept and I am grateful to the team at Digital Asset for sharing their thinking – and their list of requirements – so openly and clearly.

Here’s to open innovation!

Countdown to Corda Open Source

R3 will soon be open-sourcing Corda. Here’s what to expect.

As I confirmed a few months back, R3’s Corda platform will be open-sourced, under the Apache 2 licence, on November 30.

Corda is a distributed ledger platform designed and built from the ground up for the recording and automation of legal agreements between identifiable parties. It is heavily influenced by the requirements of the financial industry but we believe the community will find the underlying architecture will lend itself to a broad range of applications.

We’ve built Corda because we see requirements – especially in finance – that need a distributed ledger but which cannot be met by existing platforms.

  • Corda is the only Distributed Ledger platform designed by the world’s largest financial institutions to manage legal agreements on an automatable and enforceable basis.
  • Corda only shares data with those with a need to view or validate it; there is no global broadcasting of data across the network.
  • Corda is the only Distributed Ledger platform to support multiple consensus providers employing different consensus algorithms on the same network, enabling compliance with local regulations.
  • Corda is designed to provide a great developer experience and to make integration and interoperability easy: query the ledger with SQL, join to external databases, perform bulk imports, and code contracts in a range of modern, standard languages.

We designed it with the members of R3, the world’s largest financial services DLT consortium, but we think its applicability is far broader.  You can find out more in our introductory whitepaper and my blog post on why we’re building Corda and what makes it different. If you prefer videos, here’s a short interview I did with Simon Taylor of 11:FS that explains the thought process behind Corda.

What we’ll release on November 30 is pretty much the full codebase as it exists today and we will be improving it actively and openly from then on. In fact, the only code we’ve held back pertains to laboratory projects we’re working on with our members and work on our own commercial business products that will run on top of Corda.

So do take a look around when the code is released: there’s a lot in there that is still work-in-progress and not yet integrated. For example, you’ll find a fascinating approach to writing financial contracts in the experimental branch and ongoing work on our deterministic sandbox for the JVM.   We will, of course, also be developing a commercial version of Corda for those who need specific enterprise features and support, but the open source codebase is the foundation of everything we do.

This is a really important point: distributed ledger technologies will have such phenomenally powerful network effects that it is unthinkable that serious institutions would deploy base-layer ledger software that is anything other than fully and wholeheartedly open. And it’s why we’ve been committed all along to releasing Corda just as soon as we were sure it was heading in the right direction.  It is and so we are.

We will also be publishing a draft of our technical whitepaper.  This whitepaper outlines our roadmap to version 1.0 of Corda and production-readiness.

What to expect on November 30

We’re really proud of Corda and its progress to date. But, that said, Corda is far from finished. Mike Hearn will soon be publishing a “warts and all” description of quite how much work we still have to do. This is true for all other platforms in this space, of course, but I feel a particular responsibility to be transparent given the ambitions we have for Corda and the uses to which it will be put.

By way of example, perhaps a good way to help you figure out what we still have to do is to look at some items on the list of work we’ve set for the months ahead of us:

  • Functional completeness: Corda still has gaps in its functional capabilities. The technical whitepaper outlines the full vision and you’ll see us working on and merging a lot of functional enhancements in the coming months to implement the full vision in the paper.
  • Non-functional characteristics: We focused first on design and then on implementation of Corda’s core functionality. The work to ensure we meet our non-functional requirements, such as performance, is still ahead of us but we have a clear roadmap and have designed the platform with these needs firmly in mind.
  • Security hardening: There are lots of areas where we need to tighten up security. Much of this we know about and we have called it out in the code or associated docs. But there will, of course, be others. So just as you shouldn’t be using other enterprise DLT platforms in production just yet, please don’t download Corda and put it straight into production just yet either!
  • API Stability: Corda’s development is iterative and organic – and it is heavily influenced by the range of projects and applications to which our members are choosing to put it. As we learn about common patterns and discover assumptions that prove to be wrong, we adapt. In particular, this means that we do not commit to API stability or backwards-compatibility until version 1.0.  Expect parts of the implementation to change in the coming months, perhaps quite significantly!

But these things are transient: we know how to fix them and we’ll knock the issues off one-by-one in the coming months as we head towards version 1.0.  But we want you to be fully aware of them.

Why are we open-sourcing Corda now?

We had a vigorous internal debate about when was the right time to release Corda: wait until it was more mature, when we were confident we’d ironed out the bugs and made it fly?  Or wait only until the design roadmap was clear and then share it immediately with the world for comment, criticism, contribution and collaboration?

We’ve wholeheartedly chosen the latter path: to release early and to work openly.

We’re serious about inviting the community to critique, collaborate and contribute. To take one example, our friends at Digital Asset recently published an excellent paper describing a set of requirements for what they call a “Global Synchronisation Log” (GSL), encouraging those in the community to incorporate these requirements into their platforms. We think that Corda’s vision is extremely well aligned to the GSL concept and by open-sourcing our work whilst there is still time to tweak our design it means we maximise the opportunities for firms such as ours to collaborate.

But open-sourcing Corda when it is still fairly young is not without its risks!  In fact, I’m a little apprehensive. I’m a completer-finisher and I obsess over every detail. So the idea of releasing something before it’s perfect makes me feel uncomfortable.  You will find gaps, issues, problems. But that’s fine: please do share what you find.  Even better, submit a fix…!

In fact, I also have a hope that some of those who come to critique will find that they nonetheless like much of what they see, and may even join the community.

What happens next?

I performed a thought experiment a while back… I asked: what will the enterprise distributed ledger world look like when everything settles down in a few years? How many independent enterprise DLT platforms will the world need and which ones will they be?

My conclusion was that there will probably be at most three such platforms, each carefully designed and adapted for a specific set of requirements. They will all be fully open source. And they will be surrounded by thriving, inclusive communities.

And we firmly intend to ensure Corda is one of them.

Our open-source release next week is a key step on that journey.

How to get Corda on November 30

Corda’s home will be corda.net.

Head over to corda.net on November 30 for links to the codebase, simple sample applications and a tutorial to get started writing your own CorDapps.

 

 

R3 Corda: What makes it different

As reported by Reuters last week, Corda, the Distributed Ledger platform we’ve been working hard on at R3 for the last year at will be open sourced on November 30.

What is it? Why are we building it? What happens next?

Corda is a distributed ledger platform designed and built from the ground up for the recording and automation of legal agreements between identifiable parties. It is heavily influenced by the requirements of the financial industry but we believe the community will find the underlying architecture will lend itself to a broad range of applications.

Corda is quite unlike any other Distributed Ledger platform that currently exists. So we’ll be releasing lots of information in the coming weeks and months. To understand why it looks the way it does, I thought I’d share the journey we went on to build it.  In subsequent articles, the team and I will share more detail about how it works and what to look for when it’s released on November 30.

But first, some history.

The very first decision made by the Steering Committee of the R3 consortium was to establish our Architecture Working Group, which I chair.  This group consists of hundreds of senior architects, technologists and developers, many with decades of experience in a dazzling array of areas, from across our membership over over seventy financial institutions.

We were given a simple-sounding mission:

“To establish the architecture for an open, enterprise-grade, shared platform for the immutable recording of financial events and execution of logic”.

There is quite a lot packed into that sentence..!  Let’s look at just two parts:

  • “Open”
    • I stated publicly in April that we would open-source Corda and I was serious. Our mandate, from our member banks, was that whatever base platforms we selected, built or adopted had to be open. We’re delivering on this commitment with the open-sourcing of Corda on November 30.
  • “Immutable recording of financial events and execution of business logic”
    • Notice what this doesn’t say. It doesn’t say “blockchain”.  Heck: it doesn’t even say “distributed ledger”!    Instead, it tries to get to the heart of what we think is the essence of this exciting new field.  And that’s what I want to talk about in this blog post.

We don’t like solutions looking for problems

I wanted us to be precise about what this field is all about.  After all, and as I wrote when we first announced Corda, Satoshi Nakamoto didn’t wake up one morning thinking: “I really need a blockchain!”.  No: he started with a well-defined business problem and engineered a solution to solve that problem.  And if you need a system of censorship-resistant digital cash, then Satoshi’s design – Bitcoin – is the elegant solution and it’s available today.

And that’s why Ethereum, to take another example, looks so different to Bitcoin.  Vitalik Buterin and his colleagues started with a different business problem, which I characterise as “I want an unstoppable world computer that can execute business logic and move value autonomously” and guess what? They ended up with a very different design!  Now sure:  there are many similarities between Bitcoin and Ethereum but also a lot of differences.

I was determined that we would not fall into the trap of taking technologies designed to solve completely different problems and blindly apply them to banking.  That way lies madness.

So we drove two key pieces of work: 1) characterising exactly what is new about this field and 2) identifying precisely where in finance it may have most applicability.

And the answer, as I outlined back in April, is that there is something genuinely new in this space and it’s something that is massively relevant to the financial system.

The definition I think best captures this is as follows:

“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”

Let’s first test that this definition works for existing public systems:

Bitcoin: the participants don’t know each other’s identities and come to consensus about how many bitcoins there are, which addresses own them and what needs to happen for any of them to be spent without having to trust each other.  Check!

Ethereum: the participants don’t know each other’s identities and come to consensus about the state of a virtual computer.  Check!

In those systems’ cases, they achieve these outcomes in ways with which we’re both familiar and which address requirements related to the environment in which those systems are expected to run.

But how about finance… parties who don’t fully trust each other but whom need to be in consensus about a set of shared facts?

Where do we have that problem?

Erm… how about everywhere..?!!

It’s perhaps only a slight exaggeration to suggest that the financial industry is pretty much defined by the web of contracts that exists between its participants:  I deposit money with a bank? There’s a contract there that says the bank owes me that money.  You and I enter into a Credit Default Swap? There’s a contract there that describes our mutual rights and obligations.  And they’re recorded and managed in multiple places, on different systems, managed by different firms and it costs a fortune to keep them all in sync.

The shared facts in finance are the existence and state of financial agreements – ie contracts.

And the need for consensus is what amounts to the twenty-first century’s “paperwork crisis”: the tens of billions of dollars spent annually maintaining and managing the duplicated records that each firm maintain about the same deals.  The same information about a deal is recorded multiple times across these parties and in situations where a centralised solution can’t be deployed, which is in lots of places, small armies are required to ensure that these disparate records agree with each other, get updated correctly and in synchrony – and deal with the issues when they don’t.

A ha!  So now we have something phenomenally exciting: a new technology for establishing and maintaining consensus between parties who don’t trust each other.  And a multi-billion dollar business problem crying out for this solution!

There’s only one minor problem…

Public systems like Bitcoin were not designed to solve these problems. They’re excellent at what they do; but we’re doing something else.

And you only need to take a cursory look at the architecture of various public blockchain systems to see why this might be the case.  My business problem amounts to ensuring the Bank of Alice and Bank of Bob agree about a trade they just did and that it settles automatically and correctly.   A solution which not only shares this confidential data with every other bank in the world but which also requires them to process the deal and maybe even validate it doesn’t meet my needs. And yet… that’s how every single public platform back in 2015 worked.

Perhaps those architectures can be heavily re-engineered to solve such problems, as some groups are attempting but it’s not an obvious starting point, especially when you then layer on all the other requirements we identified.

So there’s a problem: Bitcoin and its successors taught us that a new way of building distributed systems was possible: one where mutually distrusting parties can maintain a shared database.  We identified a hitherto unsolved problem in finance. And yet the technology that existed simply wasn’t designed for this.

 

Coding, not talking

The reality is that finding fault is easy; proposing workable solutions is altogether harder.   So simply going out and shouting about how 2015’s platforms didn’t solve our problems was hardly a way to make friends.  No.  We needed to do better than that.

So once we had decided we needed to prototype the alternate approach we had identified, we made a critical decision to buttress my leadership team of James Carlyle and Ian Grigg:  we brought in Mike Hearn.

And he drove the prototyping effort to explore these concepts in the only way that gives you certainty that it can be done: by proving it in code.  As Mike enjoys reminding me: when it comes to core concepts, talk is cheap; at some point, the talking has to give way to coding.

 

Early results were promising: the reductive, bottom-up approach we took to architecture and design, which is explored in our introductory whitepaper and on which we’ll elaborate in the coming weeks, was solid: we could model a diverse range of instruments; the design would allow for significant parallel processing; we did not need to send all data to all participants in all scenarios; the use of a mainstream virtual machine and its libraries led to high developer productivity; we were able to support multiple consensus providers on a single network; the use of a flat, point-to-point queue-based, peer-to-peer network mapped well to real business scenarios; and more.

We worked with our members to test the maturing codebase in a variety of contexts: interfacing Ricardian Contracts and Smart Contracts in the context of an Interest Rate Swap with Barclays and others; managing trade finance flows; and more.

And this focus on validated client requirements and a willingness to question some hitherto sacred beliefs (we have no blocks! we have no miners! we don’t put ephemeral data in the consensus layer! we allow per-transaction specification of consensus providers!) led to a unique design.

Had Corda ended up being a minor variation on an existing platform or a me-too copy of something else, what would have been the point in pursuing the work?  But that isn’t what happened: we ended up with something quite distinct, something we believe is singularly well-suited to a wider variety of financial-services use-cases and something  adapted to the practical reality that the industry is regulated and some rules simply aren’t going to change overnight.

So that’s the backstory. Our large – and growing – technology team still has a large amount of work to do.  But now is the time to share our work with the broader community and encourage people – including in other industries – to use it for their own applications as it matures (it’s still a young codebase), to contribute to Corda itself, and to contribute to the architectural debate.

We’re looking forward to November 30. This is an exciting time!