 Our approach involves thinking about the system as a whole and thinking about the ways in which things can fail. And this is different from what people typically do when developing a system. Their focus, quite understandably, is on trying to make the system work. So they're focused on how do you get it to do the right thing and not worrying about all the circumstances in which things or something might go wrong. Whereas what actually happens is, for many systems, the ways in which it goes wrong and it probably only goes wrong fairly infrequently, but every time that happens the effect is quite large. And so when you're looking at the performance of the system as a whole, those occasional failures, they can just be exceptions, they can be unusual circumstances, they can be things that the programmer didn't think were very important, didn't spend any time optimising. Those can be the things that end up dominating the performance of the system as a whole. Our sort of raison d'etre is actually making things that work so well that they become effectively boring and you don't have to sleep at night, you don't have to worry about them. So for us, infrastructure is something you should just ignore, it should be there. It's something you can trust to build other parts of your daily life or your business life on top of. One of our earliest projects where we developed a lot of the tools and techniques that we used today was working on the US Department of Defense Future Combat Systems Program, which was about creating a new battlefield communication system for the US Army. And it was a $300 billion program and they had 6,000 engineers working on it. But across the whole of the US, they were unable to find anyone who could reason about the performance of the system in advance of it being built. We were able in the end to show that it was impossible for the system to meet the goals that were being put on it. So in the end, because of that and a number of other reasons, the whole program was cancelled after they'd spent only $25 billion. Cardanas, like many systems we're building today, are not ones that you can afford to make mistakes about. You're going to build complex distributed systems that are going to make settlements, that are going to engage in protocols and engage in smart contracts and things like that. Once you've set those pieces of software going, they're going to execute exactly what you told them. You've got to think about the ethics, about the emerging properties that are going to happen, how people are going to interact with it, how it's going to change, how you're going to correct issues, etc. So it's very interesting that we're not just doing performance engineering here, we're sort of beginning to do ethical engineering. So in the Cardano project, we're very excited to be able to apply our techniques for reasoning about performance in advance of something being built and deployed. We're not just engaging here in software engineering or performance engineering, or even fiscal engineering or whatever that is, but we're also engaging in ethical engineering. We're trying to make the systems that we trust ones that work for us and for our fellow citizens of the world.