 So tonight, we welcome from Cardano. We're very privileged to have two of the senior team members from IOHK, which is Cardano's research and development arm. And like many of the other kind of platforms, which are finally kind of rolling out their products and services, we're here to hear about Cardano's new development and smart contract development environment. So without further ado, I'll firstly hand over to Professor Simon Thompson, who's going to tell us more. Okay, thanks very much. Good. Well, thank you very much for the invitation. It's good to get a round of applause in before I say anything. That helps. So I'm going to talk about the work that I've been involved with, and my group has been involved with, which is developing a high-level language for financial contracts called Marlowe. But I think I first of all, I should say something just a tiny bit about Cardano in general, just to introduce what I'd be saying and what Michael will be saying saying afterwards. So if you want to characterize Cardano, it's a third generation blockchain. There was Bitcoin as first, Ethereum as second. Third generation in perhaps in stressing two aspects of it. One is that it's based on proof of stake, not proof of work. And the other is that it's based on adding to the main chain, adding a notion of side chains. And there's a currency which lives on Cardano is ADA. I don't want to say a huge amount more about the generalities, but I would like to say a bit about the approach that IOHK has. I mean, I think one, I've been involved with this as an academic, and academics have different reasons for getting involved with industrial development. I mean, it's clearly a very exciting space to be in. But I think one of the reasons that I was very keen and very, very excited to be involved with IOHK is that everything with IOHK has been open right from the start. So all the code for Cardano and all the products we're developing are by default open source. I think other companies are open sourcing parts of their ecosystem, but Cardano has been open source throughout. And as an academic, one of the reasons I get the ways I get prestige, the ways I communicate things is by publication. And again, we've got it's an entirely open publication culture. So that's been a reason for me to be involved with Cardano. And I think also there's a very open community. The Cardano community has worked very hard to build a community around the language and initiatives across the world. There's a Haskell course taking place in Africa. And I think Cardano, the commitment from IOHK to that is something that I've been very pleased to be associated with. So I think that that's a reason for an academic like me to get involved with IOHK. Another reason is that IOHK are committed to using functional programming technology at the heart of their systems. Now, some of us of advanced age here remember the 1980s when functional programming was the big thing. It was going to push general purpose languages out of the way. Well, that didn't quite happen, but it's happening now. We've waited a while, but it's now the platform of choice for building a whole lot of things in this space and in all sorts of, particularly in the financial sector, but across different industry areas. So why does functional fit well with blockchain? I mean, you can see, it's a picture of a transaction-based blockchain there, a schematic. That's like a collection of functions wired together. If you see each block as a function, they have inputs and the outputs flow into inputs of the next function. So the model deep down at the basis is a functional model. What we've been doing, and Michael talked more about this, is taking the UTXO model that exists on Bitcoin and developing that rather than looking at an account-based, heavily stateful model that you get with Ethereum, looking at how you can take the functional model that is in Bitcoin and extend that to give you a more expressive blockchain. And that is what we've got with our extended UTXO model. And I think Michael will talk more as I say about that. Language of choice for IOHK is Haskell, and it's proved to be a very serviceable, very dependable language in which to write. So I think there are no regrets in IOHK about choosing Haskell. And I think partly because it supports what you would call a high-assurance approach to building systems. It gives you clarity. It's a high-level language. You express things at a level where it's easier to understand. The intention behind the code. It's also because the way it handles state, it's easier to reason formally about what the language does. And the approach that's led by Duncan Kootz, who a number of you will know, is to do specification-led development, writing specifications in logic, proving things about those, and then feeding those through into code. I think another approach, another thing that has come out very well from this is we've been able, typically, if you use a language like Solidity, use Solidity plus JavaScript. Your overall contract that's evolving on-chain and off-chain will work in two quite different languages. What we've been able to do is take a single language Haskell and get that to work on and off-chain. We're developing in a single language. That unification. And one thing that comes along with the high assurance that we have in Haskell is that we're able to use high-level approaches to verification. We can use formal proof, but also we can use property-based testing. We can use QuickCheck to assure ourselves as we go along that we're getting the sorts of properties that our code has and properties that we want. So it's not that we just like doing functional programming. It seems like the right tool for the job. So after that broader introduction, let me narrow down and say what we've been doing in the Marlowe team. What we wanted to do, we're not looking at producing a general purpose language. What we wanted to do was look at how we could build a special purpose domain-specific language to support financial contracts on blockchain. What we've done is build this language Marlowe, which runs on top of Plutus, which Michael will talk more about. We've built a simulation environment for that called Meadow. I'll talk about both of those things. I'll talk through the details of the language, what we can do with it, and I'll say what we have now and what our plans are for moving forward. So to step back, if you look at the history of programming, and this is, I don't know how many of you are aware, this is the most, this was the first business computer, I think, in the world. It's the Leo, which was produced for Lyons. And they used this to run a whole lot of their business, from deciding what to put into ovens at various points, to ensuring that what had been produced went to the right shop and so on. So they're running a whole lot of business information systems on this, which was a clone of the computer that had been built in Cambridge in 1940. Now, to program that, you had to use the machine code. You would write code, which was for that machine, for no other machine. And the history, moving on, that would be 1948, so what, 70 years ago. Moving on from that, through the 60s, you saw the rise of high-level languages, like Fortran, Algol. And that was the point where you could begin to see that abstractions were being put on top of that machine code. But typically, you would still write in a version of Fortran, perhaps, that worked only on one computer. The Fortran wasn't, the code wasn't portable between one machine and another, certainly by another manufacturer. But we've moved from there into the sorts of general purpose languages that we use today. But these are still emphatically general purpose languages that express things, admittedly, with a whole layer of abstraction at the level of, they're still programming languages. They're not languages that express things in a particular domain. And we've seen a similar thing if you look at languages on top of blockchain, that we have general purpose languages like Solidity and JavaScript put on top of blockchain. So where Marlowe fits in this particular picture is to say, actually, let's look at the language that the people who use this, who are going to be using this sort of system, what's the language they talk? Can we try and build something that is domain specific that will allow people to express solutions to their problems at the level closer to the level in which they talk themselves informally. So what we wanted to do was look for a domain specific language to talk about financial contract on blockchain. Now because a DSL is specific, it brings a whole lot of advantages. It's the Orwellian idea that the language you use controls the thoughts that you can have. That's a rather negative view of it, but if you view it in a positive way, if you use the right language, a certain class of errors are going to be removed. You simply can't express some things that you shouldn't be expressing in this context. If you're working in a domain specific language, it's easier to write analyses. So you can look at a contract written in a special purpose language and understand more about how it will behave because you're trying to understand something written in a much more constrained domain than any program written in a general purpose language. So we can analyze these programs more easily, we can write more accurate analyses, and we can also build special purpose tools. So there's a good set of reasons for looking at DSLs in this sort of space. And because it's a language, in some ways we can have our cake and eat it. We can say we've got a domain specific language, but we can embed it. We can put it in as part of a general purpose language. So we can start with our DSL and selectively pull in, if we wish, certain parts of the general purpose language. So we can extend it in this sort of ad hoc way. So we get this, we can embed it, as I say. And also because it's a language in itself, we can not just executing it, we can do other things like, for example, for a contract, we can write a valuation of the contract under certain assumptions. Or we can think, well, here's a contract, can we simplify it? Can we keep the same behavior, but can we write a simpler version of it? So we can do a whole lot of things because we have this language for expressing our intentions. So first lesson is, DSL is a good thing. We wanted to look at how they would apply in this particular space. Now financial DSLs are not new. We're coming up to the 20th anniversary of the work by Simon Peyton-Jones and his co-workers looking at describing financial contracts in a functional DSL. And a number of companies and a whole lot of business, a whole lot of people employed on the front row who've been basing their work in the financial sector on precisely this sort of work. So let me just explain, let me run through a simple contract, the sort of thing that we're going to look at. So a simple contract here, Alice wants to buy a cat from Bob, but neither of them trusts the other. It's a sad fact, but that's the way of the world. But luckily they have a friend, mutual friend, called Carol, whom they both trust. And we can describe a contract for escrow that will allow money to be transferred from Alice to Bob, if and only if Alice receives the cat from Bob. And it behaves a bit like this. Alice puts the money into the contract. She's put in 15,000 forints. I don't quite know why they're Hungarian forints, but they are. And she's going to wait for the cat. Now of course she can do the transfer of the money in cyberspace, as it were, but the cat has to be transferred physically. So is the cat going to be transferred? Well, yes, luckily the cat is transferred. At this point, the money can be released. And of course the choice for releasing it is Alice agrees with Bob, sorry, Carol agrees with Bob that the cat has been transferred, and so they agree and the money can be transferred to Bob. So that's one option. Now of course it may not have happened like that. It may be that Alice puts the money into the contract and she waits and waits and waits and waits and waits and the cat doesn't move. I press my clicker and the cat doesn't move. At this point Alice and Carol can agree and say, Carol says, I quite agree you've not got the cat, so the money is returned to Alice. So there's our simple escrow contract and we can express that in this sort of, here's an example of our DSL. And you can see the things in pink are the combinators. These are the things that allow, that build complex contracts from simple ones. What we're able to say here is when a particular condition becomes true, do whatever is in the body of the contract. So when either the majority have chosen to do a refund or the majority have chosen to make a payment, we do whatever is in there. And then we make a choice here according to what happens in that. If the majority have chosen to make a payment, then Alice makes the payment to Bob, otherwise her money is redeemed. So we're able to, using these simple combinations of when something happens, a choice based on an external event, a payment from one person to another, we're able to express that contract. Now it's not the world's most complex contract, but then a lot of contracts aren't. But you can see here what we have is the other fundamentals of our little language. Okay, so there's our example. What I want to do is take a tiny step back and just give you a little bit more context on Cardano and where Marlowe and Plutus, which Michael will talk about, fit. We have the settlement layer. We have the blockchain, if you like, with Plutus running on top. And that we need to think about if we're to write contracts, we need to think about how those interact with the real world, how they interact with time that's passing. You can see we had a when construct in there. We have to think about making payments. So we need to equip our language with ways of talking about the real world, ways of talking about how money is transferred to user wallets. So Marlowe sits on top doing this special purpose role on top of Plutus. And just incidentally, Marlowe is not bound to Plutus. We could get rid of Plutus and put Solidity underneath. We could run this on Ethereum or any other blockchain. The model for Marlowe is sufficiently simple. It will work on an account-based blockchain, but it will also work on this extended UTXO that we have in Cardano. Okay, so we've got our contract. We've got Alice and Bob and Carol. What do we need to do? What do we have to think about if we're taking this world of financial contracts onto blockchain? One thing that we should think about if we're thinking in the extreme about removing enforcement, removing legal enforcement entirely and getting the contract to enforce itself, we need to think about mechanisms for doing that. How can we ensure that the operation of the contract guarantees the execution of the contract on the blockchain, guarantees that we get the behavior we should get? So that's one of the differences between the financial contract model in the abstract and looking at the blockchain. The second is that we can't, in the blockchain context, one of the great things about having a ledger which allows us to track how money is spent is that we can't double spend the money that we've got. Now, of course, the whole basis of the financial system is that we can double spend. I mean, that's what credit is all about. So we have to think there's a separate conversation to be had about how credit underpinning contract fits in with running contracts on blockchain. And I will come back to that a bit later on. So the approach that we take is, I mean, and this is due to Butaren from Ethereum, is to take this dual approach that using cryptography, we're able to make sure that the past is irrefutable. We can't change the past. And I'm not really going to talk about that. I'm simply going to take that for granted. But the other half of this crypto economics view of the world is to say, well, we will also shape future behavior by providing incentives to people. And those incentives are to do two things. And I think this is perhaps something which we only realized when we started designing this language. There are two kinds of behavior we want to avoid. The first is we won't want to avoid bad behavior. We don't want people doing the wrong thing. That's important. But the other sort of thing that we have to avoid is that we can't have people just walk away from a contract or we have to think of actions that will allow us to mitigate that. So we'll come back to this a bit later on. So Marlowe, if you want to think about Marlowe in a nutshell, this is a summary of what we have. We have Marlowe is an embedded domain-specific language, simply embedded as a Haskell data type. So pieces of Haskell data describe Marlowe contract. It's got an executable semantics. So Haskell is a very nice language for describing how the contract evolves step by step. We also have an implementation on the Cardano mock chain. This is a high-fidelity simulator of the Cardano mock chain. So we have Marlowe implemented on top of this extended UTXO model. We have analysis and proof. Oh, we've got work on proving properties of contracts using proof assistants like Coq. We've also got analyses so that we can take a contract and analyze, will this contract lead to a failed payment? So we can guarantee under a certain... If we can look at the contract and say, we can see that this contract will not lead to failed payment. And we have a simulation environment. So to think about what we have to do, excuse me, I have a glass of water, we have to interact with the outside world. And one sort of... Or two sorts of interactions are a contract that is tied to a value of some stock, for example, the price of oil at a certain point, at a certain place. So contracts may well depend on those sorts of values. So we have to think about models for oracles. How do we incorporate values from outside the contract into the execution of a contract? And also we have to think about how another sort of observation, if you like, is choosing a random value. Certain contracts will depend on tossing a coin, on making an arbitrary choice. We need to have sources. We need to think about how we get random values into our contract. Now, really, the state of the art of this, I think, as things stand, there are two ways we can approach it, but they all in the end require that the participants sign off on either on each individual random value or they sign off on sources of random values or sources of data like the oil price. And this is what this participant sign off is something you see in state channels and payment channels and so on. This seems to be the state of the art where we are with interactions. The other thing we have to think about, and this is internal to the operation of Marlowe, is we have to think about how to model commitments. If we're to make contracts enforceable, we have to have some way that people are required to commit money to a contract. Now, a contract can't force me, it can't take money from my pocket, can't take money from my wallet, typically. So how do we model this? What we do is we have a model where a contract can ask from a participant, from somebody, an individual, or a wallet which represents an individual, can ask for a commitment of cash. And we ask for commitment, commitments are always going to be finite. We have to ensure that if you commit money to a contract, you will be able in the end to get that money back if nothing else has happened. So you have an underpinning, it's underwritten that your money will be returned if the contract has not done something else with it. So we can avoid the situation where your money is locked up indefinitely. We have to do that. So that's why we need commitments. Now, of course, if what we're doing is asking people for commitments, we ask them for a commitment for a limited time, but we also just have to wait a limited time in order to ensure that they give that money. Because otherwise, they could lock the contract up by being asked for a commitment and just walking away. So here, we're using timeouts to ensure that we get progress of the contract. The contract's sitting there saying, Simon, give me 100 ADA. It will only do that for a certain time and will have a mitigating action if we get to the end of that time and I haven't made a commitment. So those are the keys to making, to taking the contract, non-blockchain contracts into ones that will work on blockchain. So here's our original escrow contract. If you remember, we had, when a certain condition held, we got a choice based on whether the majority had chosen to make a payment or not. What we do is we enhance that with a timeout on waiting for that action to hold. We will only wait until block time 90. And we will add a mitigation at the end to say, this is what happens if nothing has happened by time 90. This is what we do. So we're making sure that at that time, the whole contract is resolved and complete. What about commitments? Well, we're going to do something just to squeeze that in. We're going to have around that contract, we're going to ask for a commitment here. And this part, this contract forming, this combinator will wait for Alice to make a commitment of 15,000 ADA. And the commitment is only going to be block height 100. So Alice will know the timeout for that contract, timeout for that commitment. It could be reading after that. And we also know here's our timeout to say, only wait until block 10 for that commitment to happen. And if that commitment hasn't happened by block 10, do this. So we've got there, you see how we've taken the contract, which wasn't was was indefinite. And what we've done is turn it into something where now we have this commitment, commitment lasts until a certain time. We've got the when statement is bounded by that time 90. So we know that whatever happens by block height 100, the whole contract is finished, nothing is locked up. Nobody was able to subvert the contract. OK, and we've got some other contracts, which I've thrown in here. We can write a simple futures contract. Here we've got a deposit incentive, if somebody is prepared to deposit money for a certain period, they get back an extra bonus of 20. So let me just let me move on. But what we're doing in general, this is something that we're doing during this year, is working with actors who have a taxonomy of financial contracts. We're working with them to look at expressing in Marlowe templates for all these financial contracts. And you can see what they've done. There's the URL is up there. So they have a description of what they see as the major shape of what they call basic contracts and combined and derivative contract. What we're going to do is build a set of templates for those. And you can see here that they have, I talked earlier about the problem of credit. They've modeled that here in credit enhancement. So we'll be able to think about how this model of enhancing credit, helping contracts to work on blockchain, will fit in with this general picture that the actors organization have produced. So that's something that we're in the process of doing. But we're very excited to be working with them because they will give us the feedback we need to ensure that what we're doing with Marlowe is right, is working properly. So it will help us evolve and enhance the language if that's necessary. It'll also help us see how maybe that some of these contracts will finish up having an aspect written in Plutus. I mean, you can imagine that if you get into exotic options, then maybe there need to be things written at a lower level in using a more general purpose language. But this is what we're targeting at the moment. Now, I said earlier on that we're working with a language that's embedded. And just to explain what that means, all the things you see in this schematic contract I showed you are in fact things that are defined in the language in which Marlowe is embedded. So we could, for example, I can extend that. You can see that we used majority chose pay both in the, in triggering this event and in the choice that we made. I can factor that out and say that pay chosen is defined to be this majority chose pay. So I'm able, without adding much syntactic complication to what Marlowe supports, when Marlowe is a very simple bracketed language as it stands, I'm able to enhance it using, if you like, the capabilities of Haskell to give me some simple abbreviations. And those abbreviations can actually be functions. So I can say I can write the function majority chose x. In fact, that's shorthand for two of Bob, Alice, and Carol have chosen x. So here I'm just pushing out into the general purpose language a bit to give me some abbreviations. And you can see that probably with the actors model we'll be writing libraries, which will be Haskell libraries that will generate Marlowe code. So that's how we use the embedded nature of the language. Let me say, how are we doing for time? Okay, let me say a tiny bit of our implementation and then I'll move on. So the way that we interpret Marlowe is that we have, it runs as a single Plutus program. So what we have is we have an interpreter for Marlowe that runs as a single Plutus program. And we use then the extended UTXO model where we're allowed to pass data from one transaction to another to pass the state of the contract that we have so far. So it's very neat. It's very elegant to push the Plutus, the Marlowe interpreter down as a single program and pass around the state, the evolving contract as data on the blockchain. And again, remember this is a UTXO blockchain, not an account based one. And I think at the moment it's the largest running Plutus program. Is that true still? Buy a large margin. So there we are, but I guess it's bound to be because it's a, we'll measure it and tell you, we'll put it on Twitter. Okay, fine. But what we also have is a browser-based tool, which allows you to step through the execution of Marlowe contract. So in fact, it allows us to end-to-end development. What you can see here is first version of Meadow. You can build Marlowe programs using Blockly, which is a scratch-like environment for building contracts. But you can also build, you can throw up, and this is why it's a prototype, you can throw up an editor for embedded contracts inside the browser. Now, the process of converting those embedded contracts to pure Marlowe at the moment involves running a Haskell compiler in the browser. So as you can imagine, that is pretty slow. But for the upcoming IOHK summit, which is happening in mid-April, we've got an all-singing, all-dancing new version of Meadow coming, which will do all this in the cloud. So it will do the compilation in the cloud, and it will clean up what is admittedly a slightly cluttered user interface. But just to give you a summary of what we can do, we can develop an embedded contract, so using the Haskell embedding, turn it into a pure Marlowe contract, and then we can simulate it, and you can simulate it in an intelligent way. So at each stage in the evolution of the contract, you could poke it in different ways. You could pass in an observation about the oil price, or you could pass in an input from one of the participants. What the smart input facility, which you'd see down there, allows you to do is select from the inputs which will actually make the contract evolve. Because we're working in a... And again, this is because we're working in a DSL, we're able to analyze... It's easier for us to see what the contract is waiting for, so we can feed that in as input. If you're wanting to find out more about Marlowe, about Meadow, there's a video on our website which you can download, on the website which I show you as the final slide. So the video that runs you through the facilities of Meadow. And it has lots of other links as well, which would be useful. But that's our browser-based tool. We can do some analysis. So I talked about that, that we can answer the question, will this contract possibly produce a failed payment? And that's obviously something we don't want to happen. Is it possible to see this contract leading to people trying to redeem a commitment? We can check that. And also, we're in the process of not just analyzing individual contracts, but analyzing the whole class of contracts. So using theorem-proving technology to allow us to establish properties of whole classes of contracts. So what we have is a formalization of Marlowe inside the Coq theorem prover. And we're able to prove stuff inside there. And this is a piece of proof, admittedly not the world's most readable proof, but it's a piece of proof nonetheless. So we're able to do that. And that, of course, gives you the assurance that the contract will behave as you would like it to. Why is it called Marlowe? It's named after Christopher Marlowe. Anything that gets invented in Canterbury gets called either Chaucer or Marlowe. So I thought I'd go for Christopher Marlowe. He's invented in Canterbury, which is where the University of Kent, where I'm based, is based. And also, he was very good at keeping secrets. He was very good at keeping things secure. He was a spy until he was killed in a pub brawl age 29. So I'm hoping that if Marlowe lives for 29 years, I'd be happy. In the life of programming languages, that's pretty good. For the future, we'll be deploying Marlowe on the Cardano blockchain. We'll be developing the full set of templates, as I explained. We'll be putting Meadow in the cloud. And we'll be thinking about how to, in various ways, I think it's clear that we will be thinking about how the language will evolve as we're doing this work on building these templates. And finally, you can see, I explained that Marlowe has a, it's an interpreter. We're running on the blockchain, so you feed it a contract and it will execute it. Of course, one specific thing we should think about is writing a compiler. So you take a contract and turn it into Plutus code. In a sense, we've done the general thing. We've got the universal Marlowe program, which is the interpreter that runs everything else. But we can think of compiling individual contracts. Okay, so that's a summary of what I've talked about. So I think that's enough. That's a picture of the team. And there is the, this is where you can get to all the resources I talked about. We're on GitHub, as I say, IOHK puts its stuff on GitHub. There you can find a paper about Marlowe. You can find a video about Meadow. You can find examples. And you can find the system itself. So I think I will, at that point, stop.