Transcript
I have my own slides that I did. It was about a week preparation. And as usual, I left it to the last minute. I sent Greg my slides last night, and he said, "You have way too many slides and way too much text on them." So I'm going to have to move fast. But I wanted to see if you guys could help me figure out which content to do. So we're going to go with something a bit more corporate feeling, I think. Before I get started, who here by show of hands has worked with blockchain?
A few of you, not many, actually. I think I'm used to audiences that are all blockchain and of those few, have any of you worked with Corda? A couple. One out of three employees has. That's good. I've got a fairly fresh audience, which is great. I would adjust a little bit what Greg was saying in the sense that, if you know us at all, which I wouldn't expect you would, our origins are somewhat finance but we're finding ourselves moving kind of quickly outside of finance into other use cases. And that's what I was actually going to start with because I think in the industry, we've come of age in kind of a very strange time where it's very press-driven, social media-driven things. And the perception is actually somewhat ahead of the reality, which I would openly acknowledge.
The first question most people tend to have is why even use a blockchain? I wanted to jump in a couple minutes on that, give you an idea of some of the use cases we're doing today. So it's a little out of order, in a sense, but it's probably more in the order of the questions you might have. Second would be why would you build a new blockchain? There's already platforms out there. So I'll try and answer why R3 members set out to build our own platform. And then the next is trying to get a bit more technical for you guys. This is actually an overview of the platform. How is it different than other blockchain platforms that are out there? How does it differ in just the basics of how it works? And then last is in promise of cases description, what's the future for Corda, or blockchains in general as we see it.
Why use a blockchain?
I'm going to jump in quickly. As promised, I'll move fast. Why use a blockchain? I'm using our corporate slides to tee this up. I've got three use cases that we're looking at today. Of those, two are ISVs, and each have different drivers run around why they're using it. Frankly, some of this just isn't driven just by the technology for technology's sake. I think we've seen a lot of that. There's a lot of use cases out there that I would, when I see, I think, "Gee, wouldn't you be better off of the database for that?" And it is kind of true. But a lot of cases, there are places where a blockchain absolutely does something that no other technology can do.
Finastra is an ISV, if you're not familiar with them. I think they're the third largest in the finance space. Finastra is using Corda for a couple of different use cases. The primary one of which is taking what they call LenderComm. It's a lending platform, obviously. It's when large corporates go to seek funding, and they go to agent banks, and they spread out the risk and they gather up loans. Now, this is a great basic example of where blockchain is good, because you have a set of entities who compete with each other, but they need to cooperate around something. Finastra already has their technology in these companies.
They have a version of this. But it doesn't allow those participants to work together. They effectively have to come back to Finastra, or come back to the existing technologies to do that. What Finastra is doing is what we see with a lot of ISVs - they've understood. They have a large customer base who all acts on a particular solution for a business problem. Then they are discovering that they can actually start connecting them and doing that new thing. That's exactly what Finastra started with LenderComm and a couple of other use cases we're looking at.
The next is B3i. Finastra, obviously, works a lot by the way, with financial institutions, a lot of banks, fairly large networks. We'll talk a bit about the size of the networks towards the end. B3i is a consortium. It was started by a group of reinsurance companies. B3i is interesting for us because when you see a little bit about our history, their name's quite similar. But initially, we were thought to be competitors. We're actually very close collaborators today and largely because B3i is trying to solve a very specific problem and we're trying to get a very abstract platform technology that can solve many problems. B3i's problem was reinsurers. Again, this is an industry where these very large organizations have to collaborate.
If you think of reinsurance is all about taking insurance and spreading out the risk. They have to do a lot of things to coordinate with each other. One is they have to balance portfolios so that they don't double insure something. They kind of increase their risk in particular. They always have to have an overview of what's occurring in their portfolio. But they need to work with insurers and other reinsurers in cooperating. Very basic thing when somebody makes a claim, they have to go figure out who's going to actually pay for this claim. They have to start collaborating or coordinating with each other. The insurance industry for R3 in particular we're seeing is probably the area that's going fastest actually.
Banking is an area that had early traction. The use cases are fantastic for banking, finance in general. But insurance has missed out on the last technology wave. Like I've discovered, most industries in the world tend to run on email and spreadsheets. They have the advantage now being able to kind of leapfrog into this. B3i is one of the industries that's taken this technology. They have a large set of participants, very large organizations implementing it today.
The last is TradeIX. TradeIX is somebody we work with closely. They're a startup, so a different breed than the other two. What TradeIX is doing is working in trade finance. If you think of supply chains, these are these long, fragmented supply chain of companies that have to coordinate with each other. But it's almost like a baton race. They pass documents, they pass goods. They don't have anything other than the fact that they get proof that they have passed it and that they should trust who they're passing it to. So there is a lot of trust in these supply chains. Supply chain, in general, is a fantastic use case for blockchain because a lot of what blockchain does is give you the ability to trust the information because you can see the provenance of it. Somewhat cliché, but when you get into something like trade finance, you're looking at an area that is very inefficient today. It's very paper-based. One of their big challenges is double financing, as an example. It's fraudulent, but people go out and they get financing from one bank, and they go to another bank and finance it again. That right there is an ROI for the banks that are working with TradeIX.
Now beyond that, it's actually changed the economics of what they can do in trade finance because it's made it cheaper, dramatically cheaper, for them to get access to small, medium-sized organizations for seeking financing. Those are just three examples. I wanted to stay as much in the technology as possible today, considering the audience, but of how the technology is being used today. These make sense primarily from a business perspective. There's an ROI that is very apparent for them. I'm going to do my best to keep track of time.
Why build a new blockchain
Why build a new blockchain then? If you believe that you need blockchain when R3 set off on this, we were actually not a technology company.
We are more of a services company. We had a group of member banks. Those member banks were brought together in what was externally thought of as a consortium to evaluate blockchain against finance and to determine is this a threat or an opportunity. If it's an opportunity, what is it good for? We spent a long time running projects, taking use cases in the banking industry, and applying the technology to see how well it would work or not. The outcome of this was we're fundamentally missing two key characteristics. I'll run through those. One was, if you think of any distributed ledger, and I use blockchain and distributed ledgers interchangeably, mostly in a marketing sense, not technical, the idea is that we have a shared ledger - that's the basic premise. So that when I get something from you, I can look at the global ledger and understand if it's valid and unique. Those are the two questions you always have to answer for yourself.
There are some obvious problems in this, the first of which is privacy. If I have a copy of all the transactions, which are needed to assure myself that the ledger has integrity and what you've handed me actually matches something on that ledger, then I can see everything that's happened with my competitors. This is a very big problem, obviously. It's not just a practical problem. If a group of banks got together and they said, "Hey, we'll just accept the fact that we can see some of each other’s transactions," it's actually a regulatory problem. A lot of our use cases could not use a ledger where other transactions were visible. That's the first problem.
The second problem is finality. If you're familiar with Bitcoin - is everybody here familiar with Bitcoin? Show of hands? How many of you still have Bitcoin? A few of you. How many of those wish they would have sold last year? So the problem with Bitcoin is finality. As you get a group of transactions, batch mode processed effectively, and put into a block and that block propagates around the network, there's a likelihood that that block will conflict with another block that's been mined. The network has a protocol to determine which of the blocks to drop. But the reality is one of those blocks could drop.
You don't have certainty that your transaction is final. That's a very big problem with finance, obviously, because without finality, you can't move on to the next transaction. Which is something that's obviously a very basic requirement in financial scenarios, if not other industries. Our members or group of about, I think it was about 42 banks, initially, that kicked this work off, started a technical Working Group. Each contributed technical members of the organizations, and we kicked off the design of a ledger that would try and meet these criteria. That's what Corda is. That's fundamentally the two things Corda did.
One of the other things we attempted to do from the beginning was to aim for productivity effectively, and this is really looking at it from a TCO perspective. We've made some very basic decisions, which I'll cover, which if the problem is already been solved in the industry, don't resolve the problem. Don't try and reinvent everything.
Corda Overview
I'm only 10 minutes in, I'm doing quite well, maybe too quick. Let's jump into Corda itself. If you look at a blockchain network, really any of the blockchain networks, there are a couple things. One is I love what the diagrams we always see. They look like they're kind of these neat networks, I love the hairball one is my perspective of it. They're peer-to-peer systems - anybody can connect to anybody.
And so with Corda by the way, Corda is similar to Fabric in the sense that the boundary of that network is effectively the Root Certificate Authority. These all most likely run on the open internet or leased lines, but that's effectively the logical boundary of it. There's three areas that I tend to group this collection of technologies together into. One is the ledger, the second is the transaction itself, and then third is the network at large. I'll cover those off quickly in that order. When you look at the ledger, there's a couple characteristics around ledger that are important. Immutability we hear a lot about. Immutability is an interesting one because that is something you can just get from a database. You would have seen with Amazon with QLDB, I think it is, announced immutability in the database.
Being somebody who came from the database industry that always struck me as one that's a fairly simplistic thing to do. I think a lot of people in the audience could go build an immutable database system. However, it is an underpinning requirement of the platform in a way. Shared facts are quite important. This is effectively what the ledger brings you - I have a copy of information and you have a copy of information, and we can assure ourselves that it's identical. It's not only identical, but it's legally binding. That information has been signed by you. So I can go verify and prove that you had accepted a particular transaction, as well as the information in that transaction.
The next one is the transaction itself. If things are stored on a ledger somewhat static, how do entities transact with each other? The transaction has a couple things. One is just a shared logic. In a way, it's the business logic. We actually split that into two components I'll show you in a minute. But you can think of one, you have to have the contract, which tells you as the person operating this node how something will transform on the ledger. How does the state change from one state to another? What are the rules behind that? That's quite important. Because you're running that, you're going to trust the code that executes that. So that's where you bring their trust back to.
The second is universality. I won't talk too much about that. If you go back to those early examples and you think of like insurance, and all these big networks working together is you don't just need shared logic around that transformation, you need everybody to use that same logic. If I represent cash in a particular way and my counter-party has a different contract for cash, well, they're not fungible. They're not interchangeable with each other. This is, again, less of a technical challenge and more coming back to standards and other things that exist in a lot areas today that we can just adopt. Finality we talked about.
The last area is the networks. Carolyne [Quinn] is going to talk about the network. There are a lot of characteristics. A really important one is opening as big as possible, right, because otherwise, your boundary of what you can transact on is limited to the number of participants in that network. Identity. PKI has always suffered from this. I need to be able to discover a peer on the network and assure myself that that peer is who I believe it to be.
Scalability is a very big challenge for the blockchains. I won't talk too much about that today. You'll see in a second what Corda's architecture and how we approach that. Scalability is a challenge because everybody has a large copy of the data set. Then if you have a consensus algorithm, a number of nodes have to re-execute the contracts simultaneously and reach agreement on that. So performance is always going to be a challenge with blockchains.
The last is uniqueness. This is the double spin problem. I break this into valid and unique, and I'll show you why in a minute.
Ledger – Critical Insight for Corda
How does Corda differentiate in this? The first is probably the critical insight why I think for Corda is at the ledger level. If you think of a Bitcoin ledger, it's effectively a tree of transactions. Are you guys familiar with UTXO? UTXO, unspent transaction output, is pretty simple as you have an issuance of something on a ledger. As it gets into a transaction, it gets spent. What you're really spending are these endpoints.
This is all spent information but you need this history and you need the full ledger to know that it has integrity. You need this history of transactions in order to assure yourself that not only is that leaf unique, somebody hasn't spent it simultaneously while trying to give it to you, but all the contracts that executed previously had the right inputs and outputs because otherwise, somebody could have minted money or done something malicious along the way. You effectively want the full ledger, the leaf, and the contracts to go back and execute.
Corda's key differentiation is we realize that you don't need the full ledger. You actually only need the portion of the history that's related to the transaction that you are entering into. If that's the UTXO that you're presenting me, if you just want to make payment to me, I will take that UTXO, but also take the history behind it and the contracts that go with it. I'll re-execute those to determine they're valid. So I can assure myself that what you're trying to give me is valid. I can't yet assure myself it's unique. You cannot assure yourself of that, the network has to give you assurance on that. I'll talk about how we split that out in a minute. You don't have a copy of the ledger, but you can assure yourself that this is valid. That's fundamentally how Corda differs. Nobody has a full copy of the ledger. It exists in a logical sense on the network. It would effectively come back to a set of trees in intermesh with each other because you have different asset types. But fundamentally, Corda is passing branches around, not the entire tree.
Ledger – Privacy by Design
This differs from other platforms. I probably should have put Fabric up here, but primarily, Corda is bilateral, so only parties of the transaction have copy of it. You can see the transaction history for that one branch behind you. I'll talk about how we're solving for that. But you can't see ahead of you, obviously. You don't get copies of transactions later.
It's UTXO style. All records are related to each other. We really only hold a smart contract with that information. The shared unit for Corda is the transaction itself. That's what you share with your counterparties. Now, the theory and by contrast is account-based, not UTXO. If you have a contract, you have to name the parties in the contract. If you want somebody else new to transact on that, they had to be added to that contract, which means they get visibility in contract's history. Bitcoin, we take some similarities from the sense that they're a UTXO style ledger. However, we don't share the entire ledger like Bitcoin would. We also have smart contracts that are much more sophisticated and arbitrary assets, whereas Bitcoin effectively represents one asset type. We talked a bit about that.
Transaction – Smart Contracts
The smart contract is the second area. The key components of the contract and how Corda differs here, one is they're written in Java or JVM language, any of the JVM languages. We actually chose Kotlin. It was a bit of a risky choice at the beginning because it was a new language, but it was very efficient, it was one of the reasons we chose it. You could create domain-specific languages. We could start to ease the developer experience by creating DSLs that they could leverage, making it syntactically much simpler.
What Corda adds then is you still have common contracts. Most platforms have that. We separated out something with the workflow, though. If multiple parties are coordinating to build a transaction, we give you the tooling to create that coordination between parties. In a JVM language, in Java you could write the logic of how you would go about getting signatures, proposing to counterparties, etc., assembling all that, and then submitting that to the ordering service, which brings me to the ordering service.
Network – Ordering Service
The ability to reassure yourself that something is unique, is it has to be done at the network level. The double spend problem still exists, all be it at a network level now. You can assure yourself something is valid but not unique.
The way Corda treats this is we had originally looked at the mining mechanism. That's where we have finality problems, but we didn't know which algorithm would be best. In this space, in particularly, BFT is very young and immature in reality. We wanted the ability to swap out algorithms. We also wanted the ability to create very large networks, which means multiple ordering services running. That's what we have. We call this the notary. It is effectively just an ordering service. Those ordering services can be run multiple. They can each run different algorithms.
Anytime two parties transact to move something between the ledger, they have to get a signature from the ordering service noting that those are spent transaction outputs. They only care about the spent. It's very simple. Now it may be running BFT, but each of those nodes in a BFT cluster would simply say, "You have a UTXO in an index. That's an output. Have I signed on that previously? No, I'll sign for it. Now I'm going to add that to my log and move on." That's how we do the ordering service. We've done a couple of implementations of algorithms and more to come actually. I can talk a bit about that and the future part real quickly. I'm going to leave that till the end, just for time.
Technology Platform
The technology platform itself, we did make some choices to try and make this two parts. One is simplicity from a developer experience, but also simplicity from an IT experience. Most of the representatives on our technical committee came out of large organizations. Integration into those organizations was something we were aware of from the very beginning of the design. It's still challenging, for the record. It's still very challenging to deploy a point-to-point system inside of a bank, as an example. So having a continuously-changing set of network participants behind a firewall is not very easy in a bank. We've made some changes to solve those types of things. The first choice we selected is the JVM. We thought that this has the largest developer community and would lead to a lot of productivity. I'll talk about some of the trade-offs in that momentarily.
We selected AMQP as our messaging protocol. We did not develop our own whisper protocol. It is not a whisper protocol-based system. It is point to point, so you choose who to message with. AMQP exists in a lot of organizations. It is robust and proven at this point. Last is we started our ledger in a relational database. There's a lot of byproducts of this. You get all the full querying capability you would get with your tooling today around BI and such when you use a relational database. Most of the existing solutions went with key value pair systems, which are oddly were invented well before databases. Databases were designed to solve the key value pair store problems. We also get to rely on some of the mission-critical capabilities of these databases.
Future: Expanding Architecture
Where do we go from here? Where would Corda go from here? At this point, I should explain where we are. Where we are today is we have live implementations running this solution with all the things you would have seen. But we're still left with a couple of problems. If you would have followed, I hand you a transaction branch. In order to satisfy yourself that what you're receiving is valid, you have to execute those contracts. And you need all the data that goes in and out of those contracts. What we've effectively done is dramatically reduced the surface area of a privacy problem, but we haven't eliminated it.
Ledger-Privacy via Encrypted Transaction History w/SGX
How we going about eliminating that? If you think of the transaction history is it starts with an issuance and it goes through various transactions. Now keep in mind, if this was cash as an example, it could be used in various types of transactions. It could be cash versus buying a car title, cash used to pay for a pack of cigarettes. Each of these needs a contract that goes with it. So you have a variety of contracts, potentially. Cash is the hardest one, by the way. What you're receiving in the end is the unspent transaction output, which is the unspent part of that. It should have a value, it should have a signature associated to it, they can unlock it, etc. But when you hand me this, I need to rerun these contracts to make sure that this thing is valid, it was issued by somebody I trust, etc.
Today, we do that on your node. Where we're going to next is we're encrypting this transaction history. So step one, the first milestone of which we've reached, and I think next week it will be public, is doing this in a trusted enclave. We're doing this in Intel's SGX technology. Are you guys familiar with trusted enclaves? These are the things I take for granted. It's present, primarily on phones today, actually.
Secure enclaves are a piece of hardware that's inside the chip and when it boots, it bootstraps itself with the belief that the entire system has been compromised. It all runs encrypted. It's signed with the chip producer's signature. Anything that runs inside there then, it runs with the belief that it can't see it as the local host because it doesn't trust the hosting environment. It only trusts the inside of this enclave. That means that you can take this transaction history encrypted with the enclaves key, pass it to somebody. They can't read it. But they can pass it into the secure enclave, execute the contracts. The enclave will provide them with assurance that it's valid. It's their enclave, so they know the parameters around the operation of that.
The first milestone we have reached is we have a Java virtual machine running inside the secure enclave. The next step is you can the execute contracts there. Developers won't have need to have any awareness of this. It should be a fairly simple developer experience. Now why did we choose this one? Why not go with zero-knowledge proofs? Because zero-knowledge proofs are quite fashionable and people love to talk about zero-knowledge proofs. But they have a few very big problems. One, they're not at all performant. So they're on the order of a minute or so for basic contract validation. Zero-knowledge proof doesn't require an enclave. It can execute just on the machine. It uses cryptographic procedures to run this same verification process.
Two, they had to be handcrafted today. That means that somebody, a developer, has to craft that zero knowledge proof, which is quite difficult. There's very few people in the world that can actually do this today. To expect that all the contracts in the world develop ZKPs would be somewhat unrealistic in the near term. Last is the trust problem with a lot of ZKP implementations. You had to actually trust that the initial keys generated with it were not compromised. However, Corda is somewhat agnostic on this. This transaction history, once the ZKPs are viable, could be encrypted with zero-knowledge proofs. We're not religious about this at all, we just took what was practical. You get a near-on chip performance with validation in an enclave, which is much more impressive than what you would have thought. That's the first thing.
Determinism via “Sandboxed JVM”
Another thing that's actually shipping with Corda 4 in its first preview is deterministic JVM. If you look at the Ethereum community, why would they create their own virtual machine, which seems a bit silly? But they actually had to do it out of necessity for two reasons. One is they needed to assure that the contracts run deterministically. Every time you execute a contract you get the same output, if you give the same inputs, which is difficult. In fact, there's a lot of non-deterministic APIs in most of the Java libraries.
The second reason for them, which is a differentiation on the public blockchains, they needed to charge for resources. They needed an intimate control over what happened on the machines, so they could charge you gas appropriately for usage of somebody else's machine. We don't have that need. What we didn't say is we took the Java Virtual Machine and sandboxed it. Now it's a bit of a marketing term in reality because it's a pre-processor that runs through the contracts and evaluates all the APIs called to see if they're deterministic. That actually was about a two-year effort of whitelisting deterministic APIs. You still get most of the Java library, but ones that are known to be not deterministic are eliminated at pre-processing time, when you load the contract. That way you have assurance that all the contracts that run are deterministic.
Transaction-Tokens
The next area we're looking at is tokens. Tokens are quite fashionable. A lot of had your hand up for Bitcoin but not much about the using the technology. Tokens have a lot of power and a lot of potential, but they're effectively just a contract. A lot of our work has been looking at how could you make uniform tokens that are fairly fungible so they're interchangeable? There's a lot of standards work on that. That's the boring part nobody really wants to do, but has to be done slowly one use case at a time.
The other part is how can you make that token more powerful? If you look at ERC-20 on the Ethereum platform it's really just about creating an interface that's standard so that, when you take a token, you give it to an exchange they can list it. They just call the same APIs on every token. You have to have a common, I think, it's like five APIs on your ERC-20. We're looking at that further how can you make the tokens more applicable to broader scenarios? If you think of one of the key scenarios for us lately has been looking at finance scenarios. How can you issue something on ledger? How can you then securitize that and somebody who receives the token can work their way back to the issued item and assure themselves that it's legitimate rather than having to just trust the token itself? That's where some of the work is happening today.
Network Operations
I'm going to leave this last part to tee up Carolyne is on the network. One of the big things that we talked about with the network, is that the boundary of a network is its Root Certificate Authority. That's the way Corda is designed today. It's also the way Fabric is designed today. Fabric is a bit different in the sense that because Corda is kind of naturally a sharded architecture, in other words, you only get branches thrown around, nobody has to have a full copy, Fabric solves that in a very different way. They create mini blockchains within groups. The problem with Fabric is then you have to be able to take something from one blockchain and move it to another blockchain. That's an interoperability problem and that's a much different problem.
For us there is still a problem, which is each one of our customers is going to go stand up these networks with their participants, hopefully with that many nodes. It would be fantastic. These cannot interoperate with each other. Fundamentally blockchains can't interoperate with each other because you don't have the trust. You'd have to participate in both networks to assure yourself that you're getting something that's valid and unique. What Carolyne is going to talk about is, because the bounding of the network is simply the Root Certificate Authority, if we all operated under the same root CA we could operate in effectively more the equivalent of a public network. Carolyne will talk about that momentarily.
So my call to action - sorry, I'm moving really quickly and I think I'm just on time - is corda.net. The next step, if you'd like to learn more, corda.net is the website dedicated to the open source version. I should have said this in the beginning. Corda is an Apache tool licensed open source project. We have contributors from all our member banks, etc. We're always seeking contributions, so it'd fantastic if you want to participate in that. The simpler way to get started if you go to corda.net is to go through the instructions for creating a contract. That will get you the most familiar with how the system works. That'll pull down the dependencies from Corda itself.
My last slide actually is I have a problem. I run the Developer Relations team also. I didn't bring the stickers because we're running out of stickers and I need to develop new ones. I was sick on the weekend, so I came up with some ideas on my own. We're going to come back to this after Carolyne presents. But I need you guys to clap and vote on which one you'd actually like, because I have to get them printed today because I'm flying next week and need them. So I'm going to take advantage of all the people being in the audience. I'm going to hand over to Carolyne and I'll be back up for Q&A also at the end.
What is Corda Network?
Quinn: I joined R3 about six months ago. I'm not a software developer so also be kind to the previous presentation. What I am working on is governance and working on the application of the Corda network and promoting us to many different customers. Going back to Mike's points like Corda network, so trying to break down what Corda network actually is. There are four or five main components that I think about when trying to get my head around Corda network. There's a network map, which is essentially a list or a phone book of all identities on the network. This is an IP address and also a name, which is a legal entity name and several like a country and a location. Anyone who is a member on Corda network will be part of this network map.
Secondly, there's an identity issuance service. Anyone who's a member of Corda network will have an identity on the network. This is not an identity that KYC has been done on but there is a legal entity name, there is a country, and there is the closest city. And before you join Corda network, there are a couple of very light identity checks that we do to ensure that you can join. The identities are verified to a certain extent but not that KYC hasn't done on them.
There is also at least one notary service. Corda network is providing a notary service. But anyone who wants to join can also run their own notary. We provide a notary service, which as Mike explained earlier, is basically proving that the transactions are unique. That's also an important thing to get your head around. The Trust Root, as Mike mentioned, is the root of all the transactions, which have happened on Corda network, and are validated through this trust root. It's offline. It's hidden in a secret room. We had a huge ceremony to put this trust root in place. If you're interested in finding out more, I know Mike outlined corda.net for our software, but corda.network is where you can find all the information about these things and also about the new foundation that we've set up to govern. I'll talk about that in a minute.
All the policies which regulate all of these different things are all outlined on that website and I encourage you to have a look at us, should you be interested. Obviously, nodes are up at the last part of the network. A node is an identity, is a participant, is a legal entity. These are the same things to a certain extent. If you're taking part in Corda network, you will be a legal entity. Individuals currently are not participating on it, it's just for legal entities.
Business Networks
The way many projects or consortiums are joining Corda network at the moment is through business networks. This is a terminology we use internally. You could call it consortium, you could call it a trading group. Typically, these are groups of 10 to 15 legal entities. There could be way more than that. We have a couple of groups joining who are in the hundreds, but these are groups who have decided before joining Corda network that they need to interact together. They need to transact together. They want to use Corda.
We're seeing reinsurance syndicated landing. Trade finance are the big joiners at the moment, but there is also customers and many other industries like healthcare, supply chain, and oil and gas even. Business networks is how people tend to join Corda network. All the rules about who can join a business network is up to that business network themselves. They create rules around pricing, around who is allowed on, what kind of legal contracts are there, how they transact together. We want a lot of the control to go to these business networks to determine their transactions. As Mike mentioned, one of the big advantages of Corda network is your nodes can be a member of 10 or more business networks. Any assets like cash or other assets that you have in your business network can also be used in other business networks. The term interoperability is a buzz word, we recognize that, but we do think that Corda network has this in comparison with other networks.
How is Corda Network Different?
I don't want to go into this in too much detail, but on the right-hand side is Corda. It's a global network, which is an interoperable network, but it also has privacy and high scalability like transaction throughput in comparison to other leading blockchain networks, such as ourselves. I wanted to quickly talk about our foundation. When people hear about Corda network, they're excited but until recently they have been a bit reluctant or a little bit suspicious because it was controlled by R3.
Why should I join something that is controlled by a for-profit corporate essentially? Why would I risk having vendor lock-in when there are other networks out there for which this may not apply? In reaction to that, I've spent the last six months helping set up a foundation. It's a completely separate legal entity to R3. It's called Stichting and it's a resident in the Netherlands but Ethereum also has a Stiftung, which is a Swiss version of this. It's a governance entity, so it has no shareholders and no owners, it's just there for governing. What's exciting about it is there's two R3 directors, but there's nine directors from other corporates. These are customers basically of ours or participants on the network and they're directing and governing how the network runs. This is anything from pricing to changing the rules about who is allowed on the network, potentially, the network operator. It can also govern who runs the network.
It has quite a lot of free scope for changing Corda network. The transition board was internally announced last week, and we'll be doing a press release in the coming weeks about who those members are. They'll be there for the next year and they'll be deciding how the network is run. So it's really taken away from R3. The businesses have taken a good bit of risk by leaving control go to a completely separate legal entity, but it's set up and it's all on corda.network, if you're interested in finding out some of the policies and anything more about it.
What Will The Network Be Governing?
R3 is the network operator. We set up the Corda network and we're running it for the first three years. After that, the foundation can change the network operator. So we really are letting go of control.
The foundation can decide on pricing for the networks. All the pricing is currently publicly available on corda.network. They're very low prices. It's a not-for-profit entity, so it's just there to cover its costs. It's all available, should you be interested in joining. Any stuff around technology upgrades for Corda network, the foundation will be heavily involved with that. Any changes to the bylaws, the articles of association, the governance guidelines, any of these legal documents that are set in place for the foundation to run, these can be changed by the board of the foundation as well.
Questions and Answers
Participant 1: You were talking about the double financing, solving the double financial problem. What I understood is that their financing have to be on Corda network. If it is outside of the Corda network, there's no way to actually detect whether there is a double financing or not. Is that correct?
Ward: In this case, it's the way they're attempting to solve it. I wouldn't think of the Corda network, specifically. No offense, Carolyne, but that makes for a bigger network. In this case, you could just run a financing network as an example. The double financing would only be aware to the participants of that network. When they issue the request for financing it can only be consumed one time. If they go to issue something again, well, they probably have received copies of that issuance. So there's some information that's actually shared broadly in these networks and some information that's kept private. But something akin to a request to finance something would be shared fairly broadly among the major banks. It's a very big problem, though. Actually, I didn't realize it cuts in quite substantially to the profits, trade finance in particular.
Participant 2: You were talking about the governance. If you look at the blockchain as a whole, the main thing is decentralization of everything. Having something governing bodies sounds like a centralized control. How will you solve this kind of dilemma? This will be obviously like when it comes to the expanding the network or trusting the network.
Quinn: I think there are two points. Firstly, a lot of the control is actually with the business networks themselves. The foundation, it's there to govern the boring underlying infrastructure, which is the Corda network. But a lot of the power about who can join business networks, who can transact with each other, who may be kicked off, is down to the business networks themselves. There could be millions of business networks. So in some senses, the decentralization still does exist. And on the foundation side, there's 11 directors in its current form. This is in its earliest stage and there could be more directors, but it's the members of the network who are on that. After the transition board who's just been appointed, there's going to be elections, and anyone who's a member of the network can elect the boards or stand for the board as well. So it's representative democracy rather than participatory democracy. It is a certain bit of decentralization, but it's still pretty open.
Ward: A lot of that could be put on ledger at some point. But what it's governing is actually very minimal. What it's governing is the root CA and the operator of that CA's ability to add people to a reputation list. So can you kick somebody off the network effectively? The only reason you would do that is denial of service attacks, in reality. By the way, it’s the root CA's ability to do CRL is an issue and then the second thing is what are called the network parameters, which are super basic. They're basically saying like the epic, how long when a node is unreachable until it gets removed from the network map because it's considered offline permanently, those types of parameters, which are very generic. If you look at what they're trying to govern then in the ability to add or remove participants, even a CRL is something you can recognize or not.
However, it's very useful for denial of service because we use TLS as the basic security layer. Certificates are required for that. That's the fundamental reason we have certificate infrastructure. The next layer is using that certificate for identity. A business network, so a smaller group of participants operating on a particular asset type and using a particular contract, could choose a different means of identity that would be separate from the TLS identity. They could choose a means of recognizing each other that would be completely independent of the network. Therefore, they always have business continuity. These are still peer-to-peer systems, so there's not much you could actually control in reality. You could very easily change Corda to say ignore the CRL entirely.
Participant 3: Could you please explain a little bit how you solve that problem? If there is, for example, a vulnerability in one of the JVM APIs we're using, how do you expand and change all the different instances of contrast running in all the nodes?
Ward: Sorry, I didn't really follow that too much. That was a little fast.
Participant 3: If the open source community found that there is a vulnerability issue with one of the JVM APIs that you are allowing to have in your small contracts, how do you change that in every single instance running in every single node?
Ward: If there's a problem with Corda is kind of an application server in a way, and it was a security problem, so we have a process through the open source community of taking those and responding to them as quick as possible. If it's open source you could patch it yourself if needed. If it's a problem, you're saying, like in a contract using an API that was discovered to have a vulnerability, it would be up to the contract. Unfortunately, that means somebody has developed that contract that has nothing to do with the open source community. They're just happening to use the platform for that purpose. So they would have to go through it and make updates.
One of the hardest things actually in blockchain platforms is contract upgrades. I heard a really good interview with one of the tethered tokens on the Ethereum platform, and they said, shipping an Ethereum token of that caliber where it's tethered to funds that are in a bank account somewhere, is like shipping hardware. They can't change the contract after it's shipped. So they've got to get it right the first time. They had some very notable processes for doing that. But Corda doesn't work that way. We kind of designed it knowing that you'd constantly be upgrading contracts because they reflect business logic that would change. You may find bugs, etc. You just want increased capabilities. Corda has built in a means of allowing contracts to be upgraded.
So this isn't the software itself, it's the contract, the executing. The most basic means is, if it's a small network, and there's a network operator, they can whitelist which ones are acceptable. Now, that's not good because that means the operator of that network now controls what goes on it and you don't want that. So the next is you can actually have a consensus mechanism run that all the participants of a contract would accept a new reversion. At that point, they would all transact once. They would take this stuff that's an old version. They would create a transaction migrating to the new version and they all upgrade to the new contract. What we just introduced with Corda 4 is the signature constraints. The participants can agree. A signed JAR is something they would automatically upgrade.
That's when you get into a more controlled network. When you receive a contract from somebody, the contract can propagate with. If you and I transact, I can send the newer contracts attached to that. These are all adjustable things based on how you want your security profile, but I could propose a contract, attach the JAR, you look at the JAR and say, "It's a newer version of mine." JAR is signed by a signature of a producer I recognize. I will automatically take this, upgrade my ledger to the new contract, and transact with you on the new version of the contract. And that becomes an automated process in that way, so it's efficient.
Now, it's always a trade-off then of how much risk do you introduce or not. That probably depends on what you're transacting over and who you're transacting with. Unlike Bitcoin, which is somewhat arbitrary - I'll pick anybody in the world, give them my address and transact because it's one asset type made for payments effectively - Corda has it's arbitrary. So you'll have governance rules that are very depending on who you're working with and what you're working on.
See more presentations with transcripts
