 So, I'm going to talk about a language for financial contracts on blockchain. So, the idea is that there's been previous work on describing financial contracts using programming concepts from programming languages. What I'm going to show is how we've adapted that work to work on blockchain. We've got a language Marlowe and we have a tool meadow that allows you to interact to visualize what's going on with your Marlowe contract. I'll give you details of the language and what we can do with it. And I should stress, and I think this is true particularly of the presentation about Marlowe, this is work in progress. We've been doing this for a while. We've got to a stage where we're very pleased to present it to everyone, but we've got a lot of plans for things in the future. And those I will talk about at the end. So, let's get started. I think the best place to start is in the 1950s. If you think, if you look back and Phil was talking about the history of computing before there were computing machines, I'm going to take it a bit further forward. Look at the first, this is the first business computer. It was a Leo computer built by the Cambridge team for the Lions Cake Company. If you wanted to program that, you had to learn the machine code of that machine. Very low level instructions, and what you could do with that was simply code that machine. When the next machine came along, if you bought a computer from a different company, you had to learn a completely different language. So, you needed specialists to write programs for that sort of system. So that's not ideal, and it spurred the development. Though there is resistance at the start, you'll never be able to write efficient programs using these high level languages that were developed around 1960, Fortran, Algol, and so on. And they were developed to help program the computers that we see there. Often the compiler would be tied to the machine, but you were able to write a program. And perhaps with some ease, you're able to move it to another machine. But you still had to be a coder. You still had to be a programmer. And really, that's the situation today. If you take out your MacBook or whatever and you want to program for it, you write programs in C++ or Java or maybe Haskell. And the situation is similar when you look at Blockchain. If you want to write programs to run on Ethereum, you have to use Solidity, a general purpose programming language. So you need to code. That immediately restricts the availability of these systems for general users. And it's a bit like the distinction between coding on a traditional machine and using something like Excel. I think we bandy around the figure that there are 10 times the number of Excel users than there are coders. And I think we could foresee a similar thing in the Blockchain world, that we would have general purpose languages like Solidity, like Plutus, that will allow us to write anything, code anything for the Blockchain. But what we've been trying to do is an experiment to look at something different. We're saying, let's look at the people who are actually using the language or potential groups of users. Look at a particular domain and try and express things in the language of the domain, not the language of the Blockchain. And this general approach is called, in the jargon, a domain-specific language. So you build a language that reflects the terminology, reflects the applications of that particular field. And so it's closer to the user. It's focused on the user, not on the technology. And people have been doing these things for a long time. You see them in different areas. And you get a whole lot of benefits from this sort of approach. One nice thing, if you look at a DSL in an area which is error-prone, to say the least, by designing the DSL in the right way, you can rule certain errors out from the start. When you've got your language, because it's working in a more restricted domain, you can analyze your programs, your contracts or whatever more easily, and you can make more accurate analyses. And you can design special purpose tools. So if you're focusing on something specific, not general, you get a whole lot of benefits from that. And just the final thing to say about this, a DSL is a language. So in some ways, we can have our cake and eat it. We can take our DSL and embed it in a general programming language if we wish. Use a few features from that. I'll show you something of that a bit later on. But also because it's what we have our programs, we can execute them. But also in the world of financial contracts, we could give evaluation of a contract. We could look at how we might simplify a contract. Is this contract the same as this contract? Because we're expressing them in that specialized language, we have those sorts of possibilities too. So I hope what I've done in this first part is give you a motivation for looking at DSLs in this space. Now what I would say is that financial DSLs aren't new. People have been looking at these for about 20 years. There's a model for this, worked by Simon, Peyton, Jones, particularly, but others have followed on from that in using constructs of functional programming to describe financial contracts. And what we've, our contribution here is to take that work and say what are the implications of putting these contracts onto blockchain? And I thought just to give you, in order to animate this a bit, I'll give you a simple example of a contract and then we'll look later on at how it gets modified when it gets onto blockchain. So the characters in these traditionally are always Alice, Bob, and in this case, Carol. Alice has some cash, Bob has a cat, Alice wants to buy Bob's cat, but Alice and Bob don't trust each other. So how can they, but they do both trust Carol. Carol's a mutual, a mutual friend of theirs, and they both trust her. She's, how can we work it that the money gets transferred to Bob only in the case that Alice, Bob gives a cat to Alice? Well, here's a model. Alice puts some money on the table in the contract, if you like, and she waits. She says, does the, am I getting the cat? Hello, behold, yes, she gets the cat. At which point she can see she's got the cat, she's happy. Carol can see that. So the two of them, oh, sorry. I mean, Bob can see that she's got the cat, he's given the cat. Carol agrees with Bob, he's given the cat, and the money gets transferred to Bob. So Carol and Bob here agree. Carol sees that Bob has done what he should do, so he gets the money. If we backtrack, whoops, what's the other situation? Alice puts the money on the table, she waits. She waits, the cat is sitting resolutely there, and she says, right, okay, Carol sees she's not, she's not got the cat, she and Alice agree, she gets the money back. So it's a simple, what's called an escrow contract. So we've got these two alternatives, either Carol can see and concur with somebody, the cat has been transferred, or she can see, the cat has stayed with Bob. So how can we turn that into a contract? The answer is, there's a bit of simplification going on in the examples I show you, but broadly, this is the contract we might expect to see. And in particular, the things I highlight in pink here are the things that allow us, these are the building blocks of the contract. We have an option to say when this condition becomes true, do what the contract here says. So we can wait for a condition to become true. We have a choice here, and what the choice says is, well, depending on what, whether this is true or not, we do the first contract or we do the second. But what's nice about that, you can see, I talked around the diagram before, I showed things moving around. But this gives you a concrete description of what should happen. So we have this language with a small number of these combining forms, when, and choice, and pay, and so on, that allow us to build a contract like that. Okay, so that's the second ingredient. We've talked about DSLs. We've talked about financial contracts. The third ingredient into which fits into this picture is just to tell you a tiny bit about the Cardano platform, just in case you're not aware of what that looks like. At the basis, we have the Cardano settlement layer. This is the blockchain with a very simple settlement layer. We're not doing complicated transactions. We're not doing complicated programming. It's not a general-purpose programming platform like Ethereum. It's the level at which settlements take place. And for those of you who are aware of this distinction, it's a UTXO-based layer, not an account-based layer. So it's like Bitcoin rather than Ethereum. It's as simpler conceptually. And Manuel will be talking a lot more about this afternoon. So we have the Cardano SL. On top of that, we have Plutus. There's Phil explained in the first lecture. Plutus is a stripped-down. Plutus Platform is a functional programming platform for writing operations over that UTXO blockchain. And then we have things like the real world. We have time. We have random numbers and so on. And we have wallets belonging to people who have accounts containing Aden. And what you can see is that Marlowe fits in here. It Marlowe fits on top of Plutus and provides this special-purpose access to special-purpose language for designing financial contracts. And those contracts can talk about things in the real world, the price of oil, a random choice. And it can interact with users' wallets. Now just to stress, I mean Marlowe is... And it was designed to fit into this stack, but you could also see it fitting into other stacks. You could say, let's run it on top of Yelle, on top of the Cardano computation layer. Run it on a side chain, for example. Or indeed, you could see it running on an entirely different platform like Ethereum. It's a general purpose in that sense. Marlowe contracts can be implemented on top of a number of different platforms. But the one we're concentrating on at the moment is running on top of Cardano SL. OK, so that's given you the three ingredients. We've got the idea of a DSL, we've got the idea of a financial contract running on that DSL, and we've got the Cardano platform. What does it mean to take a contract and run it on blockchain? What are the implications of saying, we're leaving the legal world, we're leaving the world of lawyers and fiat currency, if you like, and we're moving to a world of blockchain? So a typical contract in the old-fashioned sense is one which describes what should be the case. It says Alice should pay money to Bob, et cetera. But if Bob doesn't pay Alice when he should, Alice has recourse to the legal system. She can sue him. What can we do to replace that? What we can try and do is build mechanisms on blockchain that will make sure that the right things happen. We can build contracts which will enforce themselves. So that's one aspect of moving things onto blockchain, which is very nice, get rid of the legal system. There might be disadvantages to that, but you can see in certain areas, if we can factor that out, that would be a good thing. I suppose the other thing, a note of caution, if you like, is the other thing that happens when you look at cryptocurrencies and you're thinking of running things on blockchain, these things are designed not to allow you to spend the same money twice. That's a good thing. If you have money in your pocket, you can't spend it twice. The problem is that a lot of the financial system depends on you spending money twice. The whole notion of credit allows you to spend money you don't have. So if you move to this self-enforcing model, take the completely radical approach, then credit and so on disappear. So I think you need then external providers of credit and so on and so forth. So it's not without complication in that regard. But we do hope that what we have to think about at the moment is concentrating on the first, trying to see how we write contracts in such a way that they're going to be self-enforceable. And there's a very nice phrase that I think is has been accredited to Buterin but potentially to other people. This idea that you have what's called crypto-economics. You're putting together cryptology to cryptography to make the past irrefutable. One of the key features of distributed ledger technology is that the ledger can't be changed. It's there forever. So the past is protected by cryptography and then you use financial incentives to shape people's behavior in the future. So it's that combination of... which makes it intellectually, I think, a fascinating area to work in. And I think the other point to make here, and this is one that becomes crucial, you'll see a bit later on, is that there are two things we need to do in order to shape behavior. We need to make sure nothing bad happens. Obviously, we don't want money to be spent twice, but the blockchain will support us in that. If the contract says money goes from Bob to Alice, it should go from Bob to Alice and not from Bob to Carol. But we equally well have to avoid walk-away. We have to prevent the situation where some money gets put into a contract. And I can see nothing good is going to come out of this for me, so I simply walk away. We have to design things in such a way that once somebody has signed up to the contract, they are incentivized to carry on... to carry on participating. Or the contract in some way ensures that their walk-away can't subvert what is meant to happen. So that's something to bear in mind. Bad behavior we don't want, we don't want to be able to sub-sent themselves. OK, so Marlowe, I can finally talk about Marlowe. And in a nutshell, OK, this is perhaps for... slightly more technical. We've implemented Marlowe. It's a Haskell data type, so it's an embedded DSL. It's embedded in the Haskell programming language. We've got an executable semantic, so it's completely formally specified by writing a Haskell program what this language does. We've got an implementation on the Cardano Mockchain. So as it stands, the implementation of Marlowe is the biggest Plutus contract working on Mockchain. Because effectively what we've done, this is Alex, who's on the Marlowe team, has written a Marlowe interpreter, if you like, as a Plutus contract. If you remember, you could see the fill was showing the two sorts of code, the code that runs on-chain, the code that runs off-chain. What we have is the code that runs on-chain, and that enforces that Marlowe contracts on the blockchain are enforced. They only do what they do. We've got some work on analysis for these contracts. We're doing some work on proving properties of the contract. And we've got a simulation in this system meadow, which I'll show you a bit later on. And what we have to think about... I'm not going to say a huge amount about this. It's something that's on the agenda for the Plutus project and for Marlowe in the next few months. It's thinking about how we deal with oracles, observations, things coming from the real world. How do you generate random values, for example? You want a source of randomness. How do you incorporate that into a contract? One simple way of thinking about it is that you can model an observation simply as a value that has got a signature that is agreed by every participant in the contract. And that provides... In the end, that's what a... It will have to be whatever mechanism you use. It will have to be a mechanism which is trusted by all participants. So just saying to participants, you must sign this off in some way, is not a bad approximation of reality. But I'm not really going to say much more about that. The things I really wanted to talk about are twofold. In order for contracts to work, in order to make sure that contracts don't fail, we require people to commit cash upfront. So people commit a certain amount of money in order to avoid people walking away, that commitment is finite. So you say I'm going to put 100 ADA into this contract. If everybody else involved simply walks away, you will get that money back after a finite time. So our commitments say you commit for a finite period. We need to, as I say, we need to avoid walk away. But if you think about it, a contract can't require you, contract running on blockchain, whatever, can't require you to make a commitment. It's not that the modality is just wrong there. So we can't require a commitment. We can only ask for a commitment. And so when we ask for a commitment, if I ask for you to commit 100 ADA for 20 blocks, I have to give you a timeout. I have to require you to answer within a finite amount of time. Not only are our commitments bounded, but the time we wait for someone to make a commitment is itself bounded. If you like, we're not... Running the contract on the blockchain doesn't make anything happen. It's important to... It makes nothing happen off the blockchain. What it does do is allow things to happen. So it's permissive. Instead of making a payment, what the contract will do is allow you to claim the payment. So it's a... If you like, you're pulling stuff out of the contract. The contract is not itself pushing things to happen in the real world. So commitments, if you like, this is the summary of what we have done to the traditional contract languages in order to make them work on blockchain. So here's our escrow contract. Remember, we've got a when. We wait for a decision, and then we make a choice. How does that vary? What do we do differently in our language? Well, first of all, we only wait for a finite time. But what we're doing here is we're saying, when this happens, do this. But what if this never happens? Does the contract live forever? Potentially, there's no reason it shouldn't. You could program it to do that. But we want expressly to rule that out. So we have to think about each of our constructs having this timeout added to it. So we say, that happens up to block 90. So there we've got our... So now we're saying, we've up to block 90, when this happens, we do this. What happens if we get to block 90 and that hasn't happened? What we have to do is provide an alternative. So we provide the alternative that says what happens if we get to that point and we trigger this at timeout if we've not triggered the when. So we add timeouts and we add extra actions to our contracts, extra contracts to be executed when timeouts happen. So there is our... There's our escrow contract, but we have to do something extra. And I have to shrink this because it gets a bit bigger. What we have to do is put around that some sort of cash commitment. And here you can see Alice... I remember Alice was wanting to pay 15,000 ADA for her for the cat. So in executing the contract, we put that commitment around it. And what have we got in here? We're saying this contract says wait for Alice to make a commitment of this amount. It says make the commitment up to time 100. After that it can be redeemed. You can get your money back after 100. But it also says this is the time you wait for Alice to make the commitment. So we only wait up to block 10. Alice hasn't made the commitment by then. What we do is whatever sits there. So our commitments have this... Our commitments have themselves, these two timeouts and this remedial action here. So what we've done, as I say, is we've taken the constructs from these previous approaches and just embellished them with these timeouts and added the notion of a commitment. Okay. I can show you Marlowe here is the... What I'm showing, I should say, this is formerly version 1.3 of Marlowe. It's the version that's reported in the paper that we've published about this. It's the version that's implemented in Meadow. We are already looking at adding one or two constructs. But you're seeing a consistent presentation of here of what's in the paper, what's in Meadow. So what do we add? You can see we've got this commitment to cash. We've got a way of redeeming a cash commitment. We've got a way of making a payment. So here what we're saying is we're making a payment from one person to another of a certain amount of money. That payment can happen if the person doing the payment is being made, claims it within a particular time, otherwise you follow this contract. Again, with the timeout, it's a very remedial action. And we're able to combine contracts together like that. And that's pretty much it. It's a small compact language. If you read Haskell, you can see it's pretty standard Haskell. And I've just added a couple more examples. This is a very simple futures contract. I think of Alice and Bob put in, committed a certain amount of money, and then effectively at the delivery date, depending on how the spot price relates to the forward price, then certain payments are made. I've grayed out the bits here, which are to do with timeouts and remedial actions. So if you like, the real functionality is in the colored part. And you can see that we've had to add these things. And there's a question that we're thinking about. How easy is it to take a non-blockchainized contract and turn it into one that works on blockchain? That's something that we're thinking about at the moment. So we've got a simple futures contract there. This is a deposit incentive contract. So Alice commits 100 ADA, Bob commits 20 ADA. If Alice chooses during the period up to 100 to get her money back, they both get the money back. Otherwise, if you reach the point 100, Alice gets her money and Bob's. So it's a very simple sort of, we call it a deposit incentive. She's getting a reward for locking her money up for that period. And the reason I put this up is I'm going to show you how this works in Meadow in a few minutes. Okay, so I think I've shown you that. Now let me say a tiny bit about what it means to embed Marlowe in Haskell. I was playing a tiny bit faster and loose earlier on when I showed you this contract. Because in fact, these things like majority, chose and redeem original are not things that are defined in Marlowe. They're things that we've chosen to use the embedding in Haskell to define. But I think the way to think of these is that they are effectively abbreviations. We're saying here's a name for a little bit of a contract. Or they're simple templates. Here's a name for a very simple function or template that generates a contract according to one or two inputs or arguments. So we're taking, we can just use a very small part of the functional language Haskell to make our contract look that much more readable. So for example, we might pay chosen might be the fact that the majority have chosen the result pay. And we might have that the majority choose an option X. This is the template, this is the function. If two of Alice, Bob and Carol have chosen X. So we're able to build up a top level contract just by writing some simple names, simple naming of contracts and simple variable contracts to give us the top level result. So I think you could say okay, you're using half your users because you're writing programs. But I think what you think of here is we're just writing abbreviations. I think we're staying within an area of safety. This is a sample of one, but I was travelling up on the train at the weekend and sitting next to a friend who's a journalist and he was saying, what are you talking about on Tuesday? I said, oh, it's this. And I showed him this contract. He said, oh, I can understand that. He said, it's a bit like the sort of formulas I write if I write something in Excel. And I said, I'm going to quote you on that. Because it's, you know, he didn't, I didn't offer him 20 quid. There was no incentive, no financial incentives to get him to say that. So I think what we are doing here is working at a level where we're writing denotational descriptions of simple contracts. An obvious way of building up a complicated description is to add some simple abbreviations. Okay, so we use embedding. Now, what are we doing for time? Okay, let me say a bit about implementation. Because we've done a number of different things here. We have inside Haskell, you can run, we've written a small step semantics for our DSL. So you can run that in Haskell. If you're comfortable with doing things in Haskell, that's fine. What we've also done is build a tool that allows you to understand more visually what a contract is doing. Now, projectors are the bane of everyone's life. I know, I'm going to show you this. Let me just describe a tiny bit of what the layout is here. On the left, we have a block representation of contracts. So what you can see here, for example, these are all the contracts, possible sorts of contracts you can write. And in each of these holes, you can put a certain sort of, some of them require money, some of them require observations, some require other contracts. So you can build up complicated contracts like this by assembling these blocks together. It's a visual rendering of this, of the Haskell data type. What you can see in the top right-hand corner is the Haskell representation of that. And if you prefer text blocks, you might think, whoa, that's a lot more readable. But we're providing facilities for both kinds of things. Also here, we've got facilities for stepping through understanding how your contract is going to behave. And I will show you that now. I hope. Okay. Now, this is a bit more, I've blown it up a bit. So what have we got here? We have got, okay, with some of the abbreviations removed. So Alice has become one and Bob has become two. They're just abbreviations for, they're enumerating the participants. So what we have ways, you can see here, you can convert from the blockly to code. You can convert code here to blockly. So we're able to move between those two forms. What else have we got? Well, what else we have is, you can look inside the contract and perhaps we don't want to do that particularly, but we'll see what happens. But we can provide input and in order to help you step through your contract, we can tell you which inputs you can, we make sense to write. You can, there's a manual that you can choose to put in whatever input you like. But we're saying, actually, the sorts of inputs you want to make are these. So let's add, let's say at this step, we want to do this action and then we can execute. And what happens there? You can see the contract, you can't see, the contract has shrunk if you look at the top. We now got a smaller contract because we've executed the first commitment. We've advanced by one block and then let's make another commitment here. We'll say do that action. You'll see the current block will advance to two and you should see the contract up here will advance. So the contract is simpler now and we're getting different choices. We're getting different choices here. So let's choose, should we choose zero? What's the choice going to be? So you can see we have expanded that out and I'll show you how we can deal with this expansion problem in a second. Let's just make the choice of one. Let's add that action and then execute. And now what have we got? You can see the contract here is now perfectly readable and we can see the contract up here is readable. And what this is saying is that we're going to redeem both the original commitments because we made a choice before the contract expired. We were waiting 100 steps if you like. So what we've done here is we're going to redeem. We're allowing both participants to redeem things and that's the end of the contract. The contract is exhausted now. So what you can do is you can design your own contracts. You can execute a single step through them using this visual interface. But the one thing I haven't shown you, which I want to show you now, is that I talked about doing this as an embedded contract. And what we can do is we provide an embedded editor. Oh! Now, this only works if you run the web server. So excuse me for... Oh, okay. Oh, no. Right, okay. Let's... Right, okay. I set this up in such a way that I would be off the internet. And of course, if you don't run the local web server, your demo doesn't work. Right, I will not try and recover in real time. But what you are... Let me explain what you could do here. You get an editor for Haskell. Within the browser, you're able to convert that Haskell, that embedded contract, into a pure Marlowe contract and then execute it in Meadow. Oh, the nightmares of doing... I maybe do it after the end of the talk, but let me crack on with the talk. Where are you? So we've seen that you can do... You can interact with your contract in this way. Ah! Right, okay. Let's carry on. So we've got this in-browser simulation, and we can convert. We can go right from a Haskell embedded contract through to pure Marlowe and then through to an interaction. Good. But I think the thing we're most excited about is that one great thing about... When it was announced there was going to be Plutus Fest, it's surprising how much a deadline moves the project on. I think both the Marlowe project and the Plutus project. There's been a lot of checking in on the repositories in the last few weeks. So what we have on the mock chain, this simulation of the Cardano settlement layer, is that we have a single Plutus script that will run every Marlowe contract. That's running on UTXO. That's a real stripped-down. It's an extended UTXO. It's stronger than Bitcoin, but it's way simpler than Ethereum. You know, you don't have all these processes and, you know, potential race conditions and everything else. It's a very simple, functional model. And what we have is this contract language running on that. And as I say, it checks that the contract does all it should, and it checks that it doesn't do anything else. And it's been... It's the most complicated Plutus program so far, because it's effectively a universal machine for this small language. We can do some analysis. We can ask questions like, these contracts are all finite. As you probably guessed, because we have time-outs, we can ensure that the behavior that each contract has is finite. And that's, I think, no due diligence would allow a financial institution to issue things that weren't finite. I mean, there's quite... There's a lot of restrictions on what sort of financial instruments can be produced, perhaps not enough in the light of what happened ten years ago. But the fact a financial contract should be finite is something we can take for granted. So we're able to do... But they may be big. We're able to do analyses using automated techniques like SMT solving to check whether a contract can do something bad, for example. Can it make a fail-a action? And so doing that checking, we can guarantee that nothing bad happens. Working programs, what are we thinking about? We're thinking about what templates can we produce? What do traditional financial contracts look like when we put them into Marlowe? When we put them onto blockchain with the restrictions that we've designed into the language. And we're very pleased to be working with business analysts, because it's not something that we... This isn't something that we can do as programming language researchers. It's not our... It's a way out of our comfort zone, but we will be working with people to make sure that we get the right set of contracts running on... templates for contracts running on Cardano. We need to think, and this is one of the things that will be happening in the Plutus world as well as the Marlowe world, we have to think about how to charge for running a contract. What sort of charge do we make? Do we make it simpler if somebody uses a template which is already on the blockchain? What happens if people use libraries that are already on the blockchain? There's an interesting set of questions around how you shape behavior of users by the way you charge for executing contracts. We need to think about that. We need to think about syntax. We can write contracts in this format. So Alex has been working, one of the teams has been working on this. It's a parenthesis-free syntax, which there will be certain programming communities who will be happier to see this than one which is parenthesis-heavy. Sorry? Possibly. This looks like Ruby to me in regard... But let's not argue about contrary syntax. It's always a good thing to argue about. We've added one or two constructs to the language that I've shown you. We've added a simple version of a while loop, which complements the when and just some things that allow us to write simple definitions within Marlowe itself. We need to think about the design, how much of Haskell do we want to suck inside Marlowe? How much are we going to leave as part of the embedding? That's a bit of work we need to think about. We're working on formalizing the semantics of this. Pablo's doing a long way towards having a formalization of what's going on and proving results in that formalization. So not only can we say... The analysis I was talking about earlier would say for this contract, can it generate a failed pay action? What we can do if we use theorem proving is we can say all these contracts, all this class of contracts will have this good property. And also we need to think... There are questions about how we... This was something Phil showed. There are two components to compiling a contract. We've done the difficult bit of putting the on-chain, getting the on-chain code to work, but we need to complete the work on wallets. And also there are questions about, as contracts get bigger, this is something Agilos alluded to earlier, there are questions about whether we might put some parts of a contract on the main chain, the Cardano SL, but other parts of a contract might sit on a side chain running Cardano CL. So these are all questions which remain to be resolved. Thinking about, I said this earlier, adding commitments and timeouts automatically, trying to find default ways of doing that. And completing that integration with Cardano SL. I think I'm overrunning my time, so I'm going to, whoa, oh, that's the trouble with cutting and pasting, that wasn't meant to happen. You might ask the question, why is it called Marlowe? And I thought I would answer that question. Christopher Marlowe is a very famous playwright. He's from Canterbury, as is the language. And he was somebody who died young. He lasted nearly 30 years. If Marlowe lasts 30 years, I'll be happy. But he was also somebody who was entrusted, he was a playwright, but also a spy for Queen Elizabeth I. So he was someone who was entrusted with valuable secrets. So we thought, Marlowe's a thing that was made in Canterbury and you will entrust perhaps with your valuables at some point, so hence the name. To conclude, this is what we've done. We've got a user-focused DSL. We can provide analyses. We can provide guarantees via formal proof. We can do smart user interfaces. And I think as a final point, I'd make the point that we see it as a proof of concept for other DSLs. We've shown the model that you can, we've shown that we can work successfully with a model where we run these in a very lean way. We have a single Plutus contract that executes all the Marlowe contracts. Of course, we might. It might be better to compile, sing individual Marlowe contracts than something else to look at. But we can see this as a proof of concept for other DSLs. I think the nice thing about DSLs is that you don't have to do everything. So I think what we've done is explore a design space here. We've learnt some general things, but there might be other languages. Do you want to build a DSL for games, for example? That would require other components like committing to values, secretly committing to a value. And you could build a DSL to do that. We see there's lots of scope for doing interesting things in this area. And I don't think we're not at all wedded to doing it all in one language. The more we have, the more we have the better. So I think on that point, and this has worked, I've said this already about what we're thinking about for the future. So I think on that point, I will conclude. Thank you very much. Yeah, I was looking at the GitHub repo because I was going to throw it into our app generator for fun before coming. Right. And it's like 80 megabytes for JavaScript files. Right. I'm just curious where all that weight's coming from. The thing that didn't work, let me go back and make that work. What we're doing is we're running the Glasgow Haskell compiler inside a browser. Oh, sorry. We're running the Glasgow Haskell compiler inside the browser. So we have a JavaScript. We're running GHC inside GHC.js. Yes? Faye. Faye. But yeah, so that's what we're doing. So it's the embedded editor in Meadow that is doing that. We made a design decision in building Meadow that we didn't want to require people to download anything. But in practice, I think what may well happen is if you're using Haskell heavily as the language in which Marlowe is embedded, what you will do is just do your development in your ordinary Haskell environment. So you don't need to do the conversion from embedded Marlowe to pure Marlowe inside the browser. And that will strip out a whole lot of stuff. So that's the short answer. Is WebAssembly going to be on the radar for dealing with that issue specifically? I think you'll need to talk to people this afternoon. I mean, I know because we have, because IOHK used Haskell heavily, I think there is some thought about trying to put investment into the GHC.js community. But I know there's also, there are also people looking at compiling Haskell's WebAssembly. And that could be, and I think the Ethereum people are using WebAssembly for a future. I think I heard the gossip to that effect. So it may well be that WebAssembly becomes a big thing in this space, yeah. Okay, yes, one more. So you said you have Marlowe interpreter as a putus smart contract. Is there any intention, at least right now from IOHK to have the ability to write a Marlowe smart contract and then have that compile the putus? Yes, yeah, that's something that we'll think about. But given this, the Plutus Fest was coming up, we thought the quickest way to get it working is to have the interpreter. I don't see any reason, yeah, I think we'll try that. I mean, I don't know how it will compare in terms of efficiency or size or... I mean, because again, there are these, and this technology we've not really thought about. There's a question about how long contracts live on the blockchain. And it may be that if you compile them, they can live for a shorter period. I don't know. But I think there's a whole set of questions about the engineering of this that we've not quite... Yeah, yeah. There are no firm dates in here, but there will be a lot... We hope there'll be a lot more by mid-2019. But I was told, make no promises about timelines ever, and particularly not in public. So... Right, okay. But 2019, a lot can happen in a year. Thank you for the presentation. I'm working for an IT company, and we have a bank that has clients. But I would like to know, who are the clients for Marlowe? Is it an analyst, or you compare it to people who code with Excel? But do you think it's for the same type of client? I think there are two questions in there. I think the intention is that it's for people who are not coders. But I think in terms of specific business areas, I think that's something that we're exploring over the next few months. Because I think it's easy to say, blockchain is a solution. What's the problem? And I think it's a matter of finding what sorts of contracts will... It will make sense to look at in this way. So I think I don't have an answer to that. What we've been looking at is ensuring that we can provide a variety of contracts to people. So it's a further vision? It's a... We're working with business analysts that IOHK have employed to develop particular markets, to look at particular markets where this will be applicable. And then I think that will help us focus what we're doing. Yeah. So in a sense, it was speculative. It was technology... We've done a technology-driven development so far. We've got the technology. Now is the time to have a bit of business pull, I think. And when you are going to develop the business stuff, is there a partnership that's going to be... I can't comment on that. I don't know. Just because I'm not... I do the research here. I'm sure there are opportunities for partnering. Okay. Yeah. Oh, okay. Gerard says yes. Okay. Good.