Tag Archives: r3

Standard

Posted by

Posted on

October 6, 2022

Posted under

Uncategorized

Comments

7 Comments

Ten Tips on Becoming a Better Writer

A colleague asked me an interesting question today: “how can I become a better writer?”

I’m not exactly an expert but I have opinions, and opinions are what matter these days, so I sent him an email full of ‘RGB insights’. Here is a lightly edited version of what I sent him.

I present ten tips on becoming a better writer.

Writing is thinking.

The act of writing is the act of thinking. So don’t beat yourself up if it feels painful. Thinking is hard!

You should expect to feel despair when you have a dozen half-completed paragraphs, staring out at you, none of which make sense and none of which link to each other. 

Don’t worry about it… just get more of your thoughts down on paper and then start editing… move stuff around… see what happens. If two paragraphs should logically be next to each other but one doesn’t flow to the other, maybe there’s a key step in your argument missing? Are there really two different points you’re trying to make? Maybe just choose one and save the other for another piece?

The lesson I’ve learned is not to give up at this point… that chaotic process is the process.  So keep going and keep reminding yourself: it’s like this for everybody (at least everybody who aspires to be good).

Writing and speaking are surprisingly similar, so practise both

Good speeches and good pieces of writing are basically the same thing: an uninterrupted, linear, coherent sequence of sentences and paragraphs, that the audience is expected to consume and understand.

In both cases, you have to know what you think, how you’re going to express it, what you want your audience to do as a result, and how best to say it, in what sequence, to get the intended effect.

I’m always brutally reminded of this in the days before I have to give an important presentation. Yes… I’ve prepared the ‘slides’ well in advance, but that’s the easy bit. The hard part is the rehearsal.

So I go into an empty room and start to present, as if live.

And it’s invariably a disaster.  

Yes – I can read the bullets… who can’t?  But trying to speak, uninterrupted, from beginning to end of the slideshow, cold, with no preparation, hitting the key points on each chart, setting each one up clearly, segueing seamlessly to the next page, and landing on clear concluding points the first time I do the rehearsal….?

Not a chance.  Not the first time I try. Not the third.

I have to go over it again and again… really asking myself why each slide is there… why it’s at that point in the deck… what is it trying to say? 

I find myself reordering slides, deleting some, realising there are some entirely missing slides, going backwards and forwards in my mind ensuring I can construct a clear narrative from beginning to end.

That, right there, is the writing process. It’s the exact same thing.

It’s the process of converting vague thoughts into precise, clear, logical and sequential sentences.  There is no short-cut. So don’t stress out when it feels like everybody else finds it easy and that somehow you’re bad at it. That isn’t what’s going on at all.

“Keep it short” is the wrong advice. Write as much as you can… and then delete most of it.

How long is your ‘final’ version? How many words did you delete from your drafts in the process of getting there? The latter should exceed the former, or you ain’t done yet.

You can hide a lot of vague nonsense in wordy documents and verbose presentations. After all, if you throw enough words at the wall, some of them will make sense to some people and you’ll get away with it, or so you think. But you won’t influence anybody. Nobody will learn much.

To make a difference, it needs to be tight.

This is because when you cut it down, you have to make choices… which sentences stay? Which ones go? Again: that’s the act of thinking right there. You’re forcing yourself to decide which parts of the prose actually matter and which are just filler. Deleting is often more important than insertion.

Learn from other writers

Look at how writers you admire do it. The medium doesn’t matter… novelists, bloggers, newspaper columnists… whomever. Next time you find yourself reading something from beginning to end and really enjoying it or feeling engrossed, go look at how they did it.  What tricks did they use?

Here are some I’ve stolen from others:

Start in the middle, or give the punchline first. You can fill in the blanks later. Readers will only invest in your article if they think it will be worth it. So you have to grab them quickly. Have you noticed how boring the first 30 mins ‘proper’ of each James Bond movie is as they set up all the plot? That’s why they have the exciting pre-title sequences… they know you’d walk out of the cinema if they’d forced you to sit through half an hour of exposition first. And there are lots of variations you can try here. Begin with a question to get them intrigued. Or start with an introduction that is plausible but wrong. When they realise they’ve been fooled, they’ll be intrigued and will want to stick around to find out why.

Play with style. Mix short and long sentences. Include info-boxes and quotes. Add diagrams, but be sure to give them meaningful captions and reference them from the prose.

Steal from other genres. I once wrote a paper that began as a parody of Aesop’s Fable of the scorpion and the frog. Have fun!

If you’re selling an idea, write like a (good) salesperson

At the heart of pretty much every ‘call to action’ is the SCIPAB structure. Once you know it, you can see it everywhere. If in doubt about how to structure a paper that demands action, just use this.

  • What is the present SITUATION?
    • Topical example: “Central Banks have a monopoly in the issuance of cash”
  • What new COMPLICATION explains why we’re here?
    • “Transactions are going electronic; cash will soon be irrelevant”
  • What is the IMPLICATION of this?
    • “Central banks could lose relevance and find it harder to discharge their responsibilities”
  • What do you PROPOSE?
    • “Central Banks should issue a digital currency”
  • What ACTION must be taken?
    • “Hire my firm to build it!”
  • What BENEFITS will you gain as a result
    • “You can continue to achieve your policy goals in a changing world”

Who are you writing for? If you don’t know, write for past yourself

You must have a reader in mind. Who are they? What do they know? What don’t they know? What misconceptions do they have? What biases do they have? What do you need to say, in what order, to reprogram their brain?

If you don’t know who you’re writing for, how can you possibly write something that will resonate with them or correct their misconceptions? 

The good news is: if you don’t know, then write for yourself.  What did you used to think about this topic that turned out to be wrong? What ‘a ha’ moment do you wish you’d had three years ago? 

This also makes it easy to edit your document at the end… keep editing until you find it engaging and interesting!

Keep it simple

Lots of writers think the mark of intelligence is to use lots of long words. They act like confusing their readers means they must be super smart. The reality is that the opposite is true.  

So, when you think you’re done, go back and look at your long sentences… how can you make them shorter?  Are you using a complex word when a simpler one would do? Are you speaking in riddles or opaque metaphors? Remove them

Say what you mean!

Write directly, clearly and simply. And if you can’t do this, don’t beat yourself up… it’s just a sign that you need to keep going… WRITING IS THINKING… so it just means you need to keep thinking until the concepts and arguments have fully baked.

Reuse, Recycle and Plagiarise (your own work)

Writing something well is a lot of work. But once you’ve done it, you can reuse it. After all, it’s not that much extra effort to turn an email into a blog post, or a blog post into a white-paper. Indeed, “email to blog post” is exactly what I’ve done here.

So the ‘delta’ in effort to produce impactful content with longevity is often way less than you think. Think back to the last ‘important’ email you wrote where you made a case or explained something complex. Could you now use it as the basis of an internal blog post? You’ll find your thinking evolves a bit more in the process. And then you could probably also use it as the basis of an external paper. Your thinking will be even more refined.

More often than you’d expect, a well-formed, impactful white-paper is actually the third or fourth iteration of a piece of work. So the writer didn’t leap from ‘zero’ to ‘published white-paper’… there were two or three stepping stones along the way, each of them only requiring a bit of effort, and each of them having value along the way.

Nobody is born a good writer… so don’t beat yourself up. 

The more you do it, the better you get. So just get writing. And remember that writing is one of the few things you can do where you incur a cost once – writing the darn thing, but obtain the benefit forever – it exists for all time and can have impact forever!  

But the cliché about “today’s newspaper is tomorrow’s trash” is also true… sometimes you REALLY want what you write to be perfect. But don’t underestimate the power of ‘good enough’…. DONE BEATS PERFECT.  So just write it already, hit publish and move on. 

—–

Endnote: did you spot that there were only nine tips? That’s my final insight: most of the time, most people aren’t paying attention. So you can get away with way, way more than you’d expect!

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.