Category Archives: r3

Standard

Posted by

Posted on

October 3, 2017

Posted under

blockchain, Corda, open source, r3, Uncategorized

Comments

9 Comments

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!

Standard

Posted by

Posted on

April 18, 2017

Posted under

Corda, distributed ledger, distributed ledgers, open source, r3, Uncategorized

Comments

4 Comments

Corda: Designed For Commerce, Engineered for Deployment

When we say Corda is designed specifically for enterprises, we mean it!

I’ve spent a lot of time with clients recently and it’s been thrilling to hear how so many of the unique design decisions we’ve made with Corda really resonate.

R3 has been building this new open-source distributed ledger platform in close collaboration with hundreds of senior technologists from across our global financial services membership. And that’s why Corda resonates with business people, because it was designed from the ground up to solve a real business problem: helping firms automate and manage their dealings with each other with legal certainty and without duplication, error and unnecessary reconciliation. Applying the essential insight of blockchain intelligently to the world of commerce.

Corda: inspired by blockchain systems but built from the ground up with the needs of today’s businesses in mind.

But Corda also resonates with technologists in these firms.  This is because we designed Corda to be deployable and manageable in the complex reality of today’s IT landscape. This sounds mundane but turns out to be critical, as I’ll explain in this article.

Corda: the only DLT platform that has been designed to make your IT department smile!

The core reason that Corda appeals to IT departments is simple: we’ve designed it so they can understand it, deploy it and manage it without having to unnecessarily rethink everything about how they operate. For example, Corda runs on the Java platform, it uses existing enterprise database technology for its storage, and it uses regular message queue technology to move data around.

These details seem small, but they turn out to be absolutely crucial: they mean enterprise IT departments already know how to deploy and manage Corda! It means that firms who select Corda will be able to get their solutions live so much quicker than those who mistakenly choose a different blockchain fabric.

No other DLT platform is as standards-compliant, interoperable or designed from the ground up to be deployed successfully into enterprise IT departments. And we’re not just talking about finance, by the way. Corda is applicable to every industry where needless duplication of data and process is prevalent: it turns out that if you can make it in finance, you can make it anywhere…

But this also leads us to another key point that explains why Corda is gaining so much interest: to get DLT projects live, multiple firms will have to move as one.

They will have to collaborate.

Corda is the product of R3, the largest-scale such collaboration the financial world has ever seen and this need for collaboration is hard-wired into its design. We’ve already discussed how Corda reuses existing standards wherever possible – massively simplifying the steps each firm seeking to deploy it needs to go through. But these insights go deeper. For example, there is usually a need to manage complex interfirm negotiations prior to committing a transaction, something enabled by Corda’s unique “flows” feature and entirely missing from other plaforms.

This need for collaboration is not restricted to large institutions themselves, of course. Getting complex DLT applications live requires partnership with implementation firms and software vendors.  Our obsession with collaboration is why Corda is so attractive to so many of these firms – our partners: they see that Corda is the right platform for business and in R3 they see a partner with collaboration in its DNA.

The reality is that there are actually very few fully open-source, credible, enterprise blockchain and DLT platforms, so when systems integrators respond to client requests for proposals, Corda is the one that many of them choose to bid.  This is not only because it is perfectly tailored for commerce but because it is the result of a genuine collaborative effort over which no one technology vendor, who may also be a competitor to them, has outsize influence: they can compete on a level playing field to serve their clients.

When you bring these strands together, it quickly becomes clear why Corda is appearing on everybody’s shortlist for projects right now.

Corda is the only enterprise DLT…

  • … designed from the ground-up to solve real business problems with privacy, scalability and legal certainty engineered in from day one.
  • … built to make the IT department smile
  • … with collaboration in its DNA: engineered to be deployed between firms in a practical and realistic way
  • … with a true ecosystem of partners competing to serve clients on a level playing field: no conflicts of interest, no fear of vendor lock-in.

As always, you can learn more about Corda at corda.net.  You can join our thriving community at slack.corda.net.  Our code is open-source and available at github.com/corda. And you can email us at partner@r3.com if you want to grow your business by building or deploying Corda solutions for your clients as one of our growing community of partners!

 

Standard

Posted by

Posted on

October 25, 2016

Posted under

Corda, r3, Uncategorized

Comments

33 Comments

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!

Standard

Posted by

Posted on

August 24, 2016

Posted under

blockchain, Corda, r3, Uncategorized, whitepaper

Comments

20 Comments

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.

 

 

Standard

Posted by

Posted on

April 5, 2016

Posted under

blockchain, Corda, distributed ledger, r3

Comments

101 Comments

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!

Standard

Posted by

Posted on

January 4, 2016

Posted under

blockchain, careers, distributed ledgers, r3, shared ledgers

Comments

8 Comments

It’s New Year… Time to change the world

We’re hiring!

  • Are you a talented developer?
    • … who has experience of banking technology and a passion for blockchain technology?
  • Can you tell your nostro from your vostro?
    • … and do you have an intuitive understanding of why it’s quite so hard to change anything in a bank?!
  • Do you understand why Bitcoin works the way it does?
    • … and can you explain the block size debate in a way that all sides would agree was fair?
  • Can you explain why $100 at Chase is different to $100 at Wells Fargo?
    • … and can you design a data model that reflects this reality?
  • Do you have a passion to transform the world of finance by applying insights from the worlds of cryptography, blockchain technology and distributed systems?

If so, we should speak.

At R3, we’re working on what I think is the most interesting and exciting technology project in finance for years and we’re hiring talented, motivated professionals to turn our vision into a reality.

If you think “a blockchain” is the answer to every question then you probably shouldn’t apply.  But if you think the application of modern cryptography, consensus techniques and modern internet-scale technologies to some of the thorniest problems in financial technology sounds exciting, please email me.

Before you do, however, some background.  Because I’m convinced many people are thinking about the problems and opportunities completely back to front…

The reality is that banks were amongst the earliest adopters of information technology and, contrary to popular belief, they have done a good job in automating previously manual processes and in digitising previously physical processes.

But there are, of course, significant opportunities to improve the cost and efficiency of the architectures that have emerged – and today’s developments in blockchain technology and distributed ledgers are showing us how.

At core, this is all about moving from firm-level systems to industry-level systems.

Today, each bank has its own ledgers, which record that firm’s view of its agreements and positions with respect to its customer set and its counterparts – and its counterparts, in turn, maintain their views. This duplication, whilst robust, is expensive and can lead to inconsistencies, and it drives a need for costly matching, reconciliation and fixing of errors by and among the various parties to a transaction. To the extent that differences remain between two firms’ views of the same transaction, this is also a source of risk, some of it potentially systemic.

The maturation of cryptographic techniques, exemplified in part by “blockchain technology”, provides a new opportunity: the possibility of authoritative systems of record that are securely shared between firms. This provides the opportunity to implement new shared platforms for the recording of financial events and processing of business logic: one where a single global logical ledger is authoritative for agreements between firms recorded on it, even though the relationships and obligations recorded remain between those firms.

I believe successful, transformational, large-scale deployments of shared ledger technologies in finance depend on the adoption of an architecture that is designed from the ground up to address the functional and non-functional requirements of banks.   And the non-functional requirements are really, really, exacting.

It’s why I hired James Carlyle, Mike Hearn and Ian Grigg to start building out our technical leadership team:  I might be CTO but I’m not remotely clever or experienced enough even to begin to figure out the answers to these questions.

And it’s also why we’re hiring talented developers, designers and architects to join our team.

So, if you’re experienced, intelligent, curious and motivated by solving difficult problems in distributed systems in finance, I can think of no better places to be working right now.

email me at richard@r3cev.com if you want to talk.