DevDay: Mike Hearn Keynote, R3
•Download as PPTX, PDF•
1 like•436 views
Mike Hearn, Lead Engineer at R3, keynotes DevDay at CordaCon 2019.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DevDay: Mike Hearn Keynote, R3
Similar to DevDay: Mike Hearn Keynote, R3 (20)
More from R3
More from R3 (20)
Recently uploaded
Recently uploaded (20)
DevDay: Mike Hearn Keynote, R3
- 3. Agenda 1.Things we’re not doing* 2.Things we’re actually doing *currently
- 9. BLACK START • 12 hours to Skeleton Network • 24 hours to 60% supply • 72 hours to full restoration Best case scenario!
- 11. Possible plan 1. Combine SIM and EMV Contactless chips. 2. Emergency GSM broadcasts at the start of an outage. 3. Phones move tokens into temporary chip balances. 4. Terminals enter emergency mode. 5. Chips can protect against double spending when not in daily use, good enough for 72 hours.
- 12. Things2
- 15. Weird consequences of wallets inside machines 1. Accidental collision or breakdown might destroy money. 2. User has to regularly fill up machine with money. 3. User cannot earn interest on money held in machines. 4. Machines can’t buy on credit. 5. End user would refuel with money, but often should be employer 6. Money shouldn’t physically pile up in beacons or charge points.
- 16. Common IoT requirement pattern • Physical proximity establishes business relationship • Security and authentication are key • Corda community can provide valuable solutions
- 17. Device Nodes and Ledger Sockets • Establish flow sessions linked to an encrypted physical connections • Linked flow is a “ledger socket” • “Device nodes” help create ledger sockets • Device nodes have machine identity. • Software library linked into embedded solution. • X.500 name contains serial number, VIN, other identifier.
- 19. Enclaves
- 20. SGX for ledger privacy Basic Java in enclave Advanced Java in enclave Verify transactions Add DJVM Signatures of validity Fully encrypted ledger
- 21. • Multi-party compute • Reduce trust in clouds • Lock down app stacks • Auditable SaaS • And more … Enclave oriented computing
- 22. • Generalised Java in SGX • Integrated with Corda • Multi-party computation • Designed for Java/Kotlin Conclave
- 23. • MPC over a set of Corda transactions. • Calculates an aggregated price owed to the app developer. • BNO/developer never sees the contents of the transactions. • Avoids pricing traps Transaction pricing (TXP)
- 25. London 2 London Wall Place, London, EC2Y 5AU Hong Kong Bonham Strand, 7F Office 18- 121 Hong Kong www.r3.com Thank you Brazil Av. Angélica, 2529 - Bela Vista 6th Floor São Paulo - SP, 01153-000, Brazil New York 11 West 42nd Street, 8th Floor New York, NY 10036 Singapore 18 Robinson Road, Level #14-02 Singapore, 048547 Come discuss on corda-dev@groups.io
Editor's Notes
- Thanks for coming, thanks for being a part of the community. Sometimes building Corda can feel totally overwhelming, so it's comforting to see how we're all in this together and how the Corda community finds ways around whatever obstacles are in its path.
- What this community is doing is tremendously ambitious and poses fundamental technical and social questions. And what's amazing is that everyone wants to do everything all at once: not just conventional business IT use cases but consumer, embedded, advanced crypto, everything. If it’s futuristic and hard, you guys want to do it, which is outstanding.
- This talk has two parts, the first part is actually about things we’re not doing. Then I’ll talk about things we are doing. You might wonder, why bother talking about things R3 isn’t actually working on, especially because we already have so much stuff in the tech white paper that isn’t implemented yet. And there are two reasons. One is that planning ahead can stop us painting our community into a corner, because APIs are hard to change once shipped so every move is your last move, in some sense. But the main reason is that the Corda vision is far too large for us to ever execute alone, and I think that’s clear to everyone. Even with our expansion R3 can’t possibly do everything the community wants. But we CAN provide advice on how to extend Corda into new areas, what would be in the spirit of Corda, and that has value in avoiding messy situations where people use Corda in ways that won’t work well, or make open source contributions we feel aren’t designed quite right.
- There’s a lot of interest in retail e-cash projects, often from central banks that want to phase out the use of paper money or at least have a plan to do so. Obviously these projects are inherently cool because they're about things that you or I might actually use in our personal lives, whereas typical CorDapps are not. It would enable CorDapps to directly sell things on ledger to consumers and all kinds of great stuff.
- And the first blockchain app I ever wrote was a Bitcoin mobile wallet, with a guy in Berlin, Andreas Schildbach, in fact it was this mobile wallet, the first ever cryptocurrency p2p mobile wallet. So this kind of proposal would be full circle for me, back to where it started and that is also kind of inherently cool.
- But we aren't currently working on this sort of project as far as I know, at least not from the engineering side, so it may well be that in the end it's community members rather than R3 that does this stuff. Unfortunately, I often find myself counselling caution on these initiatives. A big part of the reason is the list of stated and unstated requirements that come with them. Or wishes, depending on your perspective. Typical requirements include for instance, that the resulting tokens be "just like cash" but with negative interest rates, which isn't much like physical cash. There are quite a few of these apparently contradictory desires, and we do have some ideas of what to do about it, I'm not saying the situation is hopeless or trying to push things back onto the users here because the desires are understandable even if there may be no obvious way to implement them. But I thought it'd be interesting to zoom in on just one of the interesting requests the more switched on central banks give us: the ability to work without electricity.
- What happens in a world that got rid of all its physical money, when the lights go out? Let's consider the worst case scenario: a full national blackout. How long do we need our cash system to survive before it's OK to collapse along with the rest of civilisation? This may sound like a detail best left to later, but it’s important if you’re planning for ubiquity, and it’s this sort of detail where I think R3 can contribute to the community even if we don’t have the resources to write all the code ourselves.
- It might appear at first that we can just handwave past this because we're developers, developers write apps, apps run on smartphones, and smartphones have batteries so where's the problem? But this doesn't quite work because smartphone batteries wouldn't last long enough, as we will see, and anyway they're desynchronised so there are always people about to run out of power, and also merchants probably use custom PoS terminals not phones.
- Now if the National Grid were to experience a nationwide blackout right now, engineers would begin a process called a black start. In a black start workers first establish nationwide communication via CB radio networks, and then begin a restart process where each station is brought back online and resychronised with the others, one at a time until the whole grid is restarted. If you look at their projections for what's involved, in a perfect situation it would take about 12 hours to bring online what they call a Skeleton Network that's only usable for rebooting more power stations, and another 12 hours after that to restore about 60% of demand, so we can expect that around 30 million people would still be without power a day after the process starts. It would take several days to restore power fully everywhere. But that's the theoretically perfect scenario. The grid is highly unstable during a black start and if anything goes wrong, stations might trip out again forcing the whole process to be repeated from the beginning. And in real situations there's usually damage or other problems that caused the blackout in the first place, so it could take quite a bit longer than that. So my guess is that any e-cash system needs to be able to survive, for everyone, for at least 72 hours without power. Almost immediately this rules out smartphones as the only way to trade. Their batteries won't last long enough. So what can we do?
- Well, we already have a lot of infrastructure that can do this in place already. The EMV specifications are what underlie today's card payments system. Prepaid cards are electronic but energised by the terminal, so as long as the terminal has power so does the card, and EMV supports offline transactions because it dates back to the early 1990s when internet access wasn't so widespread as today. So we can make the wired terminals all have big batteries that will last 72 hours or more. This should be easy because they're low power devices and already very bulky. At the same time EMV is a basically bank oriented system, and what we want is more like cash, so what can we do?
- So how about this - we combine mobile SIM cards with the EMV Contactless spec, so every phone doubles up as a prepaid card and can be held against a terminal even if the phone itself is out of batteries. At the start of a power outage emergency GSM broadcasts start being made to every connected phone and this is forwarded to the wallet apps on the device, which then use the remaining battery power to convert tokens held on the device into a balance on the prepaid card chip. The app goes into reduced functionality mode, for instance, maybe at that point you can't send money to people physically distant to you. The terminals react to the same broadcast by disabling their receipt printers because motors and printers consume a lot of battery. And every terminal gets new software that allows balances to be moved from chip to chip, so person-to-person payments work if both people can get to a terminal. The government passes a law that says during power outages any merchant must allow anyone to exchange tokens with anyone else using the terminal as an intermediary. In this way, money could continue to change hands all throughout the duration of a blackout that takes out not only all mobile infrastructure but also all banking and datacenter infrastructure. At the end of the outage the balances are withdrawn from the chips and converted back into tokens. The cryptography of this is a bit convoluted and needs more research, but I think this plan could work.
- There's huge community interest in putting Corda into things. I'm also interested in things. You might say we all have things in common. A great project has for example been the collaboration between Daimler Motors and Commerzbank, for electric truck charging, where they used Corda in an IoT use case.
- And here's another use case - imagine we want cars to bid in real time for movement authorities on a toll road, to avoid it becoming way over capacity and jamming up. So the car needs to make payments to roadside beacons and maybe it's taking part in a Vickrey-Clarke-Groves auction, which if you've forgotten your auction theory allocates items in the auction in a provably socially optimal manner. If the car loses the bids it should pull off at the next exit. You only pay for the distance you travel. There are lots of projects exploring use cases like this one. A common starting point is hey, why don't we put a Corda node into a device! Some of you have tried this and you discovered it doesn't work well. Corda is designed for datacentres, not little devices. It's pretty fatty and getting fatter as we add more and more features. You also discovered that Corda isn't unique in that regard, actually an Ethereum node is much fatter still and ditto for Bitcoin, Fabric, Quorum etc. So this is actually an industry wide challenge.
- It’s probably a good idea to take a step back and ask what we’re really trying to achieve here. If we could magic away the size issues tomorrow, would it be ideal to put nodes designed for datacenters into devices? I’d argue it probably isn’t ideal. What we’re really wanting is a new kind of node, but which extends or can talk to datacentre nodes. It’s not uncommon for P2P networks to have different classes of nodes, even though many people have been learning about them for the first time through Ethereum which doesn’t. Bitcoin had the concept of a “simplified payment verification” node which was specifically designed for smaller devices like smartphones, yet which could still use the P2P network. But does it make sense for the car itself to make the payments? Well, probably not.
- That would imply that if the car had an accident the money inside it might be corrupted and destroyed. It'd also mean the user has to fill up the car with money at the start of their trip, like with fuel, and that'd be weird. It also means I can't buy things without having earned the money yet and of course people love their credit cards, but cars don't have credit scores, that'd also be pretty odd. Plus many drivers are driving for business and it should be the business that pays, not the driver. And finally you don't want money to pile up physically in roadside beacons that then have to go and be physically visited to empty them out. So all this suggests that thinking about this like in the cryptocurrency world isn't quite right.
- What we actually want is to establish a link between the node holding an end user's tokens, like maybe their employer's node, and the node run by the toll road owner, such that the act of driving onto the road establishes a business relationship there and the act of driving off it terminates that relationship. And we need it to be very secure so strangers can't impersonate your vehicle and run up a big bill on your behalf, nor can they set up fake roadside beacons that trick your car into paying them for a road that's actually free.
- And it seems like this is a common pattern – you’ve got two things in the physical world, and you want to establish some sort of linked business process in the back office world. “Device nodes” exist to start flows between regular nodes sitting in datacenters, which are tied to some sort of physical connection in the real world. We can call such a linked flow a ledger socket, in a nod to the concept of a TCP socket. A device node would be a tiny bit of software running on embedded computers that can do Diffie-Hellman handshakes and communicate with remote Corda nodes. They have a private key kept in a secure chip, and they're physically glued or joined in some way to the device they represent. Every device has a certificate which is a sub-cert of the manufacturer node Corda cert, this works because we use X.509 name constraints rather than path length constraints as in the web PKI.
- It means manufacturers can join the Corda Network and issue certs for every machine as they get manufactured, and they don't have to publish anything, these aren't in the network map. So sales numbers are still private. The certificates ensure that peers can detect fake devices like emulators and stop people doing impersonation fraud. The identity is strongly linked to the physical object. Armed with this cert and some basic protocols we can design, the act of coming into range or plugging the two devices together would set up an encrypted, authenticated connection between two devices, and simultaneously trigger flows between the two owning nodes, so negotiation over prices and ledger transactions can be handled by the servers and simple commands like "pull off at the next exit" can be sent to the car's on-board computer. Each kind of computer does what it's designed to do and it should all work out. We don't have any prototypes of this, it's just a thought experiment. But I'd be happy to work with people in the community if you wanted to try it. It'll definitely get you further and faster than bugging us to make the node use less RAM.
- In the last part of my talk I want to discuss our ongoing work with Intel on bringing their SGX enclave technology to you. Those who have been in the community for a while know we've been talking about SGX from the start. When we started laying out our plans to use enclaves we were totally alone, everyone else in the blockchain space - really in the whole software industry - they were all pushing zero knowledge proofs and purely mathematical techniques as the future, but we looked ahead and saw that wasn't going to be ready on any kind of sensible timeline and so we started experimenting with secure hardware instead. In recent months what we've seen is other blockchain projects accept that this was the right call and come into our camp, we've seen the Enterprise Ethereum Alliance do that, Fabric, a bunch of others, Microsoft has been combining their blockchain and MPC groups I heard, so a lot going on. We realised that to make enclaves work well for Corda developers would require a big effort. We planned out a roadmap that looks like this:
- And we've been steadily chipping away at that ever since, whilst still focusing the bulk of our effort on getting apps that were satisfied with the current tech into production. We're now deep into the 4th stage. We can run real smart contracts with deterministic Java inside an enclave, and we have a very detailed design doc and proof of concept for how to use SGX attestations of transaction validity like zero knowledge proofs, so you can check a transaction without actually seeing it. We've worked out incremental deployment scenarios because not everyone in a Corda network will have SGX technology all at once, and I think we'll be taking this to the Technical Advisory Committee soon, you'll start to see parts of the support for this land in Corda over the next few months. If you come along to my demo session this afternoon I'll be talking more about the work we're doing there and giving an update on the enclaves privacy work. Getting all the moving parts to align is a complex project and it's been a long road. But we knew that at the start and we're making steady progress.
- Enclaves can be used for more than just privacy. Enclaves can be used as the foundation for an entire multi-party computation infrastructure, for eliminating trust in cloud operators, for locking down computer networks and much much more. But to get those benefits you need to design your software in a particular way. Enclave oriented computing is the term I use for a fundamental software design pattern that I think you're going to hear a lot more about in the coming years. But let's focus just on multi-party computation for a moment. MPC is a term cryptographers use to mean several people submitting data to a shared computation, and they get back the answer, or their part of the answer, without anyone ever seeing all the data or the intermediate values. You can use this to aggregate data in various ways without trusted third parties. We've been working on generalising our Java in SGX work so it can do more than just run smart contracts, and we’re now working on bringing that to market. The generalised platform is called Conclave. Conclave lets you run non-deterministic, non-smart contract Java code inside an enclave. We eventually plan for it to be also a standalone offering, which is why it has a separate name, but the first versions will be integrated with Corda. It'll add powerful new capabilities for developers to the API. As part of that work I wanted an initial use case that would help us learn what the APIs should look like, but which also would deliver immediate value to our community if brought to market. The team at b3i work down the road from where I live and so I visited them to do some brainstorming. Here's what happened:
- Enclaves can be used for more than just privacy. Enclaves can be used as the foundation for an entire multi-party computation infrastructure, for eliminating trust in cloud operators, for locking down computer networks and much much more. But to get those benefits you need to design your software in a particular way. Enclave oriented computing is the term I use for a fundamental software design pattern that I think you're going to hear a lot more about in the coming years. But let's focus just on multi-party computation for a moment. MPC is a term cryptographers use to mean several people submitting data to a shared computation, and they get back the answer, or their part of the answer, without anyone ever seeing all the data or the intermediate values. You can use this to aggregate data in various ways without trusted third parties. We've been working on generalising our Java in SGX work so it can do more than just run smart contracts, and we’re now working on bringing that to market. The generalised platform is called Conclave. Conclave lets you run non-deterministic, non-smart contract Java code inside an enclave. We eventually plan for it to be also a standalone offering, which is why it has a separate name, but the first versions will be integrated with Corda. It'll add powerful new capabilities for developers to the API. As part of that work I wanted an initial use case that would help us learn what the APIs should look like, but which also would deliver immediate value to our community if brought to market. The team at b3i work down the road from where I live and so I visited them to do some brainstorming. Here's what happened:
- Enclaves can be used for more than just privacy. Enclaves can be used as the foundation for an entire multi-party computation infrastructure, for eliminating trust in cloud operators, for locking down computer networks and much much more. But to get those benefits you need to design your software in a particular way. Enclave oriented computing is the term I use for a fundamental software design pattern that I think you're going to hear a lot more about in the coming years. But let's focus just on multi-party computation for a moment. MPC is a term cryptographers use to mean several people submitting data to a shared computation, and they get back the answer, or their part of the answer, without anyone ever seeing all the data or the intermediate values. You can use this to aggregate data in various ways without trusted third parties. We've been working on generalising our Java in SGX work so it can do more than just run smart contracts, and we’re now working on bringing that to market. The generalised platform is called Conclave. Conclave lets you run non-deterministic, non-smart contract Java code inside an enclave. We eventually plan for it to be also a standalone offering, which is why it has a separate name, but the first versions will be integrated with Corda. It'll add powerful new capabilities for developers to the API. As part of that work I wanted an initial use case that would help us learn what the APIs should look like, but which also would deliver immediate value to our community if brought to market. The team at b3i work down the road from where I live and so I visited them to do some brainstorming. Here's what happened:
- I really wish I had more time because there's a ton of things we could explore together as a community, but I wanted to leave you just with a reminder that with the exception of the SGX work I just mentioned, you're going to often see us talk about designs which we don't plan to implement any time soon. This is how we've always worked and it's because we want to help people experimenting with using Corda in new contexts to find the right architecture and the best way Corda can work for them, even if we're currently busy elsewhere. So if you're interested in IoT or consumer wallets, please do say hello on the corda-dev@groups.io mailing list.