 Okay, so I'm now going to talk a little bit more about the nuts and bolts of what's going on, and so that's going to require maybe showing a little bit more code than we've seen so far. But my goal here is to get us to the point of showing you something that actually is running and thus maybe convince you that this is not in fact complete vaporware, which is always a risk in this sector. So why are and the thing I'm going to show you is called Plutus Playgrounds. Plutus is going to be a nice little online environment that we can use to demo some simple things at this stage. And that after all is the point. Why are we here? What is the point of all of this stuff that we witter on about constantly blockchains, ledgers, blah, blah, blah, blah, blah, blah, blah, we want to actually write something, write a contract, write something that does something useful. And unless we can do that, then everything's vanity, right? So that's what we're going to try to do today. And what I'm going to show you is actually live on the Internet today, so ULock can even do something which is extremely risky. Who knows what you might do. So Plutus Playground is an environment for writing and testing smart contracts written on the Plutus platform, which is our platform for doing smart contracts. What does that all mean? It's all right. I'll explain. So to begin with, before we go a bit further, since this is occurring slightly out of context, I'm going to do a little bit of an overview again of what Cardano's ledger technology looks like, because we're going to be, Marlowe is very nice. It's very high level. It's very independent of how a lot of it is actually implemented. That is not true for Plutus. We're actually going to be thinking about the details of how these things stick together. So we need to know what the model looks like. So you've seen this picture several times already. This is our picture of a graph. And in this case, it is a UTX O-Graph, which is this unpronounceable acronym that means unspent transaction outputs. So now this is an old idea. So Bitcoin uses this model. And what is it? Well, you think of a transaction, which is one of these rectangular blocks here, and the transaction has some inputs. It spends some things, and it has some outputs, which are the black lines, which are things that come out of it, which then kind of dangle around until somebody else spends them. And this is then the fundamental concept of how the ledger works, is then joining up these pieces and the money flows along the lines, all fairly understandable. And this then got somewhat became less popular. So Ethereum, which is obviously a big deal nowadays, doesn't use this model at all. Instead, they model people's accounts directly. So here, in this model, who owns? What do you own? Well, you have to go and look at all the black outputs that are lying around and work out which ones you own, and then that tells you how much money you have. And the Ethereum model instead, that's just kind of the primitive state of the system is who owns what. Now, the disadvantage of that is that, well, it's very imperative. We have this big state, which is the state of the whole world and everybody's accounts. And every time something happens, we have to shuffle things across from one place to the other. Whereas actually, the UTXM model, it's quite nice and functional. It's just a data flow graph. You know, we just have inputs and outputs to join them up. Everything's local. You look at one transaction. You need to look at its inputs and outputs. You know it doesn't do anything to anything else. So that's nice. We like that. Simon already did the functional programming RA bit, so I'm not going to do that again. But we like functional program. We like immutable models. We like things that are reasoning to be local. That's nice. In addition, we can still model things that are stateful. It's just that in the Ethereum model where you change the state of something directly, here it's more the case that we need to kind of keep track of our state as we go and pass along, which is often how we deal with state in a functional programming world. And we get quite a powerful notion of programming here. So again, we're still using at base the model that Ethereum uses for how to actually inject some logic into this simple model of transactions, which is that these circles on the graph where a black edge meets a red edge. What happens there? Well, the answer that we give is that the black edge is allowed to be locked. You can think of it as just having a lock on it, and we call that the validator. And then not to spend it, the red edge has to provide a redeemer, which is like a key. And what you do is you give the redeemer to the validator, which is a function. And if the validator says, yep, looks good to me, then you're allowed to spend the money. Otherwise, you're not. So this is in some ways a very simple, simple model again. It's all very local. All the action happens in that circle. But you can still do quite a lot with it, really. This very simple kind of lock and key mechanism. And we extend that model a little bit. I'm going to explain a little bit about that now because it's somewhat important. So we're going to focus in on, again, on this little dot here, which is where the action happens. So as I said, the output that you're using gets locked by validator. The input unlocks it with a redeemer. And then there's some additional data that we pass along. So as it is, these things are just kind of floating in the void. They could be anywhere in the ledger. They have no notion of what's happening, time, space, whatever. The redeemer contains some information. But we add two things. One is that on the outgoing edge, so along with the validator, we also allow you to keep a bit of state as well. So you keep some data. Why do we do this? There are a number of reasons, but the most important reason is to make it easier to write these kind of state passing models, to model your contract as a state machine or something like that. And then it's very natural to have the validator tell you how to transition and the data script tell you what the state is. We will not show you an example of that yet in this instance, but it turns out to be important. And in addition, we also pass in some information about the transaction that is spending the output. So that means the validator gets access not only to the sort of the red edge, but to the whole block that's consuming it. And this is very important because it allows you to set some conditions on how your money is spent. So it's no longer enough. Discussion? Yes. No. Sorry. It gets access to, it can see the transaction that is spending it. So you get to see, for example, so suppose you lock your money with a lock and you're like, okay, that's great. That's fine. But I don't want anybody to send my money to the mafia or something. And then I come along and say, ah, I will unlock it. And then I send the money to the mafia. Oh, no. Instead, we actually get to have a look at the whole transaction and you can make sure that it continues to behave in the way that you expected to behave, not just that it provides a particular piece of evidence. Okay. Yes. Arrows saying what I just said. Okay. So that's a little bit about the ledger. I now want to say something about the anatomy of a smart contract or more generally a program that wants to interact with a ledger that looks like this. So first of all, I've said a little bit about a transaction already. So transactions have these things in them, these validators, these redeemers, these data scripts. What are they? They're code. And I haven't told you what sort of code it is, but I will now tell you that this is code written in Plutus Core, which is a language that we've designed. And you can kind of think of that as like the assembly language of the Cardano blockchain. So it's not something that you're going to write as a human. It's a thing that you are going to, a computer is going to compile your nice, beautiful, readable code into incomprehensible nonsense that will live on the blockchain. And I'm going to denote that stuff in purple. And we sometimes refer to this as on-chain code for the obvious reason that it's what actually runs on the blockchain and makes sure that no one is cheating. Often then, there's some code that runs off the chain, often in a wallet, which is a piece of software run by a user. And so therefore is often acting as a proxy for the user. It's their agents. And this will be a piece of software that actually arranges for transactions to be submitted and listens for events and does things. So it acts as their agent and an intermediary between the slightly, the actual specifics of putting things on the blockchain and what the user actually asks to do. So then the user can interact with that directly. So they maybe will present them some buttons that say, would you like to do this or this or this has happened. And that's where they actually come in. And so this code that exists in the wallet is also very important. It's kind of the other half of the system. If we think about when you might write a web app, you often have a similar scenario where you have some code that runs on your server and some code that runs on the client. And they're actually very coupled together because they need to exchange data between each other. The sort of user flow really passes between them. And you need to think about those in the same terms. And you have the same problem that you often do when you're writing web apps, which is that it's very easy to end up writing these things in different languages and completely different build systems and have them completely out of sync. So the system, if you write Ethereum smart contracts today, is that the off-chain code is usually written in JavaScript. And the on-chain code is written in Soledsee. And the two then need to talk to each other. And there's no sharing between those at all. And so this is one of the things that we're trying to ameliorate with the Putus platform here. So our goal is to say, let's just write the two things in the same language. And that doesn't sound so, I mean, I made it sound like an obvious thing to do, but it's not maybe not as obvious as it sounds initially. So we're going to write both the on-chain code, the code that goes actually on the blockchain and the off-chain code, the code that the user is going to run on their computer in a wallet, in the same language, in this case it's Haskell, and even in the same file. And this gives us a number of benefits. So one of them is that it's easy to share logic between the two systems, which can be important. And we can do even better that. We can actually share the types between the two programs. So that means that if you aren't a fan of static types and functional programming, you may not feel the warm glow inside you that that statement might have, I would hope to elicit that statement. But trust me, this is a good thing. It means that we can just, we don't have to worry so much about exchanging data between the two, we just, we are sure that we're talking about the same thing in both cases. And we can also run exactly the same code, both on the real Cardano blockchain, on the Plutus playground, and also on a local emulator of the blockchain, which Simon was referring to earlier, which has the advantage of not needing to run all the stuff that you need to run to run Cardano for real. So let's just dig in a little bit closer into that block, into that previous slide. So as well as the, actually, I should just say one other thing. How do we do this? How do we write our stuff in the same language? Didn't I just tell you that we were writing Haskell and all the stuff that goes on the blockchain is in Plutus Core? I did, and that was true. So what we do is we compile Haskell into Plutus Core, which I thought was a terrible idea to begin with, but actually worked surprisingly well. And, but this is all fairly transparent to you as the user. We'll, as we'll see in a minute, all of the code looks, just looks like Haskell. Some of it is in a slightly specially delineated block, which is going to be compiled into, into Plutus Core for you. But, and I'm refraining from using the word metaprogramming because metaprogramming is a scary word, but that's what's happening. I would prefer to just think of it as writing everything in the same language. So let's, let's just expand that orange box a little bit. So we have to make, we have to, what are we actually going to write? We're going to write, we're going to write a program that runs on the user's computer and it's going to produce some transactions and the transactions have got to contain Plutus Core code. So we're going to write a chunk of code, this transaction block, that we're actually going to compile into Plutus Core. Okay, fine. And then we'll shove that into transactions and put it onto the, onto the blockchain. Okay, fine. So far, so good. Um, but this is, you know, we also want to change the transactions that we make. We don't just want to, it's no good if you can only make one transaction that's paid $10 to Alice and then you can make the same transaction to pay $10 to Alice again. No, you want to be able to pay $15 to Alice or maybe $10 to Bob. So we want to not only be able to have a static, a static piece of code that implements the logic of our transaction, we also want to parameterize that. But that means we need to pass some information into these, into these, this bit of contract code at runtime because this might depend on what the user says to us. The user might say pay Bob or pay Alice and we need to react to that and produce a different transaction. Um, and, uh, again, I'm mostly telling you about this problem to tell you that it's not a problem, uh, which is that it, we in fact make it easy for you to, um, uh, just write your transaction block as a function that takes an argument, say who to pay. And then at runtime, you just magically lift the person into, uh, put a score and apply the one to the other and get what you want. Um, but we will see an example of doing this in the real thing. Uh, and I want to say a little bit more about, uh, validation. I in fact said most of this before, but I just want to go over it once again, because, um, depending on how far we get through the demo, uh, how much time have I got? Keep going. Okay, good. Um, depending how far we get through the demo, we may or may not need to know about all of this, but let's talk about it a little bit first. Anyway, as a reminder, how does validation work? Remember, this is the thing that happens in the circle that tells us whether or not we're allowed to spend the money. So the black edge, the transaction output has the validator, the lock on it. It also has the data script on it. Okay. The spending transaction, the red edge has the redeemer script. That's the key on it. We also pass in some validation information about the transaction. Remember that's telling us whether we're sending our money to the mafia. And that is computed by the slot leader. That's the, uh, Cardano name for the corner to the person who's actually running this, running this, all of that stuff is glued together in via the magical technique we call function application. The validator is simply a function. We just feed it all these things as arguments. We check whether that evaluates. If it does, you can spend the money. If it doesn't reject it. That's the model. Why not one function? So when I say it has access to the transaction, how does the validator script get access to transaction? It's just a function. You have to pass it in. So the way that we give the validator, which is the main logic access to additional information is by giving it extra arguments. So that's what's in the validation info. And that can only be computed by the slot leader, because that's when they know, say, um, the current slot height or where the money's going. Um, so you can't just write your function and say, uh, and now tell me what's happening. Someone has to give that to you. Uh, sorry, uh, that's basically what this is. That's what the validator is. Um, so it's a little bit more complicated, but the thing is we have several agents here with several people in play. So the, the people, the person who's locked the transaction, the person who's unlocking the transaction, not necessarily the same person. So, um, we have to, and they don't necessarily all have the same information. Um, so, uh, the, uh, the, the validator script certainly needs to be, needs to be given the evidence that you're allowed to use it, which is goes in the redeemer script. It also wants to see the information about the transaction, but it can't trust you to give it that, right? You could lie in the redeemer script unless you could, unless we've got some way of, of, of ensuring that you're not lying, it doesn't know. So, um, and that, that information comes from someone else. In this case, the person who's actually validating the transaction, we can check later that then other people, when other people validate the block, they can check that they weren't cheating. Um, so, uh, there is additional complexity. Um, but I think most of it is due to the fact that we have different agents in here with differing trust relationships between each other. But ultimately the, the, the, the fundamental structure is that the validator gets some information and says, yes or no, that's the model. Um, it's just that some of the information comes from different places. Yes. So as I said before, this model is, is obviously descended from Bitcoin. Um, you could ditch this, all this validation info and say, instead, you have magic functions that tell you this, this information. Um, and as to why we don't do that, uh, this way our language is simpler. You don't need your special op codes, your special support in the language because how'd you get the information? It's just a function argument. There's nothing magic about it. Um, and we can, and the smaller our language, this is, I, I didn't haven't really talked much about the design of Plutus Co, Co, Plutus Co so far, but our goal here is really to make it as small and as well studied and as standard as possible so that there are no nasty surprises and the proofs are easy and we don't accidentally find out later that everything is broken. So, and also, so we don't have to change it because let me tell you, changing these things once it's on the blockchain and everything depends on it and all the stuff is written in this language, absolute nightmare. So ideally we do it right the first time and then we never change anything ever again. Um, yeah, but, but that means that this things like this where we externalize, um, externalize the information and we say, well, it's, it's, it's not our problem. We say this, this, this, the, the language doesn't need to know about, um, the fact that there are transactions and transactions have inputs, that's not something the language cares about. There's no op codes for that. It's just information that a particular function is given. Okay. Um, so there are four main classes of interaction that you're going to care about while you're doing this stuff and conveniently these correspond to four Haskell modules that provide you with the functions to do that, which we will see in a second. Um, we're about to get the point where I show you some Haskell. Um, if you don't know any Haskell, um, good luck. I will try and make it as clear as possible, but, uh, I told you it was going to be nuts and bolts and I meant it. Um, so the first interaction is between your off chain codes. Remember, this is the stuff the user actually interacts with, uh, and the wallet itself. Well, what does this mean? Well, the wallet is going to provide you with the ability to do a bunch of stuff. You know, you might say, I'd like to submit a transaction now. Okay. Off you go. Go do that. Or I would like to look at the user's, the user's key pair. Okay. You can do that. So that stuff happens there. Um, you might also want to, uh, create transactions. That and deal with deal with things relating to transactions. And we talk, put that in the, the module called ledger. Um, and then there's a bit where you want to actually generate the on chain code itself. Um, and, uh, the, we refer to these special blocks of Haskell, which are just Haskell, but they get compiled into Plutus core. We refer to that. Those is Plutus TX, TX is for transaction. Um, and the code relating to that lives in the Plutus TX module. Um, and finally, it's actually, we get to, um, share some code with the slot leader. So remember, there's a validation info I was talking about. Um, we get exactly the same benefit I was talking about before when I said, well, we can share the types and so we know that everything's going to line up or we're not going to make any mistakes. Um, well, in the same way here again, we have an interaction between two pieces of code, one that you're writing, which is expecting to consume some information in a particular format and one that's being, uh, that's, that's, that's, that's, that's being executed by someone on a machine far away where they're going to actually produce this information and give it to you. A jolly well better lineup. Otherwise, uh, otherwise bad things are going to happen. Fortunately, it's exactly the same code. So it will. Um, and that is a legend of validation. Okay. Let me show you some actual real things. Um, so this is the Plutus Playground. Um, you can see the URL at the top. That's a public URL. You can go and look at it if you like. Um, it comes with a number of examples over here. So the one I'm going to show you, uh, now is an example of a simple crowdfunding contract. There's also one that implements, uh, so the simplest one is one that implements a sort of guessing game. And, uh, there's one that does, just shows you how to do some logging and another one that implements a vesting scheme. But the crowdfunding one is kind of a, kind of a nice middle ground of complexity. Um, you can also see there's a tutorial and some links to the API documentation. Um, and, uh, if you happen to write your own beautifully crafted contract and you don't lose it forever, you can now save them into guests on GitHub, which is, is, is quite nice actually. Um, and, uh, this will also be getting a bit of a facelift. This UI will, um, will be, uh, before the summit, but this is, this is a slightly older version, but it works. So it will do. So here we have a text box full of Haskell code. Um, and a threatening looking compile button, um, uh, which is going to compile, compile my code and it's going to compile because I'm not going to edit it, but it will in fact be compiled and checked. So if you do make any mistakes, the compiler will give you a hand. Um, but let's just have a look through, uh, what there, enough of what there is here that I can actually show you it running and then I'll explain what happened. So one of the key pieces of data here as well. So what actually, what actually happens in a crowdfunding campaign, is this legible by the way? Should I increase the font size? Increase the font size. Sadly, the color scheme is under the control of the IOHK design team and, uh, not something I can change on, on the fly. Um, is that legible? Yes. Okay. So here we have Haskell data type that defines, that gives us kind of the specification of a particular crowdfunding campaign. So, uh, a crowdfunding campaign conceptually is a setup where I say I'm trying to raise some money and then you send me money. And if it reaches the threshold, I get to keep the money. And if it doesn't reach the threshold by some deadline, you will get your money back. Okay. So we have a deadline unsurprisingly. So this is the date by which we have to meet the target. Um, and we're using block height or in fact in the newer versions, this is actually the slot height because in the Cardano chain slots actually occur at a specific frequency. So it's a much better proxy for time. Um, so that's the date by which we have to meet the target. We have a target, which is how much money we want to raise. We have a deadline, uh, by which, um, the owner has to collect the funds. So remember what Simon said about not, not having things people be able to walk away. Um, so we're not writing this in Marlowe. So we're not forced to make good decisions, but here we're, we're saying, ah, well, if you meet the threshold and then decide not to take the money, something should happen. It shouldn't just stay there locked up forever. And then finally we have a public key, which identifies the owner of the campaign. So this is the person who's actually going to get to get to, um, take the money out. Um, okay. So that's enough. And now I'm going to show you, uh, so I compiled that it's successfully compiled. Hooray. Um, and we now have another little section. Uh, so this section here allows us to add some agents into this system in our, in our current parlance, an agent is identical with a wallet. Um, so they're, they're wallets. Um, and they have some funds available to themselves and they also have some actions they can take. And these are derived from the Haskell code. And I'll show you how that happens in a bit. Um, so, uh, let's start doing something. So to begin with, I need to do, um, oops. All of these actions are going to be parameterized by a campaign. The campaign is what identifies this script. If you have, if you pay to a different campaign, that's just a different thing. That's a different thing. So let's say, what should we say? Okay. So let's say that the campaign ends at block height 10. The target is to get five money. The collection deadline is 12, I guess. And the owner is wallet number one, the lucky owner. Uh, so he is going to initiate, initiate that. And then wallet number two is generously going to contribute some money. These parameters all need to be the same. Uh, one would not, this is the sort of thing that would be hidden for one by an actual wallet rather than, uh, this UI. Um, and wallet generously going to, going to, going to contribute, uh, five, uh, five eight at that. Uh, and then we're going to wait, um, until the deadline of the campaign. So 10 blocks. Uh, and now we can see what would actually happen if we did that. And this is going to give us the following, uh, rather beautiful, if somewhat difficult to interpret. Sankey diagram. Um, so let's, let's skip all that and go back to the, to the, to the, to the, to the real, the useful information at this point, which is that we can see that at the end, wallet one has 15 ADA and wallet two has five ADA. Ah, money has been transferred. Success. Okay. Okay. Okay. So let's seem to work. Okay. Let's, let's try this again. Let's try this again. Let's say, let's suppose it doesn't meet the type that doesn't, doesn't meet the deadline. Um, it doesn't meet, doesn't meet the threshold. So we can run that. Oh, ah, yes, wallet one has not, wallet one has not claimed their refund. That's, that's a mistake. Where's the refund action? Hmm. Pass. I'm going to skip that because I can't remember how to make sure it does. It takes its refund. But in any rate, wallet one has certainly not got the money. In this case, wallet two has failed to claim their money back, but they probably should possibly I need to make it run for longer. Maybe if I make it run until after that second threshold, that's what I need to do. This is what happens when you improvise additional things in your demo. Don't do it. Um, there we go. Okay. Good. Once the collection deadline passes, indeed, wallet two claims their money back. And if we look at this Sanky diagram, we can in fact see what's going on. So this here is wallet one and getting, I mean, I say we can see what's going on. This is one of the bit scheduled for a facelift. It's, uh, you kind of have to know what's happening beforehand to understand it. This is wallet one, getting their initial chunk of 10 ADA. This is wallet two, getting their initial chunk of 10 ADA. This is them locking away their four ADA that they contribute into the script address. And this is them getting it back again. And this is the change, uh, of one ADA from the, from that first action. And you can see a bit more of a log of, uh, of what happened here. Uh, so here we can see that, uh, uh, wallet two submitting contribution and then claiming their refund a bit later. Okay. So you can, you can, you can, you can set up the actions and you can make it happen. You can check that you haven't made a terrible mistake and implemented completely the wrong thing. Um, and that evaluation there, oh question. Yep. Very good point. Yes. So I didn't put any actions in for either the owner or the contributors, uh, taking the money out of the contract. So, uh, one of the facilities that our wallet API, uh, gives you is that, um, you can register triggers, um, to, so you can wait for particular conditions to obtain and then do something. Uh, and in particular, you probably don't want to wait for user interaction to claim the money back because there's these, there's these timeouts. And if you, if you miss the threshold, then you, uh, you, you might lose your money. So instead, when you make a contribution, it also tells the wallet, wait for the deadline and if the money hasn't been claimed, then claim my money back. And that then happens automatically. Um, the moment your wallet finds out that that's happened, you could implement it so that everybody had to do all that manually. Uh, but that's just, that's just more error prone. And this one, this, this, this, this implementation does the version with triggers. Um, you could do one that was manual. Yeah. I mean, that's just, that's just, that's just like real life, right? I mean, if you, if there's these deadlines or timeouts in Marlowe or something and you go offline while the timeout passes sucks to be you, like, so, uh, yeah, if you, if you, uh, if you've got something where there's, there's, there's timeouts and you, you, you need to be online to do something about your timeouts. Of course, if you were doing this for real and you really cared about this, maybe you would have a wallet that runs on a special server that's run by someone who makes sure that it's always up and gets really good access to things so that you never miss any of these windows. Um, if you really cared about, um, about, um, these interactions, uh, but for a casual user who's, who's doing something on there, who runs a wallet on their laptop. Well, no one's going to submit transactions for you unless you ask them to. Okay. Let's have a little look at the meat of the contract, which is the validator script. So there's a bit of ceremony here, which I'm going to completely skim over, um, and just focus on this chunk of stuff here that begins with the magic words, Plutus TX dot compile and some scary symbols, uh, but we don't need to worry about that at the moment. All we need to worry about is the fact that inside here is some normal Haskell, just the same as the Haskell outside, um, that implements implements the validator function. What does the validator function look like? Well, it is a function of three arguments. The first argument is the campaign that tells us all the parameters of the campaign, deadlines and so on. Who, who's who, who the owner is and so on. Lots of information that we need to actually do this properly. The second action is the redeemers. The second argument is the redeemer script that's going to be, that has to be provided by the, uh, by the, um, person who wants to spend, uh, the outputs. Uh, and this is going to be an action of the type campaign action. What is a campaign action? We don't know yet. But it's something that you can do to, to this campaign. Um, the, uh, third value is the, is a public key, um, which is the, uh, the person who provided that input in this case, but that is the data script in this instance. And finally we get this pending TX thing, which is the, the information about the spending transaction that I mentioned. Um, aren't there too many arguments here? I told you there were three things, the, um, redeemer or the data script and the pending transaction, but there's also this campaign. Quite right. Um, uh, hypothetical questioner, um, the first argument, uh, is as I said, we want to parametrize these things so we can not contribute to any campaign, no matter who sets it up or what the parameters are, whereas we don't want this block to be constant. And so up here, we actually apply it to a particular campaign that you, that you choose at runtime, but that's where that comes from. And then this is just some Haskell with comments, but we'll, we'll, we'll skip that. Um, but you can see that in the end we do a little bit, we just do a bit of logic. We try and work out, well, is this a valid spend of the money? Well, uh, what do we need to do for it to be a refund? Um, actually, how much time have I got? Carry on. Okay, good. Um, so, okay, what are things I can do? Turns out the things I can do are get a refund or collect the money. Um, let's look at collect the money that's simpler. Um, so well, if I try and collect it, what has to be true? Uh, well, the time current, the current time has to be past the deadline, uh, the deadline for contributions and before the collection deadline and the total money input has to be greater than target and the transaction that this I'm submitting has to be signed by the campaign owner. If all of that is true, then it seems like the conditions have been met correctly. And, um, that's fine. Um, and we're going to evaluate successfully. Otherwise, we're going to call this error function, but again, don't worry about that. A lot of the details of the actually how to write these this nicely is under evolution. This is still somewhat a, um, early version of the API. In the other case, let's where maybe I'm trying to claim a refund on my money. So remember that's the other case. The other thing that we can do is say the collection deadlines past the owner's gone a wall or the threshold hasn't been met, giving my money back. Um, first of all, we can we write this, um, we write this, this helper function, which I won't look into, which just checks whether a transaction output belongs to us. Um, and so what this condition says is we're past the collection deadline and you're only trying to spend the inputs that you paid and you signed the transaction properly. Um, in that case, you get your money back. Um, and, uh, yeah, that's the validator scripts. Um, and then there's some scaffolding around here, which I think I won't go into because it's not, not terribly interesting, which is providing the functions. So this, this stuff out here is then off chain code. This is the stuff that runs in the user's wallet and it's implementing things like, um, implementing things like, uh, this contribute function. This is something that you a user might click their button and say contribute to this campaign and then this will run and it takes the campaign you want to pay to. It takes the amount of money you want to do and it does some stuff. Um, uh, but it was exactly the same campaign type as you using the validator script and it's all of this is in the same file type checked together should fit together. Um, yes, question. This code is stored on a blockchain. Yes. Yep. Yep. Um, that's part of the deal. Everything's mutable. Yeah. Uh, so remember, this is the validator script. So, uh, so where does it live? Well, it's attached to transaction output. That's, uh, that's, that's where it lives. In fact, it's slightly more complicated than that. In fact, what you put on the transaction output is just the hash of the validator script and it's the, uh, the spending transaction has to provide the actual validator scripts mainly because we want to make them pay for it, um, because it's might be quite large. Yeah, they have to work out how to get that probably by talking to you. They, they didn't just look at this hash and go, ah, yes, I will do a pre-image attack and work out what script has that hash. We don't expect people to do that. This isn't proof of work. No, this is Haskell. This is your high level language. This is going to be compiled into Plutus Core. So that's what actually, so this, this text, this is not stored on the blockchain. This is compiled into, um, something that's stored on the blockchain. And if we look up here, we will see, oh, it's, it's inside here. Inside here is, this is actually a blob of, you know, it's a serialized blob of, of, of assembly language effectively. And that's what actually lives on the blockchain. Otherwise, you'd have to run a Haskell compiler when you validate your, your transactions. And I don't think you want to do that. Yes. It is a, it is a small extension of a strict system f omega with indexed fixed points. And we just store, uh, we store the terms serialized. Yes. No, strict all time. You may rightly think that's a bit weird and you'd be right, but it turns out to not be too weird in practice. It's just Haskells. That's, yeah. Yeah. You could potentially tie yourself in an art with that, but, um, we don't expect anybody to write anything sufficiently complicated that that would matter. But yeah, um, there was a brief period where I accidentally made, uh, case statements strict, so it would always evaluate all the branches. And that was, that was not so good. Uh, I think I could go through more details of this, but I, I, I think we could, let's just go into Q&A. Let's Q&A. And, uh, we've got Simon here as well, just because we want to make sure any piece has arrived. We want to get a few questions in. Simon as well, a few, uh, if you make yourself available. Um, so if we can carry on, just asking a few more questions for the next five or 10 minutes. So, um, and if you don't mind waiting for the microphone to come, if you do put your hand up just so we can make sure it's on the camera. Oh, sorry. I've been irresponsibly taking questions. So that's actually, yes. No, Richard has reminded me before I think we have to stand far away from each other. Before I do this, I am obliged to show you this slide, which says, um, there's going to be an IHK summit, which you've mentioned a few times. Um, it's on the 17th to 18th of April, which is quite soon. It's in Miami. It is going to be exciting. In particular, it's the first time that members of the general public can come to the IHK summit. If that sounds like your kind of thing, uh, you can go on the website and, uh, find out about it. Great. Do we have some questions? Yes, question. So the validator info, that sounds, it sounds like it's something appropriate for regulation or something. It's kind of like an add-on to the validation, right? So it's mostly intended for the person who's writing the validator script to make sure that, um, the person who's, who spends it does the right thing with it. Um, so I didn't go into the, the details, but let me give you a, let me give you a more concrete example that would maybe make it clearer. I mean, when you said the right thing, it kind of, you mentioned it. Yeah, so let me give you an example of the right thing. Yeah. So one thing you might want to do is you might want to implement something a bit like a little state machine with this. So you'd say, like, you know, maybe it just keeps track of how many times someone has tried to use it or something. So the validator script would be, would remain the same. And in the data script, you maybe you keep like just the counter of how many times someone has used this. But in order to make someone sure someone uses this correctly, they have to spend the old output and produce a new output that has the same validator. And they've updated the state appropriately. Now, we need to make sure that the old validator has to check that they do that. Otherwise, who knows what they might do? They might do anything. They might take all the money. That'd be bad. You know, you might want the money to stay locked up until something happens. So sometimes where you have these chains of transactions where things have to keep going. But you don't want to everything to be serialized through a trusted party. You know, you don't want to be the only person who's allowed to update this because, you know, that's tedious and slow and expensive for you and not distributed. So instead, you want to say, sure, anybody can update the state of this. But we're going to make sure that they do it the right way. And so that's what that's one of the things that we get the ability to do is we can actually look at what the the next transaction is doing and make sure it's the right thing. So it's kind of something you could see it as a single transaction but made up of a series of a finite series of transactions. Yes and no. I mean, there's there's interactions going on with people, right? Like it's not one transaction. So it's like it's complicated. OK. But another example of that is if you think back to the the escrow contract, if you did that on Bitcoin with Multisig, Carol and Bob could split the money between them, for example. So Multisig, all it says is these two people have control of that money and they could do whatever they want. What we can do is make sure that when they do that, when they both free it, it goes back to Bob, for example. So we have a much better example. So and that was, I mean, we sort of, I mean, Pablo and I, when we were thinking about Marlowe, that was one of the things we thought we've got to be able to do that. We want that control. And that was a, yeah, I think that's. I gave the overly generic example, which is that this is an example of implementing sort of state machine type stuff, which turns out to be really useful. But we're coming here. It's different different ends of the the same thing. But yeah. Yeah, I have a quick question over here, right over here with my hand up in the middle. Oh, there are several people with their hands up. Sorry. Well, several microphones. That's a trouble. So, so I understand how this applies to crowdfunding, but I also saw you guys have demos on games, vesting and messages. Can you just describe how it applies to vesting? Sure. So the, I won't go through. I'll just explain. So the, what we implement in this example is a scheme where there's some money locked up. So we say, here's some money for you, but you can only have it in chunks and the chunks become available beyond a certain time. So after a certain time. So then the validator is exceptionally simple. It just says, you're trying to take the money. Is it past two o'clock? Fine. You can have this much money. Is it past three o'clock? You can have this much money. So yeah. So it's a very simple, very simple vesting. So yeah. I mean, anything you can talk about on the Cardano chain. Well, it's the issue about fungibility, I guess. Sure. Right. So you wouldn't do it with ADA. You'd, if you were doing some like, like that, if you're tracking assets, you want a non fungible token or something that actually represents the thing. So I guess shares are probably not fungible. Yeah, I know it, yes. Not sure. All right. So do I understand correctly that a contract is an address and then is it possible to upgrade a contract? So the word contract is somewhat overloaded. So a, you can, if you want to lock some money using a script, you effectively pay to the address of that script. And if you're doing the sort of state passing thing that I was describing, then that address is a lot like the address of a contract in the Ethereum world. As for upgrading it, if you upgrade it, it's going to have a different hash, it's going to have a different address. So no, unless you add functionality to do that. So it's, it's, there's no special backdoors built in to help you avoid accidentally putting all your money in a runaway machine that does something stupid. That is still something that you the programmer not need to make mistakes by using Marlowe or something that only lets you do sensible things. I think we hope in future to explore more techniques for using formal methods or similar to try and help people not make that kind of mistake. The other thing you could do is actually build functionality into your contract to allow, allow it to be changed or allow some of its parameters to be changed. But of course you can make mistakes doing that and then you just accidentally let someone else take change all the parameters or something bad. So it's, it's, it's, yeah. But also building libraries, I suspect. So you'll be building and encouraging people to reuse those. What is Marlowe but a very fancy library? Wellington. Yeah, exactly. Yeah. Hi, it's one for Simon. Um, what issues have you had modeling exotics with Marlowe? None because we haven't done it yet. Okay, that sounds great enough. So that's, sorry. Thank you. Just a question with regards to you mentioned or using the allergy with regards to the mafia and then them using the technology for bad things. Where is KYC dealt on? How does it work? Is it in Marlowe or is it in the validator script? I do not believe we are going to solve KYC for you. I'm afraid. So if you, so you could build something that made it easier to do KYC on top of this, you know, you could have systems which would only accept transactions to like addresses that were known to be known to be trusted or something. And you could have someone else update the ledger of trusted people. You could build that sort of system on top of this. This is the plumbing for, for building these systems. If you want to do something where only certain people are allowed to do some things, you have to do that on top of. Sorry. Maybe you missed my question. You said earlier that the validator script can tell if someone's doing bad things. You have to be able to tell me how, you have to be able to write the program that tells whether it's bad. There is no magic bad thing detector, right? Like if you can tell me how to see whether the thing is bad, sure. You can, you can detect whether it's bad and abort the transaction. But if you don't have the information to know whether it's bad, you know, just paying to some public key who knows that it's owned by the mafia. That's not a problem that we're solving for you. Okay, thank you. Okay. We have one more question at the front please. Why is it called Plutus? Plutus is the Greek road. No, I think it's actually Greek. It sounds Lassner. I believe it's in fact Greek. I got, I got, I remember this because it was not black. Yeah, I got that. Okay, fine. I believe it's the Greek God of wealth because, you know, we allow you to lose your money faster than ever before automatically. And we'll cut off there. PR department of the back's going. Cut, cut. Get him off. Excellent. Simon and Michael, thank you. Thank you everyone for your questions. Thank you everyone that joined the live stream as well. We'll be doing more of those. But also to Monzo absolutely for providing the venue and the beer and also to our other sponsors Etoro and KL1 as well. Thank you everyone. We'll be back next month, hopefully with an event around lightning Bitcoin's Lightning Network. But for the rest of the evening go and get more beer. The pizza is here. Go and tuck into it. They look great. Good.