155 – Richard Brown & Mike Hearn: Corda - A Distributed Ledger For Financial Services

Transcript

Hey everyone. We're looking to hire a part-time communications manager to join the Epicenter team. You can get more information about that position at epicenter.tv/apply. So, if you're interested in learning more about that, if you have think you have what it takes, go to that website and you'll find the job description and the instructions on how to apply for our communications manager position. Thanks. This episode of Epicenter is brought to you by Jaxx. Jaxx is a user-friendly wallet that works across all your devices and handles both Bitcoin and

Ether. Go to jaxx.io and embrace the future of cryptocurrency wallets. And by the Ledger Nano S, the hardware wallet which sets the new standard in security and usability. Get it today at ledgerwallet.com and use the offer code epicenter to get 10% off your order. Hello and welcome to Epicenter, the show which talks about the technologies, projects and startups driving decentralization and the global blockchain revolution. My name is Brian Fabian Crain.

And I'm Meher Roy. Today's episode will focus on Corda, which is a platform built by R3. We have as our guests Richard Brown, who is the CTO at R3, and Mike Hearn, who is the lead platform engineer. Uh very happy to welcome you both of you gentlemen on the show. So, let's start with Richard. Perhaps a bit about your background would be nice, Richard. How did you get involved in the blockchain space? Hi everybody. Um yes, so I I joined R3 in September last year, so I guess 13 months ago now. And I joined after um and in my entire career having been at IBM in various roles in um in um in IBM's UK offices. So, I joined IBM

straight out of university as a as a software engineer and I worked in in various engineering and some pre-sales roles almost exclusively in finance both in London, Europe, and across the world. And I think I got into this space. I need to go back and check the exact time the exact date, but it was a it was actually through the Economist. There was a one one column inch article just almost a throw away little article in the Economist about this strange thing called called Bitcoin. It must have been in 2012 maybe 2013 and that's what piqued my interest and I guess I won't rehearse the the story that's followed from then till now.

But but I guess I got completely sucked into the into the rabbit hole and spent a lot of time getting my getting my head around it being fascinated by it and then to be honest putting it on the shelf for quite some time until the real hype kicked off a year or so later and it just struck me that almost everybody who was purporting to be an expert about it they all comment about it. They just completely missed the point. They either were making overinflated claims for how it was going to completely transform finance without understanding finance or they were making ridiculous claims for how Bitcoin was the most evil thing in the world without really understanding Bitcoin. So, that's what motivated me to to start a blog where I spent a lot of time explaining Bitcoin and blockchain concepts to to bankers and a lot of time

explaining financial concepts to to the the Bitcoin and blockchain community. And from there I got more and more more involved in more and more work at IBM and eventually when it became clear to me that the way forward was deploying this technology at scale through collaborative efforts and through consortia when it comes to finance. When when I realized the R3 initiative was was trying to do just that it was the obvious thing for me to do for me to join in. Yeah, and for those who don't know Richard's blog is at gandol.me and it's an excellent blog.

I I you were one of the certainly one of the best writers on on the signal. She also together with another guy who's at R3 now, Tim Swanson. And we were in contact with you a long time ago actually and and kept asking you when you were still at IBM like we you need to come on the podcast, we need to do an episode and you kept saying like I'd love to. I'm not they don't they don't let me ask me again in a month. So we did that for like I don't know a year. And maybe not a year but a long time. And then you joined R3 and of course asked again like are you ready now? And they said still not allowed to. So we're glad that finally you're allowed to.

No, I'm glad to be here and you know I used to get I remember the emails I used to get from you or I used to dread them because I could never say yes. But the main reason I didn't say yes was when you when you come on things like that you want to have something to talk about. You you you can you can you can commentate or you can you can give sort of broad views but I think these these these these these podcasts are are really valuable and fascinating when when when when we're talking about you a real thing with the people who are building it. So so I'm delighted we waited until now. Yeah, and of course Mike who's been on this podcast twice before I think and both times they got a lot of attention.

I I remember the first time you were on you made a statement that you know Bitcoin development has ground to a halt which then got a lot of a lot of attention and and then I think actually the last time you were on that was shortly before or that was sort of with Bitcoin XT controversy when you guys were trying to you know get bigger blocks and get to switch away from Bitcoin Core and then shortly afterwards you left. So how is how is life post Bitcoin?

Good. It's more productive. Yeah. You don't miss the arguments the No. anyone, right? That's the question. I don't think so. But yeah, that was about a year ago, wasn't it? I think it was the last time I was on the show. Yeah, around October, November time. And I guess now from sort of your outsider's perspective, I mean, at the time a lot of people disagreed with you. Today, I think a lot of people have sort of well, opinions of course still diverge, but I would think that your position back then has become more like, well, yeah, you kind of right and in that a lot of changes didn't happen. Are you still following what's going on and how do you look at it now with some

distance? Um yeah, I still keep half an eye on what's going on in in the Bitcoin community. I don't, you know, I don't post or comment anymore or anything like that but I think yeah, the way events have worked out, pretty much everything that I I predicted in those in the articles I was writing last year have have come true. You know, with there's been media that said oh there was a show on NPR radio in the States where the show was about Bitcoin and it started by the two journalists saying, I tried to send money to the other guy and it didn't work. And that was one of the things I predicted would happen. So, you know, the bad media coverage of the problems.

So, yeah, I I keep half an eye on it. Nothing really seems to have changed. So, I haven't been paying too much attention. But uh it's a shame things things don't seem to have changed much in one year. Yeah, and I think the the worst thing is even though I'm sure people still work on a lot of interesting technology, even the guys on Blockstream, right? Doing a lot of interesting things with segregated witness and stuff, but there's just the the community and the way of making decisions has become so divided that it's the project certainly hasn't developed very well.

But enough of that, so that's not why we're here. Um so, R3, a lot of people of course know about R3. At the same time, it's this kind of mysterious and strange entity, right? It It's sort of a startup, but then it like is set up in a completely unorthodox way. So, can you share Can you guys share a bit about uh what's the origin story of R3 and and what does that organization look like? Yeah, sure. Why why why don't I take that? So, um yeah, it it's strange how we were seen as this this mysterious thing.

We certainly don't feel mysterious to ourselves and we we do try to be open, but um um but maybe we can go some way towards um addressing that here. So, so R3 was founded um some time ago. We we came to to public prominence in September last year, September 2015, when we announced the founding of a of a consortium of of large financial institutions. Um I think there were nine at the time. Um it grew to 42 by the end of I think last November. And we now have over over 70 members. But uh but R3's history actually goes back I think a year or so um before that. Um and there's I guess there's there's quite quite a lot of um I got quite a lot of interesting history, but perhaps one or two of the things that um that are are most pertinent are that it was it was

founded by our CEO um David Rutter, who'd spent um a career you know, over three decades on on Wall Street. Um and and um although this wasn't his his prime his prime um focus over those years, his career was was punctuated by success in building a series of very large-scale, very successful industry consortia. Um he seems to be the the person in the world who's able to to help bring together otherwise you know, sort of competing um institutions, bring them together um when when when something collaborative needs to be built. Um for those who know the financial markets, he was um chief executive of of EBS and of BrokerTec of of of of large um collaborative efforts.

Um and all the way through 2015 and as far as back in 2014, um after leaving um his after leaving his his previous role at a senior role at Wall Street. He He took a trip out to the to the West Coast to to understand more about what was going on and he got very close to what was happening in Bitcoin. He's He's amongst the first to talk in public about how the the underlying technology, you know, what we now call blockchain or distributed ledger technology had applicability beyond the the Bitcoin use case and he realized that if at least his belief was if if if things were going to happen in in mainstream finance and in financial markets and beyond, then this is inherently shared

technology. It's inherently distributed technology. It requires It requires organizations to come together to understand it, to evaluate it, to to figure out what needs to be done, figure out what needs to be built and to do it collaboratively through a consortium. So, he he drove that was the insight driving the formation of the R3 consortium. So, fast forward to September, that got off the ground. I joined. We rapidly got to 42 banks. Now now now north of 70 and we began our work in earnest 13 months ago. So, the consortium is one thing and the consortium if is is sort of like a place for experimentation, you know, where you get like those banks together and they kind of run these these little projects and uh

and but then the separate what you guys have been working on is almost like a separate project within R3, right? Um kind of. So, the the thing we we began with and and we were we were open about this at the time was that there were always um three primary strands to the to the work we were doing with our members and and with the community more broadly. There was architecture and doing that through what we call the architecture working group and that's what I chair and I'll come on to that in a moment. There was always and continues to be a a very laser-like focus on what we called use cases, but again I guess what most people would think of as a product. So, you know, to what uses can this technology be put that's valuable for that's valuable for

members and and and for society. And then, as you mentioned, there is also our our global collaborative lab, or what's now our lab and research center, um which is a powerhouse for running um running um projects. And those projects might be evaluations of of specific technology. Now, the insight there is um if um if multiple institutions are interested in evaluating the same technology, rather than each one running it to slightly different standards, slightly different evaluation criteria, let's come together and run it once and and and and share and publish the results working in concert with the with the provider. And we we I think we'll probably be much earlier this year on with some of the some of the experiments we've done. But it's also where also where members and

others can come together to to work together jointly on projects looking at specific specific product or or or commercial ideas. So, that's a real powerhouse for collaboration amongst the the member financial institutions and and beyond. Um but but your question about technology, um we we began as as as one of the three strands was and remains our architecture working group. And my um and my my mission and I actually wrote this in in in the blog post that I that I put out earlier this month. Um the mission given to me was um was set as the very first decision of our steering committee. That's the thing that the the the the senior senior executives from all our members sit on. The very first

decision they made was to formalize the creation of the architecture working group and give us the mission to establish the architecture for an open enterprise grade scale um ledger for the processing of financial events and automation of business logic. Um and so, that that was our mission to um to to answer that problem, answer that statement. And I guess we'll go through that in more detail. But um but the the vision right from from was to do solid requirements-based engineering to understand what this technology's relevance might be. Not all the things this technology can do is relevant to finance. Understand what its relevance might be, understand what needs to be done to make it deployable at scale securely, reliably, and usefully in in finance, and then go do

it. So, in in in pursuit of this aim, um like at the start of the year, um there were many news stories that the consortium had taken some technology, let's say it is the It's technology stack, and they had created um I guess like small experiments where commercial paper trading was being done using the It's technology stack, but all the partners of the R3 consortium were kind of involved in that experiment. And the initial impression that outsiders like me got was um that R3 is going to just uh not build any technology of its own, but it's going to act as a filter for all of these projects, like check all of them out,

see what ideas are good, and then deploy them at scale in the consortium. That's what my initial thought process was. But then, I think in the middle of the year you came out strongly in with with Corda and indicated that there would be an independent platform. And now, like you've announced that Corda is going to be open sourced on November 30th. So, uh so the question is like why did you go down this direction of building something um bespoke or new other than just leveraging technology that other people are building?

Sure. Okay, so I'll I'll start with that, and that might also be a good segue in into some some observations from Mike as well. So, the first thing I should say is um throughout this process, um and even with the open sourcing of Corda, um we don't claim that Corda is the answer to all the world's problems. Just as I've been uh very very vocal um in in public and and on my blog and and so forth uh saying that, you know, Bitcoin doesn't solve everything. Bitcoin is good for the problem it solves. Similarly with R3 and these uh and Ethereum and all these other platforms, um, we don't we don't we don't claim that that Corda solves all these problems. Um, but what we do claim is it solves a specific set of problems that are pertinent to the financial industry in particular, although not or

not exclusive to the financial industry. Uh and we think it fills a gap that that other platforms don't fill. But but how do we get to the point where we even decided we needed to build something like Corda? Uh and for that it goes back to the mission statement of the the architecture working group. And and excuse me, the the work we did, um, the work we kicked off, um, at the end of last year once we were up and running. And the the the two questions that I I drove through the architecture working group because I I was petrified, if if you like, you know, almost paranoid that simply trying to apply, you know, blockchain to business or applying distributed ledgers to finance without a good, solid set of requirements and a good description of what problem we're trying to solve was not good

engineering. It was it was it was not an appropriate way forward. We needed something more solid than that. So, as I say, we we we kicked off, um, two two parallel pieces of work. One was to to look at the existing platforms and answer the question because, you know, it may seem obvious to those of us who are steeped in this space, but to answer the question, is there anything genuinely new in the in in the blockchain and and and and the the broader distributed ledger space? Um, you know, it's not often that that breakthroughs in computer science um come through. So, let's be clear, is genuinely new here beyond say the you know the advent of of of of the cryptocurrency revolution with with Bitcoin and the like. So, number one, what if anything is new? And then question number two, you know, to the

extent there is something new, what if anything is the is the applicability to finance? You know, it it does not follow uh or rather it is not obvious that the technology that was originally designed, um, some would argue to to disintermediate financial institutions, it doesn't follow, it's not obvious that that technology is is going to be one of the most important technologies for them. You have to make a compelling argument for why that's the case. So, um so without going into all the detail, we we can elaborate later. Um taking those two two questions in turn, you know, what if anything is is new about this space? Well, the conclusion we reached, and again, it's obvious to those of us who are steeped in this space, is that yes, there is something new. This is all about building systems that are deployed across and between

large numbers of of entities who don't necessarily know each other, who don't fully trust each other, and yet which can bring all these entities, can bring all these parties into consensus about the existence, the nature, the evolution of some set of shared facts, some set of shared facts that exist between them. Now, that seems quite a quite an abstract definition, and maybe it's not perfectly right, but it's a but it's for our purposes, it's close enough. You know, it it it captures Bitcoin. Bitcoin brings untrusting people into consensus about how many Bitcoins there are right now, which addresses own them, who's allowed to spend them. Ethereum, we bring people who don't fully trust each other into consensus about the state of the of the of the of the Ethereum, the global Ethereum virtual machine. Um and and we didn't really have that before. You know, we had we

had distributed databases, but they're typically run by one organization. We have systems that are deployed by a centralized institution that everybody else agrees to trust. But but but but but data that is managed somewhat cooperatively across a large number of of of mutually distrusting organizations, and that works reliably, yeah, that's that's kind of new. That's really quite interesting. So, if you then turn attention to finance, you say, "Well, where in finance do we have examples of of of of entities who may want to interact with each other, might want to transact with each other, but don't fully trust each other?" You know, they wouldn't trust the other side to manage all their accounts for them. But where there's a need to ensure that all relevant people are in consensus about the existence,

the nature, and and the evolution of some shared facts. Well, you could argue perhaps with only a little exaggeration, that pretty much defines the financial system. Certainly the back offices of the financial system, where you've got people who are trading with each other, but each who needs to keep track of their own records. They need to keep track of all the details. They need to build and maintain and manage systems that that that track those agreements and those those trades throughout their life cycle, and they have to agree at every step. If they calculate different values for who owes what to whom, then we've got a got a break. We need to go through an expensive fixing process or process to fix it, and there's a huge amount of reconciliation of paperwork and communication we we need to go through to bring all these disparate systems that should all be

doing the same thing to make sure they actually are all doing the same thing. So, so that's kind of like the that that's the journey you go on. What if what if anything is is new in this space bringing interesting parties into consensus? What might the application be in finance? You know, anywhere where the same information recorded in multiple places, which is which is pretty much everywhere. But then, after a long meandering talk, which I apologize, to answer your question, why did we get onto the path of thinking we needed to build Corda? Well, you then look at the technology that that's available. And of course, it it it it's it's also obvious to state that the technology that inspired this movement, the technologies that that that that that take people like us on this on this on this thought process, you know, they they weren't

designed to solve problems like reconciliation in back offices in in investment banks. And that's no criticism of those technologies. You know, Bitcoin is a very elegant successful solution for the problem it solves, as is Ethereum, but neither of them were designed to solve the problems I've just outlined. So, um and and this is perhaps the last point on this. So, so we so we we reached a point where we where we needed to we had there's a fork in the road. We could either spend a a of time um trying to amend, edit, and influence the the existing platforms to move in a direction where they they could um adequately solve those problems, um or we should build something ourselves. And the And the

conclusion we reached was it simply wouldn't be credible to go out into the market, and remember this is the back end of 2015, to go out into the market and simply tell everybody um you know, simply assert that that the the the the technology isn't quite right or doesn't do what we want. You know, it's very easy to criticize, it's very easy to poke holes. It's altogether harder to um to to show a workable alternative. So, we thought it was incumbent on ourselves to show that yes, these ideas we have for other ways of building these systems based on blockchain principles, um to show that those those approaches actually could work. That actually um could um could address some of the problems around scalability and privacy and expressiveness and so forth. That um that we that we saw in other platforms.

Um that was a key reason for for bringing Mike Hearn in, and and he'll he'll talk more in a moment. Um but that that was the genesis of Corda, and as we did more prototyping, as as it evolved, as it as we as we followed the almost the inexorable logic of the um the inexorable logic of the requirements and the analysis, um you know, Corda developed and it it it it matured. We did not allow ourselves to be to be constrained by what other people had done in the past. Um and you know, in in short order we ended up with a design that is is is heavily influenced by, but is fundamentally different to the other platforms out there. And hence why we think it's worth why we thought it was it was worth continuing to invest in, and why we now want to share it with the

world. Let's take a short break to talk about Jaxx. Jaxx is a multi-coin wallet created by the people at Decentral. Now, in the past, if you had a whole bunch of cryptocurrencies, it was a pain to handle them. You either had to leave them on an exchange, which was insecure, or you had to have all these different wallets, which was a hassle. Fortunately, now with Jaxx, those medieval days of darkness and misery and suffering are over. Jaxx supports multiple cryptocurrencies and new ones are being added. But, it's not just storing cryptocurrencies you can do with Jaxx, but you can also exchange them directly from within side the wallet thanks to their ShapeShift integration.

And since there's only one seed, Jaxx makes it super easy to back up and sync to your other devices. Jaxx works with Windows, Mac OS, Linux, Android, iOS, and has browser extensions for Firefox and Chrome. So, go to jaxx.io, that's jaxx.io, to download the wallet and get started today. We'd like to thank Jaxx for their support of Epicenter. So, moving on a little bit to the more the more technical side of Corda, what are the the kind of high-level decisions that you had to make in order to come up with an architecture and to those decisions?

There's going to be a technical white paper, um which I'm writing at the moment actually, which will go into all of this in like a lot of detail. Um it will it's it's not quite a specification in the same way that the Ethereum yellow paper is, but it it covers a all of the design points in a lot of detail. Um so, there were a bunch of things. One is um we felt pretty strongly up front that you know, there's two models of computation right in in this space. There's the Bitcoin model of transactions with these inputs and outputs and you have the unspent transaction output sets and that's the database, the UTXO model. They call it in in the finance space and then you've got the Ethereum model, which is sort of a distributed computer.

And we we chose up front to go with the Bitcoin model for a bunch of reasons and which you can talk a little bit about why, but um it had a whole bunch of advantages. It but at the same time um a lot of uh you know, financial developers actually liked the Ethereum developer experience. It's a much more developer-friendly project. Um you can use You don't have to write code in assembly for example. You know, you is the bit easier to think about and so a lot of the design decisions that we've been making are about how do we take this model of the Bitcoin users which has all kinds of advantages around privacy and scalability and all kinds of other nice features that we want and yet make it easy to use for developers who don't really want to think about the details.

But a lot of the and the other one was the other design decision that was key and then these two had been made when I joined R3 already. Limited data distribution. So data goes only where it needs to go. If there's no global broadcast in Corda anywhere and these two design decisions as we explored them they led on to a whole bunch of other design decisions and they led on to even more design decisions and this is probably the most design heavy project I've ever worked on actually. Almost all Satoshi once said about building Bitcoin that actually you know, he spent over two years on it and and almost all of the work was design.

It wasn't actually coding. It was mostly design work and this is very similar. Yeah, and I guess the advantage you guys had here was that Satoshi did this in isolation or maybe with some collaborators whereas you had the the big advantage of having a significant organization with resources and with people to speak with as opposed to building something that's like totally novel and you can't really test so well whether the design works or not. Yeah, well, you know, I was I was also sort of the first full-time developer hired. So one of the tasks that we've we've done this year in the past 12 13 months is build a developer team from scratch by hiring right primarily in well actually almost entirely in London except for me. And yeah, often you know,

what a lot of the process of designing Corda has been we will come up with a design we think works based on our own knowledge of finance and we have in-house experts and we have team members the team is a mix of people with computer science and cryptocurrency type backgrounds and also people with backgrounds in banking and finance. They sit next to each other. It's a unified team, and and you know, we would run ideas past them, and then also go to the members who all contribute developers and architects as well. And we would write design documents and say, "Hey guys, is this sensible? Does this meet your needs? Is this stupid? What do you think?"

And um that feedback process Uh and they've been contributing in other ways, too, but the feedback and the discussion process with the members has been really invaluable for yeah, just doing some reality checks and making sure that we're not going going off course. That said, you know, Bitcoin's design has a lot of really really well thought out stuff in it. In many ways, it's still um you know, it stood the test of time well, and and in many ways, it's still a pretty elegant design, especially the original one. Um if you go back to 2009 when it was first released, Bitcoin's design has actually got worse over time in my view as people have tweaked it, but the original design was actually pretty good, and we've incorporated a lot of ideas from that, except for the blockchain. You can argue that that's the most important idea, but actually, I

don't see it that way. We don't see it that way. There's a lot of ideas in Bitcoin that is not mining and blockchain-related, and we've incorporated a lot of them into Corda. So, when when Richard was speaking of like um we came across this idea that um the fundamental innovation in, let's say, the blockchain space for lack of a better word, is the ability to have lots of diverse participants agree on a shared set of facts right? And um and we're trying to apply this to the context of financial services, investment banks, or banks, right? And Corda is a platform built to enable that.

So, with with that in view, what are the big design decisions did that you took? And what are the let's say, the computer science components that you're using? What kind of contracts, what kind of virtual machine technology, what kind of consensus etc. So should I should I just give a little bit on on that agreement concept just to get that clear and then let Mike come answer the computer science question. Because because you you correctly identified something and and I I I guess in my my intro I hand-waved over it. I said the you know the the shared facts in in finance or or agreement. And I use the word agreement

because contracts make people think of smart contracts and and people have already got mental images and mental models for what they are. Which may not necessarily map to to what we're doing. But when I say agreement, I mean contract. And the reason I say that is you know if you look at anything any relationship between a customer and a bank or a bank and another bank, at its heart it is a contract. We don't always think about it this way, but the reality is it is. So in the in the most obvious cases, you know a very common financial instrument is the interest rate swap, a very standard derivative contract. And it's a contract between two identifiable parties. We know who they are and we have to know who they are because under different circumstances one will owe money to the other or the other will owe money to the

first and they need to be able to enforce those claims. But it's a contract, we know who the parties are to it, we know its life cycle, we know the events that can happen on it, we know the rules that apply under different circumstances. So that's quite clear. But the the observation maybe the insight we made was other things that don't look like contracts are also. So when you put money into a bank, you deposit money with a bank, you're not really depositing money with a bank, you're lending it to the bank. You now have a claim on that bank. There's no vault in sitting in there's no there's no there's no there's no sort of vault in the basement with your name on it. So actually the act of depositing money with an account with with a bank is actually entering into or or or or or a

contract you have with the bank that says it the bank now owes Richard this amount of money and under the following circumstances Richard can ask for it back. So actually this idea of of of modeling um modeling financial relationships as as contract but it actually turns out to be quite um general and and generalizable. And it then allows you to ask a question which is well, who are the parties to this contract? Who needs to know about it? Who needs to observe it? Who needs to verify it? And under what circumstances might other people downstream need to verify it as well? So very quickly you can then begin to ask questions just as I've said about what is the data that needs to be captured?

What's the overarching legal agreement that governs it? What are the rules that govern its evolution? Who needs Who needs to sign any transitions? Who needs to be told about them? Um and and perhaps importantly, how do we ensure that, you know, two proposed transitions to to to something representing a contract are not in conflict? Um that leads quite naturally, I would argue, to to our selection of the UTXO UTXO model because the UTXO model, just as in Bitcoin, is is you know, the transactions in that in that um in that system, they're very very explicit. They say, you know, these are the current pieces of information in the system, the current contracts if you like in our model.

I I assert they're current. I assert they are they are they are pertinent to me. Here is how I'd like to change them, replace them with these new contracts. Here's the proof I'm entitled to. Um and they're as self-contained units that can be verified independently and in parallel with all the others because it's completely completely um explicit about which parts of the data set it's updating in a way that's much much harder to do in a general purpose virtual machine. Um so so that's that's that's how we thought about it from a business context, but of course everything I'm saying here you can argue is actually just a set of requirements. How it's actually implemented is of course a different story and I guess I'll I'll I guess I'll let let Mike figure it out.

So I'm going to assume uh the listener's familiar with how Bitcoin works. I don't know if that's a valid assumption, but it'll save a bit of time. So, in Bitcoin every row in the database is an quantity of Bitcoin and then a little program that determines who can access it, right? The script and the value. Um in Corda, uh we want to store more stuff than just a quantity of cash, right? A quantity of a single currency. So, this is we I think Richard has talked a bit about states already. A state is um currently in the current design, it's actually an arbitrary collection of objects. It's an object graph.

We may restrict that a little bit um in future, but one of the one of the things we've been doing this year is a lot of experimentation and prototyping and proof of concepts with Corda to see how much power developers really need and where we can restrict them a little bit to get other features and where we where we can't. So, currently a state is a full-blown serialized object graph. And if you want to represent something like cash um in a in a Corda transaction, all all uh Corda is like Bitcoin in that all entries in the database come from transactions and you can refer to them with a hash of a transaction and then an output in And to do something like representing cash, the state would not only include number of pennies, right? The the sort of equivalent of satoshis for fiat money,

but also um the issuer, right? Because um dollars issued by Barclays are not the same thing as dollars issued by a central bank. I should say pounds issued by Barclays are not the same thing as pounds issued by a central bank, right? There's like you're exposed to default risk and so on. They're not quite the same thing. And then there's a few other, you know, things that uh that you have to track as part of even something quite basic like So, Corda has a it can represent currencies, but it can also represent other things like uh like we've mentioned the contents of deals, an interest rate swap, all this stuff that will that will put in the outputs where a Bitcoin transaction would have only a value.

We mentioned a little bit at the start, right? We're using Ethereum developed zone virtual machine for this, so did Bitcoin, for the task of expressing the the logic behind new transaction types. Um we chose to modify the JVM to do that because again, this is coming back to the, you know, we're designing this for banking and business. Um, virtual machines are well-understood technology, right? This is not a new area of computer science by any any means. Um, there are high-quality, robust, industrial-strength virtual machines out there. The most successful is a JVM in banking.

Java and JVM bytecode is everywhere. A lot of banks are now using things like Scala as well. You can compile Haskell to the JVM. You can A lot of languages which crop up repeatedly in finance, you can run on this platform. You've got tools, you've got IDEs. It doesn't make sense to us to reinvent all this stuff. So, part of the the work we've been doing with Corda is allowing you to define new transaction types by defining new smart contracts in You don't have to use Java. In fact, Corda itself is written in a language called Kotlin, which is very new. Um, it's but it it's compatible with Java. So, we've We've done a bunch of things there.

Another thing which is very different and will strike people immediately when they look at when they compare Corda with Bitcoin is that in Bitcoin and Ethereum, when you create a new transaction, you sort of pick some random peers on the network and you send it to them and they they pick some more and they propagate it around, right? And the network sort of gossips new transactions until everybody has seen them. And nodes on the network don't have any real identity and they don't have any real obligations. Effectively, these systems attempt to build a reliable component out of unreliable parts and such a thing is always statistical, right? You can't always reason about how reliable the Bitcoin network is because the people making it up can disappear at will, they can arbitrarily sort of deviate from the protocol and who even knows who's doing

it. This is how Bitcoin ended up with miners that won't make big blocks. In Corda, it's structured more like the email network. So, every node is identified. Um, every connection between them is secured with TLS and and certificates that we issue by If well, whoever runs a Corda network is issuing it. Doesn't have to be us, right? You can run your own Corda networks, of course, if you want with different rules. And then, nodes only communicate with each other when they actually have a specific reason to, and there's no global broadcast. So, if I want to send cash to you, then I connect to your node, and I give you a cash transaction, and then you say, "Oh, I don't know the dependencies of this, so I can't verify.

Give me the dependencies." And I give you all the dependencies. And then, now you have all of the dependencies of that transaction. You have the entire graph. And then, next time you send it onwards, you send, you know, you tack your own transaction that moves the cash or spends the cash on the end, and then you send the whole graph onwards to the next guy in the chain. So, the data propagates around the network lazily. You You see only data that you need to in order to verify the parts of the ledger that are interesting to you. And this has a whole bunch of interesting uh consequences. Like, you can actually, in theory, you can run two separate Corda networks that are totally independent, and then merge them together later, right? Um both sides need to agree to trust each other's notaries, and we can talk about notaries

a bit, if you like. But, basically, once you've established connectivity between them, and if they trust each other's identities and um notaries, then you can actually do that merge, and it all just works, because there was never any assumption that all data was visible to begin with. You can't do that with blockchain-based systems. And again, this is one of those requirements that sort of comes out of talking to people who work at banks. And they say, "Well, you know, gee, we would like to start with an internal deployment, maybe, and then, you know, join the rest of the world a bit later after we're comfortable with the technology." There's always going to be political concerns. Maybe some countries want to have their own separate network for political reasons, if they're in a fight with the West right now, and maybe later it's resolved, and you want to bring

everyone back together. There's all kinds of reasons why it's useful to be able to do that. Today's magic word is a Corda. That's A C C O R D. Head over to letstalkbitcoin.com, sign in into the magic word, and claim your part of the listener reward. I would prefer that we try to break down this excellent explanation like through an example, right? So, so one of the examples that that Richard came up with is the example of the interest rate swap.

Yeah. So, let's try to just talk about what an interest rate swap is and then like fit it into this quota model. How would How would it work there? And then we'll keep on adding parties. So, we might start with the basic interest rate swap. So, let's say it's Brian and I and we are two different financial institutions and what we want to do is an interest rate swap. So, we are going to take I don't know a standard uh interest rate index maybe from I'm not even sure maybe the Fed funds rate or something.

So, this this standard interest rate index that keeps moving every day and Brian and I kind of want to have a contract that let's say the interest rate is 2% today. And if it goes to 3% for every percentage rise in in interest rate uh I don't know Brian pays me like 10 million dollars and every percent fall in the interest rate I pay Brian the same 10 million dollars. Let's say it's it's something very similar simple like that. So, interest rate moves depending on how much it moves either I pay to Brian or Brian pays to me, right?

So, now uh so that's a contract. Now, Brian and I want to do this contract and this contract fundamentally requires me to trust Brian to fulfill my obligations if something is due to me and Brian to trust uh uh myself, right? Yeah. And and maybe we are going to settle every 3 months. So, so we're going to do the contract right now and then 3 months later we're going to see what the interest rate is on that current day and then whether if it's higher or lower than 2% we'll calculate who needs to pay who how much and then we'll exchange that amount. 3 months later we'll do the same thing again, etc, right?

So, how would this kind of transaction between two financial institutions be modeled as a Corda object or a Corda contract? Well, you know, at the end of once we finish this open source, I can just point people to the code cuz it the code base is contains um it actually contains two different um what we call Corda apps. Uh they implement uh interest rate swaps. Um they will probably merge them at some point. They they do different things related to interest rate swaps. Um but basically, yeah, you start by defining a state um to represent a deal and and because a state is just a bag of objects, you know, you can represent this in a bunch of ways.

Um the Corda spec incorporates parts of the um the Java spec into itself because that's a very well-specified platform. Like there's detailed documents on how it works. So, you can do things like record timestamps um you know, using the standard library types and things like that. You can define fixing schedules and so on. Once I've put together a transaction with no inputs and one output, so this is like a genesis transaction, but there's no there's no blockchain, right? It just exists sort of floating in space. Um I give it a unique deal ID or whatever to make sure that the hash of this transaction is unique. Then we then we start what um Corda calls um flow, right? So, in a system where there's no global broadcast and communi- all communications take place between like specific nodes, you need uh

and also the protocols involved can be very complicated. You need somewhere to manage that. You see these little like node-to-node protocols crop up in other systems, too. Like Bitcoin has like the payment protocol bit 70. It has um micro payment channels or just payment channels where two nodes are sort of interacting outside of the blockchain or outside of the standard network to to come to some sort of deal or some sort of agreement between themselves. And And that kind of thing is the to the norm in Bitcoin and Ethereum, but in Corda that is the norm. That's how all communication takes place.

So, I would create such a transaction. There's this component in a network called the network map, which is basically a map of identities to nodes and and vice versa. Um so, you know, someone would type in, "Oh, I want to do an interest rate swap with um you know, with Brian." Right? And then press enter and off it goes. It finds Brian's node. Starts a flow with them. Proposes that transaction. The other side says, "Yeah, looks good." Sends me back a digital signature. All right. So, at this point now we have a sort of mutually signed transaction and we both agree on the hash of this transaction so details are agreed at the byte level. This is very simple, of course.

Then we want to start evolving that deal while it is it changes. Every time we want to fix a new we want to re-fix it to an a new interest rate. For example, there may be an oracle in the network that knows interest rates. So, we can then embed the new interest rate into a transaction. Corda transactions have inputs and outputs just like Bitcoin. They also have um commands, which is a sort of because you can cuz in Bitcoin there's only like two kinds of transaction, right? There's ones that move money and there's ones that create money and you know it's a creation, you know it's a genesis transaction cuz of the position in the blockchain.

Corda transactions can do many different things. So, you need a way to sometimes distinguish what it's doing and that's what commands are for. So, you create another transaction. Has a you know, fix the interest rate command in it. You would send then you would start another flow. The flow would send it to an oracle. The oracle would sign because it sees it's valid. You get that back. You send it to the other side. The other side verifies it. Says, "Yes, I'm signing too." Sends it back and there's a multi-step procedure here where you're moving signatures and transactions and data around. Then we want to introduce notaries perhaps, which are how um a notary defines you know, basically a notary is the part that stops double spending. And I whereas in um you know, in the systems that most people are familiar with, uh the consensus mechanism is bound very

tightly with the definition of the network. Bitcoin has one blockchain that defines Bitcoin and Ethereum, same thing. Um a Corda network can have multiple different competing notaries, actually. Uh and different transactions can be deconflicted, like double spend deconflicted, by different services. Um so you can then start involving one of those, that's another step. Maybe there's a step where you report to a regulator, that's another step. These protocols can become very complicated, and so one of the things Corda provides is what we call the flow framework, which allows you to write these protocols in very straightforward code.

It looks um it looks like the simplest possible code you can write, I would say. Um basically, the flow framework gives you what appears to the programmer to be kind of unkillable uber threads, which can survive for days or weeks. They can survive process restarts, they can even survive upgrades of your node in some cases. So you write your interactions like send a message here, get a message back, send a message there, get a message back. Um and then by the end, you have agreement on what's going on, and that is then committed to your node's vault, we call it. Bitcoin and Ethereum have wallets, and that's a little bit foxy for banks. They They want something a bit more robust-sounding. So we have the vault.

And then one of the things Corda states can define is a relational mapping. So once no once once these transactions have been processed, um they get converted into relational database tables and searched into a relational database. And you can then join those tables with your own internal apps state, right? So you can have information which is both on the global ledger and in-house, like your customer database or whatever. And then you can just join that data together in the normal relational way using join keys and select statements in SQL and so on. Okay, so that's that seems really cool.

So the way the way I I didn't think of this is um that you're you're you're essentially taking all of these contracts like so a contract between me and Brian which might be an interest rate swap or some other kind of contract representing this as a digital object. And then every time we we we we create this digital object and then we do transactions to modify the current state of this digital object. So this kind of keeps moving. Every time we do a transaction we ensure that if me and Brian are the parties to it then there's my signature on it and Brian's signature on it and maybe a notary signature on it to make sure that some rules of the transactions are also

being followed, right? So all of these signatures keep on accumulating and that tells me what the current state of my contract with Brian is. And now I I could have contracts with many parties like with Brian, with Richard, with yourself and I could collect all of these objects to collect all of these contracts together in one relational database and that kind of shows me what my firm as a whole is doing in in the market, what contracts I'm participating in in the market. Yeah, that's pretty much it. I would clarify one thing which is you don't always need a signature from every involved party, right? The set of signatures that you need for any given type of transaction is defined by the smart contract code itself. You don't

want to be in a situation where your your counterparty has defaulted and you know, the the courts have moved in and seized all of their computers and the the electricity company cut them off because they didn't pay their bills and now you can't update the database to reflect they're in default cuz they're not signing. You can you know, in some cases you can advance these agreements without all parties being involved. It it depends on how the smart contract code is written. And that is it's worth it's worth probably adding to me also there's a good even in the non-default case there's I guess there are good game theoretic reasons why we need this as well. One of the Um, and talked about you know, requirements and and what problems we were trying to solve. One of the motivating examples we used um in in the

early design work was that of a just a traditional um option agreement, put option, a call option. Um, you might model that as an agreement, you know, maybe I have the right to um I have I have the I have the right but not the obligation to um to demand that I can buy a security from you. Um, they have deadlines, they they expire at a certain time. Um, if it was just before the expiry um and I wanted to exercise it and that requires your signature as well for it to be valid. Well, you might have just the slightest incentive to to run a bit slow and um and and allow the clock to tick past um past midnight. Um, so so that would be I guess you know a perfect sort of like business as usual example of where only the exerciser and

then the notary to um to commit to the timestamp um is required to sign it. It's also why I guess we may not get into this detail. It's also why the the notary as as in the the cluster that that provides confirmation of of no conflict is also the entity that commits to the time. Those two things can't be separated. Let's take a break to talk about the Ledger Nano S, the new flagship hardware wallet by Ledger. I'll pass it over to Ledger CTO, Nicolas Bacca, who can tell you all about Ledger's security features and SDK. So, Ledger Nano S is a personal security device based on the secure element screen and button so that you can verify everything that is done on device and make sure that you are really doing what you wanted to do. Compared to our

previous solution, this device is based on the latest generation secure element, the ST31 from STMicro. The ST31 is an is using a secure arm core, which means that you can have the same ease of development that you would have on a generic um microcontroller but benefit from the security features of a secure element. Security features uh include an application firewall at the lowest level that let you protect applications from each other, which means that you can load multiple application on the hardware wallet even post issuance. And you as a developer will be able to leverage these features to load your own application without our authorization and without any kind of authorization from the vendor. We will be providing

this device with an open SDK on that let you do anything you want with this device. We provide sample applications for cryptocurrencies, different cryptocurrencies so Bitcoin, Ethereum. Uh and we will also provide a FIDO authenticator and you will be free to add everything you like. For example, you could add some secure messaging, some encrypted chat. And you'll see that the solution is quite powerful and very easy to develop with. The Nano S sets the new standard in hardware wallet security and usability.

You can get yours today at ledgerwallet.com. And when you do, be sure to use the offer code epicenter to get 10% off your first order. We'd like to thank Ledger for their support of epicenter. So just if if you briefly kind of bridge the gap here to to the blockchain idea, right? Cuz in a way what you do in blockchain is that you say you have these transactions and and they all you know, you put them together and you timestamp them so you know the exact order and and then there's this global agreement on the order. Whereas here I think you're you're still having the same idea that you have kind of transactions or events that are between parties and they're sort of you know, hung uh cryptographically

on top of each other or sort of chained to each other so that one can follow the whole history, verify everything. But then you say there's no need to have this global agreement there. They maybe need to have some agreements at some point and and it's quite obvious also if you look at this uh who's who's supposed to agree on something, how much security is needed, you know, does it need a regulator or is it just between the two parties? Is is there a need for third parties to be able to verify that? Like all of those things will depend a lot on the circumstances.

So, it's almost like that's it's not part of the fundamental thing. It's the something you layer on top through the notary stand and you have enormous flexibility there in saying, "Well, it it's just going to be however the business requirements want it to be." Yeah. Yeah, the the key thing to realize is if you don't have a blockchain, um you don't have a total ordering of all transactions relative to each other, but you don't actually need that. Right? You only need um an ordering um when there is a double spend to resolve. And uh Corda transactions don't define a precise time at which they occur. They define um time windows, which may be open-ended. Right? So, you can express things like Bitcoins and lock time um with a Corda transaction, but you can

also say, "This transaction must occur within this window of time." It can't be a specific time because, you know, there's no global clock, right? You can define a sort of a time window and then, you know, taking you make it wide enough to take into account the speed of light and so on, but you there's never any point in which you can say precisely which transaction came first unless there's a double spend, which you don't need to. So, why bother? Why bother providing that expensive guarantee? And uh and in this example of the time window, so is that where Richard point comes in?

That because I can, of course, make up whatever time locally and if it's not put in a blockchain, uh nobody can verify it. So, that's where you need kind of a notary or third party to to provide the time. Is that correct? Yeah, so you you often you need you need some notion of a time for reporting reasons and and to, you know, interact with a logic like need to put option example. You know, we specify that notary the machines in a notary cluster are supposed to be synchronized to US Naval Observatory time, where which you can get from a GPS feed.

Um there's a mapping of that that time scale doesn't always that doesn't like the raw time scale doesn't include leap seconds and there's the you know there's some stuff in the specification and in the design documents about handling that and so on, but ultimately, you know, you don't know what the exact time the notaries will observe is. So, you can only ever specify it at a fuzzy timestamp in a way, yeah. It's maybe worth just saying some just one other thing on the notaries because I know when we sometimes when I when I explain this to people in other contexts um there there are often a lot of questions and I imagine your your your your viewers and listeners may have a few as well. So, so anticipating some of them, I'll just give a little bit more color on that.

So, so we use the word we use the word notary albeit we may have to we may have to be we may we may have to change that if it turns out it's incompatible with with some European um European regions, but we use it because we want to revoke the idea of it's the thing in the architecture that that's providing that stamp. For safety's sake, we think the notary should validate transactions, but but they don't strictly need to. The function they're performing is to say yes, I saw this transaction and it doesn't conflict with I it does not spend any of the same inputs as something I previously signed. So, it's providing like the same guarantee you get from a blockchain that says, you know, if a transaction makes it

successfully into the blockchain, it has it has out-competed any others that tried to spend the same inputs and you know which one got confirmed. Um, but that's a that's a that's a that's a that's a logical concept when as described. Concretely, there are many different ways of implementing a notary. You could imagine a centralized service that that that may work in some situations is sub-optimal in others. You can imagine a high-performance cluster that isn't Byzantine fault tolerant and you can imagine a Byzantine fault tolerant cluster that implements a notary. But then as Mike says, we can have many notaries many notary clusters implementing different algorithms with different qualities of service in different geographies with with

different characteristics all on the same network. And the thing that ties it all together is when a transaction is created and signed, the outputs each commit to the notary that is authoritative and whether that output has been spent. So when you look at any given transaction, you know whether the output of that transaction has been spent because it commits to the notary at the time it's created. And we can have many different notaries. Why might we want this? There could be geo geographic performance reasons. If all your trading for a particular particular set of set of trades is all with people in the same region, then having a geographically close notary for performance might be something you need.

There may be regulatory reasons where a regulator insists that any any transactions involving money issued by their banks is notarized on their shores. And there are also arguments for how this kind of technology gets adopted incrementally where before we get to a fully decentralized model, there are steps along the way that are part of the way there and get us there incrementally. So so so this idea of the multiple multiple notaries, multiple consensus services on one network is surprisingly powerful and and useful in multiple domains.

Yeah. To make that concrete, we have a prototype of a raft based notary cluster at the moment. Um that might be appropriate, you know, for City of London, you know, interbank trading where they they're not going to maliciously double spend each other, right? They just need a just need a mechanism to make sure there are no accidents. And then we'll probably we're looking at using the PBFT smart algorithm and implementation for a like a global a global notary that may include, you know, parties that sort of don't don't trust each other so much. So one question I had is one of the hard parts about um putting blockchain like systems or shared ledger systems inside uh inside a financial institution context

is uh they almost always have to interact with some other legacy system, right? So, I might be a financial institution, Brian might be a financial institution, and we might have an interest rate swap, but now the payment actually needs to go through, let's say, the real-time gross settlement system of, say, the United States right? And now, the issue here is that the money flows on that other system, but that other system is not cryptographic. It doesn't have a cryptographic proof that some event happened in that other system. So, we might have uh this contract object, and our contract objects, the state must need to be updated to reflect the fact that I have made a payment to Brian, but I don't have I may not necessarily have a

cryptographic proof that that payment was made. So, how does Corda handle something like that? Yeah, I'm actually kind of glad you asked about this cuz this is uh one of those really boring topics that no one ever thinks about when designing the systems, but you can't deploy um if you don't think about it. It's Right, so obviously the ideal situation uh the ideal scenario is everything is on the ledger, including cash, and then, you know, for an interest rate swap transaction, you can actually update the deal and move the cash atomically in the same transaction. Everything is nice, and it's all on one system, and so on. If it isn't, um then you need to uh basically, you know, both sides and it's not just like um interacting with real-time gross settlement systems, right? Banks Well, or any institution have all kinds of internal reporting systems, and you

know, they they want to print out reports at the end of the day, maybe, all kinds of stuff that's specific to that organization that needs to interact with the global ledger. So, this flow framework I mentioned earlier, this thing that gives you these kind of uber threads, the Corda platform, so a Corda app is a thing shared between um institutions. It defines the smart contracts where this determinism is very, very important, and that code is precisely shared. It also defines these flows, but the because these flows are just protocols um that are implemented by both sides, they don't have to be exactly the same on either side, right? They're not a part of the consensus mechanism. And so, the idea is that these these flows can be sub-classed, right? they're just ordinary so Java classes. You can customize them in various ways. You can

say, "Okay, at this point in the process of updating an interest rate swap or doing whatever it is you're doing, um I'm going to run some custom code and I'm going to call out to some internal system, right? Corda nodes are um at heart they're they're they're built on um a sort of industrial-strength message queuing system. We're using something called Artemis, but we'll probably make it pluggable later. Um message queues are very common inside banks, you know, you have messages going here and there and they can be saved to disk and written to databases and they can time out and they can be monitored and all these kind of things. So, what you would do is, you know, you would customize your flow and say, "Okay, well, at this point I want to make a payment. I'm going to override that method. Instead of trying to find cash in my vault,

right, in my wallet to make this payment, I can pass this to the message queue to some other system that will then go off and talk via Swift to uh you know, the RTGS or do whatever it needs to do." On the other side, you know, the other side is also sub-classed at the point in the flow where it's waiting for payment, then again it's interacting through these sort of message queues or by making HTTP requests to um their internal systems. So, the the nodes know how to interact with existing legacy systems. They don't need cryptographic proof. They just wait at that point in the protocol before they sign the next transaction on the global ledger. They just wait until the internal system flags it up and says, "Oh hey, you know, it's it's good.

We're good to proceed." Um flows um the current code doesn't support this, but it's a part of the design we're heading towards implementing. The idea is a flow can also interact with a human being this way. So, you don't only interact with nodes on the peer-to-peer network and, you know, internal systems. You can also send messages to people, and that's useful for saying things like, "This looks weird. Should I sign it?" Or even, "You need to sign this transaction with keys you have in a little treasure type device." Um, you know, the the node itself doesn't have the keys in it needed to do that. So, this is why we have these sort of long-lived threads, right? You can survive for days or weeks because maybe the person's on vacation or sick that day.

So, you need the ability to like pause the execution at that point until they come back, do their thing, and then resume with that signature you've obtained from the person. Cool. Yeah, I think that integration's going to be very important. Now, one of the things that's important to cover on the technical side that we haven't yet talked about. So, you mentioned that Corda uses the the Java Virtual Machine. Now, the the most well-known Virtual Machine, of course, in the blockchain space is the Ethereum Virtual Machine, and a big reason of thinking behind it is that "Okay, it needs to be deterministic." So, on every node, it needs you know, same input, it needs to be exactly the same output. Uh, and that's why, you know, they developed a

new programming language, and and did everything sort of from scratch and differently. Now, the Java Java isn't uh deterministic, right? And the Java Virtual Machine isn't deterministic. So, how how do you handle that? How is that uh does that mean only a subset of Java can be used? Or how do you address this problem? Yeah, so only a subset of Java can be used. There's a There's a whole list of things that you need to do to convert a JVM to being this completely deterministic thing, but if you just compare, you know, the EVM and JVM or Solidity and and Java, they are very, very similar, right? They have a lot more in common than they don't have.

Um, and so, yeah, requiring people to learn these new languages, which often um the EVM is is I would say kind of quirky in many ways. Uh The basic data width um in the EVM is 256 bits, which leads to some very puzzling and and strange sort of data usage scenarios and things like that. Like a you can define a byte array in two ways and one way is a is an actual byte array and another one isn't. You know, going with something like the JVM avoids a lot of those issues. As some examples of things you have to fix um so you obviously have to restrict access to things like file IO, network IO, random number generators. Random number generators are lurking in a few places

you have to be careful of like every Java object has a thing called a hash code, which is very useful because it means you can put any object into a hash map, hash set. This is functionality that programmers just love and use all the time. Hash codes are if you don't specify how one is calculated for a class, then it defaults to being a random number generator. So that has to be patched. Um you need the ability to terminate execution, right? So you need a kind of similar concept of gas. That can be done with um we're we're doing this with a byte code rewriting phase. Um and there's a a bunch of other things, but yeah, the the basic strategy is you define a subset of the the platform. You forbid features, right?

You you take away features that are incompatible with determinism. And what you've got left is something that's still pretty complete and still pretty useful and has a lot of functionality that Ethereum developers want but don't have. But you've done it for a fraction of the work, right? It's much easier to carefully review what's there and then adapt it than to build it everything from scratch. And it's it's worth adding one other thing to that as well, which is intersects quite nicely with the decision to with the decision to use the UTXO model rather than the virtual machine model because that restricted subset of Java that or of the the JVM bytecode said that

that Mike Mike describes. That is That is that is that is what we need for the the consensus layer. So, the bit that has to run the same on every node. But, that's pretty much only transaction verification. So, if I send you a transaction that purports to do something, we need to know that when I verify it and when you verify it and then anybody else who needs to verify it verifies it, we all agree it was valid or we all agree it was invalid. All the extra work that you have to write when thinking about smart contracts, how you generate transactions, how you chose what the transaction would do, how you figured out in which order to include things in it, that's something that's just run once in Corda and it's run by the generating node. So, um and that you can

do however you like. You're not subject to those restrictions. Um whereas in the uh the full virtual machine model types, um typically you write a lot more code in your smart contract and that's all stuff that has to be running all stuff that runs in the consensus layer and everyone has to agree on. So, that that the separation means even that quite quite rich subset we allow, that restriction is only there for the code use for the for the for the specific cases where you need to verify a transaction, not where you're creating. There's a whole bunch of advantages to doing it this way. You know, one one obvious one is that um you don't not every case where you're working with transactions has to be sandboxed and deterministic. If you want to make a a nice GUI that draws transactions on the screen, for example,

doesn't you know, if you if you whitelisted the transaction types that you're using, you don't have to worry about uh determinism or security, right? You just want to access the data that's inside and run them and see if they're valid. And um you know, maybe if it's not completely deterministic, it doesn't matter. So, it's it it's super convenient to just be able to drop this code in as if it was a regular library and start working with it. Yeah, for generating transactions as well, you you know that they're valid because you're constructing them, so you don't really want any pain from crossing language barriers and things. You just want to just want to start instantiating objects and working with it.

Okay the design of Corda's looks looks really interesting. It's probably the most fascinating like technical design that I've I've seen in around this space. But for the final section, let's kind of jump into sort of the the business proposition with a platform like Corda. So, the way I see it is like what Corda could enable in the future once it's running at a large scale is for a large financial institution, an investment bank, it can allow them to have one unified view of all of the contracts that they are participating in.

And um have it like have it like in in in one system, right? And when a lot of these institutions have these shared shared global views of all the contracts that they are participating in, it solves the problem of them need to spend time on reconciliation or making sure there are no errors, etc. So, how how does a system like this impact the economics of financial services firms? And does it does it benefit small firms? Does it benefit large firms? What is the economic impact of removing the reconciliation process?

Okay, so I'll I'll give maybe maybe answer that through through through a few examples, but start with just re- I guess restating the the the the essence of the problem space. So, you used the word reconciliation and let's just be clear about what we mean by that. So the you gave an interest rate swap example earlier. So, it is not a typical. It is It is common in the case where we've negotiated a deal like that between ourselves bilaterally. We've and we've and we're we're managing it through its life cycle bilaterally. We're not using a central counterparty or clearing house.

Then each of us will have built at least one system each, often many, where that deal is recorded and where aspects of its life cycle are managed. So, so the to to say we each have two would be would be be an understatement. So, that's four systems between us, all of which are recording the same data, all of which have to agree on a large subset of their functionality. Um, but they're written by different people with slightly different functional requirement sets, slightly different assumptions, slightly different reference data, slightly different bugs. Um, and so they mostly agree, but but sometimes they don't. So, we have to we have to put both in a, um, a prevent and a and a response strategy. So, there are lots of reconciliation processes that go on that affirmatively check throughout the life cycle of that of that trade

that both sides have indeed reached the same conclusions as to, you know, what the current status of the deal is, who owes what to whom, um, what needs to happen next. So, that's expensive. Um, it poses it imposes what amounts to a, you know, almost an IT tax on organizations. They they have to spend this money in order to be able to participate in that market. Um, and it's, um, and and that cost is obviously, um, it reduces the number of firms who can participate. But it also is it is it is experienced as as higher costs by customers. If we can move to a model where that deal is is recorded, um, recorded accurately once and each of our systems is participating in this network, so that when I look at my copy of the deal, I know that what I see is what you see. We both know that we see

the same thing because we're running on this consensus layer, then we get massive benefits from sharing the the the consensus code only needs to be written once. We probably will still need to run some reconciliations until we get confident, but we won't need to run as many and they'll identify fewer breaks as we go. So, the both the the the day-to-day costs go down, but also the, the fixed ongoing costs of running this infrastructure should go down as well, which I would I would argue, although I've not done the analysis on this, would, um, would allow for for more players and hence more more more more competition and, um, and more creativity and innovation. So, so that's just, um, that's just, um, one example. The other example, and this is a project we did with some members

late in the summer and early in early in the fall, was to look at a very a very specific specific specific regulation. This project is now public, so I'll just talk about this one in in generalities. But specific regulation that says in effect that if two banks or two institutions cannot come to agreement on who owes what to whom across a portfolio of trades accurately and within a certain time period, if they cannot do that, then they they they have to hold more more capital. Which therefore means it's more expensive for them to be in business. Their their profitability will be will be suppressed. So so quite apart from the IT cost of running this infrastructure, there are there are regulatory reasons that directly affect the balance sheet. If banks can't show

that they are indeed in consensus and running similar or identical business logic with their peers. So I think I don't want to to overstate or oversell this because change takes time. Implementing change and implementing, you know, new and better systems in one organization is difficult. Doing it across multiple institutions at the same time is of course harder still. So so we should expect this to be an incremental journey that we're on. But the but the prize is big and real. So Richard, if if you can for a moment put on your your speculative hat and be completely irresponsible and think about what what will that mean for the financial system? Like what what's it going to look like 10 years or 15 years from now once a lot

of this change is percolated through the organizations and and change sort of the structure of banks and other financial institutions. I'm not going to rise to the debate. I I I don't know the answer to that, but I but I do think I know one thing, which is um a lot not not all and I'm not here as a an apologist but for some of the excesses. But a lot of the a lot of the complex instruments that exist exist to solve a real client need. You know, we talked about those interest rate swaps.

You know, at the end of that chain of transactions, there's almost always company trying to to hedge its interest rate risk or trying to ensure that it's protected against against exchange rate fluctuations or for some goods it's buying or for some for some goods it's selling. There are people in the real economy at the end of this chain. And the because of the the problems we've had in the past, there is a strong regulatory move towards ever more standardization of these instruments, the moving of them towards central clearing houses, so that so that the regulators get far more confidence that there won't be any any blow-ups. Um to the extent that this technology, and I think it will, to the extent that this technology allows that that regulatory direction of travel to continue, but we still get the customization and the the

specialization we need to actually solve the problems of the people who are buying these products. It's to the extent we can do that, um it will be a be a benefit to all. Um so I I can't predict what the financial system will look like in in two years, let alone 10 years. Um but any technology that that drives sort of safety and consistency through knowing that there are there are no mismatched trades, no no incorrect views of the world, while still while still allowing the banks to serve what is ultimately their customers, um is is um is is what I'm focused on. I'll rise to the bait. It'll be easier to be your own bank.

Yeah no I think that's a great point, right? Cuz in the end, you you would imagine that first of all, the the cost of of running all these systems are going to be dramatically lower, and then there's probably going to be much more standardization across the systems. Uh so yeah, you know, maybe you won't you can finally be your own bank, you know? Yeah, I I don't know if it'll ever happen because there's lots and lots of people in these institutions who can say no, but it would be I think it'd be fun to get to a point where, you know, your online bank has like a internet ATM, and you can withdraw like digital pounds, and you know, use them as if they were like you would have used Bitcoins.

And there would be withdrawal limits and so on, just like with a real ATM, because of security and other reasons, but um it would be a nice thing to be able to get to the point where you can send money around just like you could with Bitcoin, but you're using, you know, more useful currencies. We've talked a lot about, you know, making the existing financial system more efficient, you know, replicating an interest rate swap. Are there entirely new products and, you know, use cases that today don't exist that will become possible once this technology, or technologies like this, have become widely adopted?

Well, there's there's a lot of discussion on using this sort of thing for supply chain management and things like that. Currently, and and especially around management of trade, like international shipping and things like this, which is currently an incredibly paper-based process. I don't know if you would call them like new products, but uh the the act of selling things around the world is is remarkably bureaucratic outside of, you know, internet services and so on. Um making it easier to sell things, making it easier to figure out where things have come from. If you look at some of the things going on in the world around trade deals and so on, right? The traditional approach to tackling all this bureaucracy and paperwork has been building political unions and political blocks, and that's starting to run out

of steam. So, maybe if instead of tackling the the the bureaucracy and and problems of of these things with uh political unions, you just have really really really efficient software, and really efficient tracking and things like that, then that's another way of you know, making trade easier and tackling these problems. Well, I don't know maybe. And maybe I'd add to that, I guess Mike gave a really exciting example in a be your own ATM. That sounds like a new product to me. It's not something that we are we're in the process of building, but it you can see how this technology could could get you there if if if if someone if someone followed that train of thought. The other thing, and maybe this maybe this is going a step further, is

to think about what happens when you have a network of Corda nodes upon which multiple applications, multiple cordapps as we call them, are deployed. The interaction and interoperability of those applications I think is also a a source of potential future innovation. I don't pretend to have the imagination to say how that would be used, but having having applications that can within the bounds of the consensus layer and the verification logic manipulate the the state objects of of other applications, build upon them, and reuse their functionality. I don't think we've even begun as an industry to think about where that might take us.

Okay, so we're almost at the end, but there's one thing we want to address very briefly. So, Corda of course is open source, available for anybody, anybody can do anything with it. It also doesn't have you know, a built-in token or something like that to monetize it. So, there's a different project that you guys are working on called Concord. Can you share anything about what Concord is, how it's different from Corda, and and maybe how that relates to the R3 business model? Yeah, sure. So, so exactly as you said, Corda is the software is is is the software that that our team has been building. It will be open sourced under the Apache 2 license on November 30th.

It's our it's our it's our hope to contribute that to the to the Hyperledger project. But as you say, that that software, you know, software unless it's deployed and and solving real business problems is an interesting curiosity, but it's it's not particularly useful. It's just interesting. So, the so the the other piece of work and we and we spoken little about this in in in public, is is is is is essentially driven by the thought experiment that says, "Right, okay, that's great. We've identified these problems that need to be solved and which Corda is is is is a foundation of the solution."

But this almost back to the founding principles of R3, this is useful when it's solving real problems for in our case our our case banks and then financial institutions. This software needs to be deployed across them. They need to have They have nodes, they need to be secured, they need to be connected to each other, the messages need to be routed. And just as I hinted earlier, this becomes more valuable to to to to to institutions and their clients and then to everybody when when you don't have to deploy a different network for every application. You want a common shared inclusive network that that people, not just us, other people can come along and and deploy applications on on top of.

And that that in a nutshell is is project Concord. It's the the vision for how we take Corda open source software and deploy it as a network upon which other people can then build applications. So we get the benefits from from sharing that infrastructure. Yeah, that's that's that's the idea. Okay, well I I think we're at the end. We've been running quite a long time, but this is a very exciting project and it will be very exciting to see what happens when it comes out just just a few weeks from now. Depending when we'll release this. And I'm sure it's also something we'll we'll come back to, right? So I think it's our expectation and probably certainly your expectation that this will become widely used. Probably lots of people will build applications

on top of it, will build technology around it, and it will be exciting to see what impact this is going to have on on the financial system. Yeah, let's hope so. Yeah, so thanks so much for joining. Indeed. Thank you for having us. And of course we're going to have links to to the white paper, to to to some of the other resources that are out there and and the Mike's technical white paper is also going to come out in a few weeks. So, probably not at the time this comes out, but we will certainly also tweet tweet it out and and share that. So, Yeah, thanks so much for listeners as well for joining us once again. So, Epicenter is part of the Let's Talk

Bitcoin Network. You can find this show and many others on letstalkbitcoin.com. And of course, you can subscribe to this podcast in any podcast application or watch the videos on youtube.com/epicenterbitcoin. So, thanks so much and we look forward to being back next week.