 Alright, here we go. So I am very happy to be talking to you here because Jan and I get the envious role of being Father Christmas in this conference in that we get to actually show you the real deal. So far, we've heard lots of people telling you lots of nice things about programming languages and theory and all this stuff. But at this point maybe it's all vaporware, you don't know. I'm here to tell you it is not vaporware. And also to do something extremely dangerous which is tell you a lot how to actually do something. And more than that we're actually going to do some of that live in front of you. And this is the point at which I'm struck down by the god of demos for my hubris. But let's see how far we get before the lightning strikes. So today what we're going to talk to you about is the Plutus Playground. And the point of the Plutus Playground is well why are we here? What is the point of this conference? All of this infrastructure that we're building up? Well at the end of the day we want to actually write some smart contracts. We want to do something with this system that we've been building. And the Plutus Playground is here to help you do exactly that. So it's an environment for writing and testing smart contracts in your browser. You don't have to install any fiddly dependencies unless you want to. And so it's a bit like remix in the Ethereum world if you've seen that. And that's what we're going to be showing you today. And you can go all the way up to actually testing your contracts and seeing that they actually do what you expect them to do and just send all the money to my account. I should really put that in as a backdoor. So first of all I'm just going to do a little bit of a retread of some of the ground that Manuel has so adeptly covered just to make sure that we're all on the same page here with what's going on because this is really the pedal hitting the metal. So we need to know what we're doing. So to revise a little bit, the anatomy of a smart contract. You've heard people say on-chain, off-chain, over and over again. I'm going to say it again. We have some code that runs off the chain. It runs in the user's wallets typically. This is what they interact with. It's what listens to them saying I want to send all my money to you know the fuzzy bunny kittens crowdfunding campaign and then submits a transaction that actually does that. And then there's the on-chain code which is what actually lives in the transaction. It runs during transaction validation. It makes sure that nobody steals all the money. That's very important. But these two pieces of code, as you know Manuel has explained, are very tightly coupled. They need to understand each other. They need to cooperate. They need to exchange data between each other and they jolly well better do that in the same format otherwise we're going to drop everything on the floor and everybody is going to be sad and all the money is going to be gone. So the goal of the Plutus platform is to bring these things much closer together so you can write your on-chain code and your off-chain code in the same language and that language is Haskell and even in the same file. And more than that you can actually really reuse the same types between the two. So you can just the same data structures, the same definitions and maybe if you're not a Haskell developer you don't feel that deep inner feeling of joy that that sentence engenders in me. But you know I promise you this is the thing you want. This is the thing that will make your life easier. The types are definitely your friend and you want to share them as much as you can. Moreover the library and tool chain support that we have built allows you to write exactly the same code to define a contract and run it on both Cardano obviously because that's where the real stuff happens but also on the Plutus playground which I'm going to show you today and also on a local emulator which we affectionately call the mock chain and that's what's actually powering the Plutus playground under the under the scenes but crucially you can just you don't have to do jump through horrible awkward hoops to do testing. It's all just the same nice interface. Let's drill a little bit further down into the anatomy of what's going on. So we have we have here we have we're going to continue our continue our color coding adventure. We have this blob of off-chain code written in Haskell that lives inside the user's wallets and then as a manual shown you have these these these fancy with what the previously blue colored now purple colored blocks that live in those em in those quotation quotation blocks that actually are going to turn into on-chain code which are also written in Haskell or as we like to call it Plutus TX because it's not quite Haskell but pretty much Haskell and these are what actually define the logic of your transaction most of the time so that that's what that's where as you saw in the crowd funding campaign check that you got enough money check the deadline is passed yes okay no not okay that's what that's happening and so that's that's the second stage the first stage being the Haskell the second stage being the Plutus TX but in addition to that we want to make it easy for you to cross the to come across these boundaries we don't want the these stages to be awkward rigid things that you keep butting up against as a programmer and in particular you often want to parameterize your your contracts you don't always want to pay Jim 10 ADA sometimes you want to pay Jane 10 ADA you want to actually be able to parametrize them and so we make it easy for you to lift chunks of data from the Haskell world at runtime in your on off-chain code into the on-chain world seamlessly and so that will all just work and this is one of these things that hopefully when we actually get to look at it you will probably might not even notice that it's it's interesting that's the goal is that it should seem really easy even though there's actually some work going on behind the scenes and then this all this that all getting it's turned into a transaction that actually goes on the chain and we're going to see all of these pieces shortly I then also want to say a little bit more about what Manuel described earlier where he explained about the extended UTXO model on how validation works so just as a reminder how do we check whether we can spend a transaction output well the spent transaction output has to accept the spending transaction by taking and we do that by taking its validator and just feeding it a bunch of bits of information and if it evaluates successfully then it's fine if it doesn't then transaction is rejected and this is done by the slot leader and in addition if you don't know what that means it's the person who actually runs all the code it's part of the Auroboros protocol and the way that works is that well we're writing in a functional language this validator script is just a function and it just takes these things as arguments and that's exactly the pattern that we will see literally in the code in a moment so remember that that's going to happen in addition the Manuel denoted this with a little sigma there's some additional information about the current transaction that goes in as well says things like what block height are we at i.e. like what time is it and some other pieces of information and crucially this is actually uses exactly the same mechanism for lifting data into on-chain code as you can do locally and you can also then use the same types so not only can we share our types between our on-chain code and our off-chain code we can share our types with what happens at validation time with the slot leaders and we can be sure that everything is just going to work and we don't need to worry about accidentally screwing it all up when we do it ourselves and so to summarize there are kind of four interactions that we need to remember and and conveniently these correspond exactly to the four Haskell modules that you would import when you're doing this for real and again in a moment you will see precisely these things in action so the first thing that we need to remember is that the off-chain code talks to the wallet this is to do things like ask for your private public key submit a transaction register that you want a trigger to take an action some later date these are things that the wallet is going to do for you and you need to say please do this that lives in unsurprisingly the wallet module the off-chain code also needs to actually make the transactions that in order to do something you have to make a transaction so you can submit it on the blockchain and actually have something happen and all of this this material is handled by the ledger module which talks about things that go on the ledger thirdly we had this this this staging business whereby we write we write this putus tx code that gets turned into putus core code that goes on the blockchain there's some stuff to do with that unsurprisingly lives in the putus tx module and finally there's the types and structures that are used during validation that you will want to care about when you're writing validators and those live in the validation module so just remember that those are the kind of the four the four things that are going on that you might want to you might care about and and we'll we'll see those in a moment so I'm now going to actually show you some code in emacs where else the font size on this is not ideal oh dear it's possible to turn this off if I just take it out of the socket nobody saw that put it back later I'm sure it's fine so this is a haskell file all right haskell if you haven't seen haskell before this is not going to be a haskell tutorial but hopefully it will not be tuber-wildering and so there's a little bit of stuff at the beginning which we're not going to worry too much about now but we will we do see that here I have written four imports corresponding to the four things I just told you about as a reminder Plutus DX is about stage code and writing things that run on the run on the chain wallet is about talking to the wallet ledger is about making transactions validation is about things that happen at validation time so just that's that's that there they are that's exactly what you'd write yourself so I'm now going to pop the hood a little bit and show you what's really going on here and the reason I'm going to do this is because although it's unlikely that you're actually going to care about the Plutus core and what's going on it is interesting to know what the sort of assembly language of what you're doing looks like is what I'm going to put a proof to you that there's really there really is something there you might have no idea what it means but it exists I'm not I'm not just making this up it's not these functions are not implemented these functions are in fact implemented they don't just like return the empty string all the time so here's here is a simple very the simplest example I could come up with of using Plutus TX so we're going to write the plus one function as a function that would run on the chain adding an in one to an integer and well what is that's going to look like well it's going to be and it's going to be an opaque blob of code as far as the off chain code is concerned the off chain code just it's just it's just once once you've made it it's you can't really do much with it it's going to get run later but that that's what it looks like and here we see the the funny quotes the funny dollars and brackets that Mamma was talking about before so for the lispers around you this is going to be old hat but for the rest of us let's let's take a moment to think about what's happening and what's happening is that between these funny double bar brackets we have a Haskell program and what that program does I'm going to reformat it so that it fits on it fits on the screen is it's a function that takes an integer and adds one to the integer very exciting and what these little quote brackets do is give you a representation of that Haskell program which is what we're then going to compile so that's all this is this is just you can just think of this as the program that's inside the brackets and then we feed it to the Plutus tx.compile function which surprisingly compiles it and then finally we feed it into these these double dollars which takes us back into back into the real world and out of the quotation world and actually shoves the compiled program into your program to use it now um what that actually means is we end up with a Plutus core program so let's look at it oh there it is it's it's it's oh I know what it needs to do I don't need to do ah I taste it like that um so here's here's a plute this is a genuine Plutus core program that you could put on the blockchain ooh and we can see a few interesting things about that it has a version that's that's interesting so this is actually something that we do to make sure that when things change we know exactly what version of the language is being used so we don't do the wrong thing uh you can see a bunch of incomprehensible nonsense uh but what I'm going to tell you is that this bit here corresponds to the bit that we wrote and the rest of it is is is not so interesting at the moment and if we squint we can see that this is a lambda function so like a like a function which is going to take some incomprehensibly named variable which is I promise you this is an integer and is going to I promise you this is calling add integer add and this is one is going to add one to it so at the end of the day Plutus core is not that dissimilar from Haskell in many ways and so actually a lot of what's going on going on under the hood here is not so clever um there is some cleverness that more cleverness that we'll we'll we'll we'll talk a bit about later but it's it's comprehensible we're just we're just one of the virtues of the approach that we've taken is that um we actually are quite close to how Haskell represents things so now this would this would this would not be terribly useful if we weren't we're only able to use integers I mean you can do a lot with integers but not everything and um in fact we can just use pretty much all of the Haskell data types that we would want to so here's a very simple example where we use the the type maybe which is in the Haskell prelude and just is either a thing that's either there or not there so it's like an integer or nothing and this does a pattern match on it and in the case that there's something there it gives you the thing in the case that there's nothing there it gives you zero so it's give me this thing or else zero and this will just work um hooray um you can reuse you can reuse your data types uh things will just work you can use write your own data types and things will just work it's not special or special built in it's just whatever you want to write um and I won't show you that because that's a bit longer and even more incomprehensible what I will show you is um here is a ever so slightly more real program so this is actually part of the example that Jan is going to show you in a second this is a real validator script for a simple guessing game um and so this has a couple a couple of user-defined data types um a couple of bits of magic to uh make sure that you can do that lifting that we talked about earlier um and then it's just a function and well what the validators look like well they're functions that take a redeemer the data the validation info just like Manuel said nothing nothing fancy here it's exactly the same and then it does some computation and decides whether or not it's going to accept it um and this you know it's simple but but significantly more complex program is also um what do I call it um is also um oh it's very long it's very long it's not that long but it's quite long for an emacs terminal um but it's a real program that we can write and that works and that you can actually execute using the putus core evaluator um for real in the putus playgrounds and it will actually evaluate and do what you want to do and i'm now going to hand over to Jan who's going to show you how to use these things in in anger and actually see something that isn't isn't gibberish okay thanks um so this is the putus playground uh there are no slides here i'm just doing it all live in the web app so this is actually working um and you can try it out for yourself later um when you open it the first thing you'll see is the code editor and that's this field where we're going to write the smart contract and it comes preloaded with a number of examples so we have the crowdfunding campaign the game um one example that just produces different blog and error messages and the vesting scheme and we'll look at those in a minute i just want to show you the rest of the user interface first so we have the contract um we click compile and that brings us to the second part of the playground and this is where we can set up a simulation on the blockchain that uses this contract so we can set up a number of wallets each wallet has a an initial distribution of funds or 10 ADA in this case and these wallets can perform actions and these actions that are going to be defined in the contract that we will write and because we have an empty contract here there's only one action that they can do and that is pay something to a public key owned by another wallet so let's try that let's pay eight to the second wallet and the public key of the wallet in the playground is just the number of the wallet and then well two pays back eight to wallet one and we can put up any number of actions in this sequence here and then the emulator will run it against the the mock chain oops sorry one so now we get to the third part of the playground and that's where we see the the results of the simulation i'm zooming out a little just so that we can see this whole graph here and this graph shows the entire blockchain that has been generated and the time in this graph flows from top to bottom so the node at the top here that's the initial transactions a transaction and the other nodes are the remaining transactions and the node at the bottom here this utx o node that's an unspent output so the last ones at the end they're always unspent outputs and all the other nodes are transactions and the edges in this graph they're pairs of input output connections so one transaction consumes the output of the previous transaction and the size of this edge shows you how much data was transferred in that so we can see here each wallet got 10 data initially and wallet two received eight data from wallet one and wallet one received eight data from wallet two the second part of the output is this log that we'll see here and that just lists all the events that happened on the in the simulation so we see transactions that were valid transactions that were rejected any script failures log messages from the wallets and we get quite a lot of information from this and here we see three transactions the initial one and then the two that are just created and the final output that we get is the balances of the wallets at the end so each wallet is back to 10 data that started with so this is the general workflow of the the playground we write something and we set up the simulation and then we look at the results to make sure that the contract behaved exactly like we um we wanted it to now this is a full source code for this game and that we already saw the validator off earlier in michael's talk i'm just going to make it a bit bigger okay so um we start out with the module name can be anything then we have the imports that we need as before so we have plutus tx and the prelude with with some helpful functions ledger validation and wallet imports and when we're working in the playground we also need to import the playground contract module because that lets us define the contract endpoints that the wallets are going to use to to create transactions with this endpoint and then in this line we also have another haskell library that we're importing from byte string and that we only need in this particular contract so we can use any other a lot of other haskell libraries in here as well now we need to define the data types that we want in this game so that the rules of the game are the first player makes up a secret word and puts the hash of that word on the chain so they're using a transaction um output that's locked by the the hash of the the word basically and the certain player has to guess the word and if they guess it right they get the funds in that and to encode the hashed word we just have this hashed string data type and for any data type that we want to convert to the on-chain representation um we need to call plutus tx.makelift that's why we have that here and then there's a helper function that lets us take a haskell string and produce the data script for the transaction and in this that's where we so first we have the hashed word here using the char2 function and we embed that into the the data script using ledger.lifted and ledger.lifted takes anything that you have defined makelift on and puts that into the on-chain representation so we need that for the data script and then a similar definition for what goes into the redeemer script and that's the guess of the other player and here we have a clear string which is also going to be the byte string on the chain and by using these these types that we've defined we can make sure that in the validator script we don't compare two wrong things so we don't compare a clear string and a what was it called a clear string and a hash string but we always compare two hash strings for example so we have the clear string and we can construct redeemer scripts containing the clear string with the make redeemer script function and then finally this is the validator this encodes the the game logic so we have the two quotation marks from earlier here and here line 42 and anything in between that that this is the actual on-chain code all written in haskell again and in here we can use the import p.from earlier because we imported the prelude qualified as p then we can use any functions that are defined in there with this splicing operator these are the two dollars so that lets us use functions that were defined outside of this script and puts them into the script so we compare the two byte strings and if they match then we just terminate or we just return the unit value no error but if there's a mismatch then we produce an error using the error function and a little log message so that we know what happened now we need to we have the on-chain code we need to define the the contract endpoints now so how do the wallets interact with the game and that's what the next few functions here are for first the first interaction that we need is locking some funds with the secret word this is what the first player is going to do so we have a function that takes two arguments a string and the value and it returns a value of type mock wallet and mock wallet says that in this function we can use the wallet api to produce transactions and to interact with blockchain so we're using the wallet api as an intermediary to talk to the chain and pay to script here that's one of the functions from the wallet api and we're just paying the value to the address of the script using our make data script function from above now the second endpoint that we need is guess which takes the guess and also returns a mock wallet function because here we're using collect from script which instructs the wallet to take out all the the unspent transaction outputs at the script address using the validator and the redeemer scripts here now there's a little problem with this at the moment because to collect all the outputs at the script address the wallet needs to know that this is an interesting address so that it can watch this address for any outputs that are produced to it otherwise it doesn't because it can't just watch all the addresses of the entire chain all the time and to make the wallet aware that this is an interesting address we have a third endpoint which is called start game and it just tells the wallet to start watching the game address at the end of the contract we have three calls to make function and that's what will generate the contract endpoints that we're going to see so make function lock make function guess and start game and we can call make function on any function that has this structure that returns the mock wallet so let's compile it and now you can see that the wallets have learned how to do these actions they can lock something they can make a guess and they can start the game so wallet two has to start the game but one will lock the funds and then wallet two will make a guess let's see how that works okay so here we have the the transaction from wallet one locking the eight adder and then this is wallet two retrieving them because the guess was correct and that little bit here that's the change that goes back to wallet one and in the log we can see there were the successful transactions as you would expect and wallet two ends up with 18 adder if you put in the wrong guess now there's no transaction that spends this output and we can see in the log that the validation failed for this transaction so that's that's something that you can only get in the playground and in the emulator so you get these error messages and detailed reasons why validation failed you won't get that on the real chain but it's very useful for designing and debugging contracts and now wallet two only has 10 adder wallet one two adder and the remaining eight adder that are missing they're still locked in the script output let's look at the crowdfunding contract now i just want to show you these blockchain triggers in a little bit more detail that manuel mentioned earlier so we've this is the the contract endpoint that makes the contribution to the campaign and once we've made the contribution we register this refund trigger and that's a condition on the blockchain that becomes true at some point so in this case it means the campaign deadline for the campaign has passed and the funds haven't been collected yet so in that case the contributor is entitled to a refund when that happens it calls the refund handler so this is like an event-based system where you have some conditions and then you can call an event handler that deals with or that reacts to this condition in this case the refund handler is implemented here and there's one important difference between this refund handler and the guessing endpoint that we had in the game earlier because earlier we were using just collect from script from the wallet API and here we're using collect from script transaction because we don't want to try to reclaim all of the contributions to the address but only the one that we made ourselves in the initial transaction and that's why we're calling collect from script txn to only claim back our own contribution if we try to collect all the other ones then the transaction will be invalid and we wouldn't get anything back so we have to make sure to create a valid transaction and this whole blockchain trigger system that all runs in the client code so it doesn't go on the chain this is done by the wallets themselves so we're going to run a little campaign two contributors and one is the campaign owner and they have to call schedule collection again so that they start watching the address and you can see here that it generates the correct form for the data types that you want to put in so we have defined a campaign data type above and the playground automatically gives us these inputs here to put in the blockchain height values and anything that we need so let's say the campaign runs to 10 blocks target 15 ADA collection deadline 20 and the owner of the campaign is this public key let's make two contributions and we have to make sure to put in exactly the same details because the campaign this definition is part of the address of the script and if we put in a different number here for example then the contribution will go to a different address and it won't be registered as part of the campaign so 15 20 owner is one and then contribute eight and now we have to add a weight action again because if you run this then we won't be at 10 blocks so the campaign owner won't even attempt to collect the funds yet so we can use this button here at weight action to add a number of empty blocks to the chain just to simulate the passing of time now this is a bit more complex but you can see these are the two contributions 9 ADA and 8 ADA and this is wallet one collecting the funds and now we if you look at the logs we also see these messages from the wallet so in in the wallet API we can also log some information here and then at wallet block height 10 this is when the collect funds trigger fired and collected the two contributions and what happens if we have an unsuccessful campaign say well three only contributes to it and we have to add some more blocks so we have to get past the campaign collection deadline 20 blocks and now you can see that the the contributions here were claimed back by the original contributors so message from wallet two claiming refund message from wallet three claiming refund and everybody's back to the balance that they started with so we can use the playground to to go through really complex interactions with our contracts and it all evaluates quite fast considering what it's doing because when you click evaluate it really spins all the wheels it compiles the contract emulates the transactions it runs the compiled code and returns all the results to the web interface that's all i wanted to show for the demo and there's some links here to more documentation the url of the playground is here so you can try out these examples yourself yourselves and there's a docker image as well if you want to download it and run it locally and i encourage you to try it out make some changes see how the contracts behave thank you