 Good afternoon. Thank you very much for taking the time to come to Plutus Fest and giving us the opportunity to present our work on the Plutus platform. So what I want to do in this talk is I want to answer the question, what is Plutus? And then moreover I want to tell you what's special about Plutus. So well let's start with the simple. What is Plutus? Well to summarize in one sentence Plutus is an innovative platform for the development and execution of distributed contract applications on the Cardano blockchain. Now you may say, well there are other contract platforms. What's so special about Plutus? There are three pillars, three special things about Plutus. The first one is a focus from the ground up on safety and security. The second is for it to work on a superior ledger architecture and thirdly we provide an integrated full-stack development environment for the on-chain off-chain components of contract applications. So let's look at these three in turn and let's start with safety and security because that's really at the heart of the matter. As far as safety and security goes, we've got a secret weapon. It won't be secret anymore after today. Maybe you can already guess. It's functional programming and type system. So yeah, what's this strange stuff you're coming with? Can't you just do object-oriented programming like everybody else did yesterday? No. So what's so special? Why do we do functional programming? Well because it's very simple and if you care about safety and security, simplicity is your friend. Functions are just mappings from inputs to outputs. Now you probably say well, any programming language has functions but we've got pure functions meaning the mapping from inputs to outputs is all the function ever does. The function is a pure function is entirely characterized by just this mapping. If I use the same function on the same inputs twice I will get the same result guaranteed. That's what makes it easy to reason about what the function does. Now we couple this with types. What types? Well it's basically a description of the inputs and the outputs which the function can handle properly. Basically it tells you if you lose the function in a particular context where it gets those inputs it's guaranteed to do the right thing and it's going to give you something back which has also certain properties which is represented in the output type. So the types give us more information about the behavior of the functions. Simplicity, that's great. Also this concept Phil told you this morning one way for us to make sure that our work on Plutus is going to be of, has a long life is to use something established, something based on research from 40, 20 years ago which has been validated over and over and over again. Well the notion of pure functions is even older. It's been validated, it's the basis for all of formal scientific reasoning. So it's a good foundation. If you want to make sure things actually work. So what do we get from it? We get the ability to reason locally. If you look at one pure function just by itself you can understand everything about it. You don't have to look at the 50 other modules of your program which we usually don't and then you misunderstand what the thing does. Secondly we can perform type directed design meaning types are not just a way to check whether function is used in the right context. No, no we use types to actually design our programs. It's a methodology for us to arrive in a constructive manner at a program which is already doing what we wanted to do or at least very close. Instead of just coupling something together and then testing it until maybe eventually works. And finally, and that's also very important, it allows advanced validation, testing techniques and even formal verification. The kind of thing James Chapman has explained in the academic stream before lunch where we fully formalized the semantics of the Plutus core intermediate language. Now by taking these two things we get two major benefits. We achieve an increased understanding of the behavior of the code we are writing and of the code we are putting on the blockchain. And secondly, it gives us the tools to find exploits in that code. That's really the goal. That's why we go to the effort of this rigorous discipline of developing the Plutus platform. And let me give an example, one which has been mentioned before of what the outcomes of this are in the form of Plutus core. So Plutus core is the representation of programs as we store them on the blockchain. And as Phil has explained, we use this Plutus core based on system F omega. Doesn't matter what that exactly means. What's important to know, it's an established calculus which has been validated by the scientific community. We are basing it on this and it's a small well understood system. It's purely functional system. Everything in it is just pure function. Everything in it is typed. And by this design, the type directed design approach, we get to a very small, minimal system. So it's different to other virtual machines or similar things you have seen. It's not a byte code. Everybody uses byte codes. Why? Because Bitcoin had byte code, a Bitcoin had byte code and nobody came up with a new idea. Really, copycat. Plutus core is a type functional programming language. A very small one, but it's a full functional programming language. Also, we don't use a virtual machine, a big complex thing which we have to validate a verified test again. We use something called an abstract machine interpreter which is based on the operational semantics, very directly on the operational semantics which we formalize of Plutus core. And that's very small. It's what you have on the napkins. It's small, meaning it's a simple system we can actually, or James, can write an actor formalization of it and prove that it's doing what it's supposed to do. That's what we get back from the effort of going through this rigorous development methodology. All right, so much for safety and security, but where is this Plutus core thing used? Well, it's used on the chain. So now this gets us to the ledger. What about the ledger? Well, generally speaking, there are two ledger architectures as probably most of you know. There's the so-called UTX or unspent transaction output ledgers, like Bitcoin. And then there is account-based ledgers, like Ethereum. Now, what's the difference between? Well, if you look at it, the structure of the UTXO ledger, it's really a structured data flow graph. It shows us exactly for each transaction what are the inputs, what are the outputs, like the pure functions. Remember, a function is a mapping from input to output. So the transaction, they are very similar in nature. In contrast, if you look at an account-based ledger, like Ethereum, then it's really like object-oriented programming. So the accounts are the objects and they send messages to each other. Well, you may think, well, object-oriented programming is cool. Well, it was cool. But have you ever tried to write an object-oriented program in a concurrent and distributed manner? No, because otherwise you wouldn't sit here, you would be going crazy somewhere in a closed institution, maybe. It's very difficult, very buggy, you get race, conditions, deadlocks, lifelocks. It's crazy. I mean, the entire conference is just devoted to even halfway sanely handle this kind of complexity. We don't want this complexity on a ledger. We want to get it right. We want a compositional structure. But what about smart contracts? Right? So this is Bitcoin. This is Ethereum. We know Bitcoin scripts. Not that interesting, not very powerful. Ethereum, yeah, well, you can write any exploit you want. So the question is, can we have both? Can we have the simplicity and gain the power? So let's look at this in a bit more detail. What's a transaction? Well, transaction gets some inputs, the red bits, and it has some outputs, the black bits. So inputs could be money in, outputs, money out, but could also be data. And then we can join them together, but we can't join any all transactions together. Well, the money summing game has to be all right, but there's more when scripts are involved. The outputs, they come with what we call a valid data script. And that's in Flutus core in our case. And the inputs, they come with a redeemer script. Both are little programs. And in order to check whether we can plug the two together, we have to apply one program to the other. It's a function call. Well, everything's functions for us, right? It's a function call. And the result is either true, so okay, or it's not true. There's an error. And then we say, no, this transaction has to be rejected. That's a simple model. That's the simple model you get in Bitcoin. Now, we've extended this slightly, keeping the spirit, the simplicity, and by just adding a little bit more information. So in the outputs, in addition to the valid data, we get a data script. So in addition to the code, we have some data which can travel along the UTXL graph. And then we also provide access to some further information on the chain so that we can reason about chains of transactions. And then the validation condition is slightly more complicated. This function, the valid data function, is applied to a few more arguments. Still the same principle, plus a little bit more data involved. Now, this gets at what we call the extended UTXO model. So the nice thing about the extended UTXO model is it has the same structure, the same simplicity, the same ease of reasoning about it as the original UTXO letter. But it provides the scripts with significantly more expressive power, giving us the best of both worlds. So what's the additional expressivity that we are gaining? Firstly, we have the ability of letting data flow along pure value through the transactions and this transaction graph. So we can do things other than just trade money on the blockchain, which ultimately, that's what we want to do with smart contracts. We want to track other information, not just the funds. Secondly, scripts get an identity which is similar to, in an account-based model, the account provides you some identity and often you need identity to reason about things using the same script and similar invariance. And finally, and that's very important for more complex contracts, we get the ability to write scripts which ensure certain invariance that certain things are true about, for example, not your money not getting lost or an f of a chain asset being tracked correctly across multiple transactions on an entire chain of transactions. That's the power we gain in this extended ledger model. All right, so that's two of three. So what's the whole full stack business about? Well, what's a smart contract? Let's take a simple example. Let's have a simple crowdfunding example where, well, somebody makes a campaign, other people can pay into this campaign for a certain time until a deadline, then if the funding goal is reached by the deadline, then the campaign owner can get all the paid in funds out. And if the funding goal doesn't get reached, then of course contributors want to be able to get all the funds back. Or if say the campaign owner runs away and doesn't play anymore, then you should also be able to get your funds back. So very simple setup. Let's use that as a little bit of a running example. As Phil mentioned in the beginning today, well, if you want to implement this in solidity, then, well, you write some solidity for Ethereum and then you write some clavascript and then you put the two together. That's a quite ad hoc way of constructing your program, but it's necessary because the off the clavascript bit, they are associated with the wallet of the user. That's where you spend stuff into the contract. And then the on-chain bit, this is where all the contract logic happens and it makes sure that things are only paid out under certain conditions. So you need both. There's no way around it. And this is what programming language researchers like myself, we call this two level or stage programming models. And this is not a new idea. It's been around for a long time. People have researched this. In fact, some of these ideas go back a long time to the first functional programming language, so the least line of languages for the developers among you. Now, this particular setup with solidity on Ethereum, this is very ad hoc. I mean, people just thrown this together. I don't think they thought about any programming language considerations, really. So the communication between the two is ad hoc, and why is ad hoc bad? Maybe ad hoc is good. Now ad hoc is bad because it's inconvenient. You have to learn two languages. That's bad. You can't take out from one language into the other language. Now you have to rewrite it. That's also bad. Also, it's complex because the communication between the two, the protocol is quite complicated. And it's difficult to check that the things fit together. So it's fragile. You change one. You still can run it, but it doesn't work properly anymore. Then you have to find out why the compiler doesn't give you any help. It's a mess. So we thought, well, this is two level stage programming. We should be able to do something better with all our programming language research knowledge. We should be able to come up with something better. So our idea was to say, well, for off-chain, let's use pure functions, Haskell. Good idea. Thanks. On-chain, also Haskell. Well, actually subset of Haskell, which we call Plutus DX. But now one nice thing immediately apparent. You only have to learn one language. Also, if you have code on-chain and you need the same data structure off-chain, well, you just use the same definition. If you have code on-chain and you wouldn't move it off-chain, just copy paste. Don't rewrite into new programming language. That's what you want to do, right? So how do we tie the two together? Well, we use meta programming. Meta programming was first introduced with Lisp. So it's another old proven idea of tying up a two-level language, which we are using here. So the result is something which is integrated, one language framework. And it is compact because you don't have to spread things across multiple files, tie them up in an ad hoc way. No, this can only live in one file. You can modelize this, of course, if you want to, but there's no need from the programming language. And it's robust because if you mess up the interfaces, the compiler will tell you, oh, you made a mistake here before you even run it. So you get some information back on what works and what doesn't work. Now, let me give you a slight idea of how this looks like. And I appreciate not everybody's a Haskell programmer. So I won't go into great detail here. I just want to give you an outline of what such a contract looks like. And I'm just going to look at one function, namely, how can I contribute to the smart fund crowdfunding campaign? So that's a function contribute. It gets a campaign as an argument and how much you want to contribute. Well, then we should check that you actually want to contribute positive amount. And then this code, this is off-chain code. So the green, slight greenish background, that's off-chain code. So we get your public key from the wallet, from your wallet. Why? Because we have to be able to refund to something in case you get a refund. And then we create a transaction with the script. Well, what do we have to give this function creating the transaction? Well, it has to get the script. I'll talk about this in a second. We have to tell it how much you want to contribute. And then it gets as the data item, remember, extended UTXL model, there's a data item, a data script together with the validator, which in this case is the public key of where refund goes to. And then we set up a trigger that if a refund condition arises, we can execute the refund code, refunding code, so you get your money back. All right. So now how do we get at the script for validation? Well, that's where it gets interesting. That's where we get the two-level language. And I don't have enough space on the slide to put it on one slide. So let's continue on the next slide. So what we do here, we write more Haskell. And this time we define a validator, which is applied to a particular campaign. And what happens in the validator code? Now you have some strange symbols, dollars, square brackets. This is just Haskell speak for do some meta programming. And we get blue into the blue part, which is the on-chain code, still in the same file. Now what does the on-chain code do? Well, first of all, it gets one argument called TX, which is transaction. And this is syntax for Haskell pattern matching, taking a complex value, splitting its multiple components. Because we have to get at the individual bits of the transaction to check, it's okay. That's our job. We are the validator. And then there are two cases where it's okay. Well, either we are in a refund condition, meaning the collection deadline has passed. All the payments in this transaction go to actually the person who made the contribution. And that person has signed with their correct key this transaction. So the signature on the transaction is correct from the right person. That's when you get a refund. Or it's time for the campaign owner to collect. In this case, well, we have to be after the campaign deadline, but before the collection deadline. And all the inputs have to add up to what the target goal of the campaign was. And finally, of course, we again need to correct signature on the transaction. If either of these two conditions is met, then transaction is good to go. Otherwise, we throw it away. So it's quite compact code. Of course, I appreciate if you're new to Haskell. It all looks like special characters. Once you get used to it, it's actually not hard to read. It's just a pure function. All right. So this rounds up the whole three pillars of Plutus. So the things which make Plutus special. But let me give you the overall overview. How does this all fit together? Well, you write your Plutus contract. Then you use the tooling we provide to compile this into a piece of code which communicates with a user's wallet or multiple user's wallets in the distributed case. And this provides the wallet with the ability to invoke what we call contract endpoints, the things the user is supposed to use in the contract, external functions in Ethereum. And by doing so, your off-chain contract code will produce transactions, including Plutus core, which go onto the chain. And then the wallet which observes what happens on the chain will notify the off-chain code of any events which are interesting to its execution. And this completes the cycle where the off-chain code notified by an event, such as the refund trigger we put into place in our example, can submit more transactions and so on. And that's the overall architecture. It's also quite simple. But simple is good, because for simple architectures, we can check that they actually always do the right thing. So overall, that's Plutus. It's built from the ground up using, with a focus on safety and security, using the methods of functional programming and type systems. It uses the superior ledger structure provided by UTXO ledgers, in this case extended with the extended UTXO model. And it provides a full stack environment where you can do on and off-chain code at the same time in an integrated manner. Thank you very much. So if there are any questions? I actually very like UTXO model and Bitcoin because its blockchain is small and it's quite important in these days because we know what happened with Ethereum. And when you're adding so much additional information to all the outputs, what do you plan to do with the growing blockchain and space? Because each time you're creating new output, you're adding code there and data. And if you're reusing it's like 10 times, that means that you have 10 copies of the same code in the blockchain. So it looks like a kind of big problem with the growing main layer. So the setup is exactly the same as with the plain UTXO chains. So the important data structure in the UTXO chain is the UTXO set. Well the U in UTXO stands for unspent, meaning you put all these transactions in there and all the transaction outputs which have not been spent yet, they need to be kept in the UTXO set. But the crucial thing is once you spend an output, it cannot be spent again. This is a double spend restriction. At that moment you can call that output from the UTXO set. This is not new to our extended model, this is the case in Bitcoin already. And so basically we have a natural form of garbage collection, which if you're a programming language person, there are many programming language people in here. It's like a linear type system. So if you know everything is single use, once it's used you can throw it away. You don't need a complicated reference counting, garbage collection or anything. It's just once it's used it's gone. And so the data structure, the main data structure which has to be kept in memory, the UTXO set grows and strings in the exact same manner as it does for Bitcoin or Cardano today. Hello. Well first of all, amazing talk. I really enjoyed it. And then we inherit a lot of really cool things about Haskell, but also some of the challenging things. And especially I would say the challenge of adoption, right? Is there any strategy that Cardano or the bigger ecosystem is doing for these to be adapted into a critical mass for the environment, etc.? Yeah, that's an excellent question. Thank you very much. And the outlook is extremely bright. So as I think we've heard this morning and IHK has been doing for a while, doing training courses, educating developers in the use of Haskell. This is going to continue. So we are actively working in teaching people how to use Haskell and in extension from now on also Plutus. That's number one. Number two, if you look at what's happening in the wider developer community at the moment, you will see there's a seed change. So that's why I kind of flippantly refer to object-oriented programming as the thing of the past. Because if you read tech magazines these days, they're very critical of the problem with object-oriented programming and how it didn't fulfill the promises of abstraction, modularity, and so on. And there's a strong shift towards functional programming. And you can see this on a large scale. For example, if you look at the Apple development ecosystem, Apple recently they used to have all the developers write Objective-C. Now they converted everything over to Swift. Swift is a hybrid language, a hybrid functional object-oriented language, but it has a very strong focus on functional programming. And all the type system things we are doing, they are all present in Swift. The type system of Swift is not any simpler or whatever your metric is than Haskell. So what Apple has done in the last few years, they've taken this millions of developers like all the iPhone, Mac, and so on developers and converted them from writing Objective-C to Swift. Right? So it's not like large chunks of developers aren't able to make this move to functional programming. It's a matter of explaining why it's a good thing to do and providing the teaching material for people to achieve it. But I don't see this as a significant obstacle and I think Apple has proven you can do it. And if you generally look at the developer meetups and so on, there's a huge interest in functional programming. More and more people learn functional programming anyway, whether it's in Haskell or any other functional programming language. So what I would say, we are actually, we are going with exactly the times. We are running the direction of where everybody else is heading, as far as programming languages go, instead of being stuck in the past with object-oriented programming. Thank you. There was also a gentleman behind you. Thank you. I'm not a programmer, but I would like to be sure to understand. So I have two questions. The first question is, a programmer can make, can develop a program or smart contract with Marlowe and use Plutus for more complex to add some functionality? So the way it works at the moment is that Marlowe can be compiled to Plutus. So it's basically implemented on top of Plutus. And the two integrate perfectly as a result. So our Modus operandi at the moment is for Marlowe to be a self-contained system where you avoid having to have the developer experience and the domain expert can create contracts. Now, due to the integration of Plutus with Marlowe, what you're describing to use Plutus as a sort of extension language of Marlowe, I think is a plausible way of moving forward. It's nothing we have explored so far because to get to this day, we had to build the systems themselves. But I think it's totally feasible because you're using the same underlying infrastructure, namely the Plutus infrastructure. And then a collaboration between Marlowe contracts and Plutus contracts is effectively just two Plutus contracts collaborating. So that's totally fine. And the second question. Do I understand that you can develop multiple contracts with Plutus? Yes, sure. In the same software, in the same development, like I'm not a technical, but in Ethereum, you have multiple smart contracts that can interact with an interface. But I understand that with Plutus, you don't have those multiple contracts that you have to connect with the interface. Okay. So what I'm saying is that the on-line, off-line code is integrated. But in one program, you can. And typically, if you look at the examples we will provide in a second, then you will see that once you get to more complex contracts, a single overall Plutus contract will contain multiple on-chain bits. That's totally fine. There's no limitation. It's just that I use this color coding with the blue and the green. But there can be many blue things in one big green box. And there's no limitation on how many or anything. It's just, for the simple example, it's always one on one, because otherwise it doesn't fit on a slide anymore. Thank you. We can do one more. Yeah. Thank you. I had a quick question. I'm not a software engineer, so forgive me if this question sounds a little ignorant. But you were mentioning Ethereum and how someone who's coding has to do an on-chain and off-chain solution. So they have to code in Solidity and Java. But for Plutus, they just have to know Pascal. And basically my question is that because you're using more compilers, or why is the solution for off-chain and on-chain with Plutus so much different than Ethereum? Does it have to do anything with the compilers? Yeah, it has something to do with the compilers. Basically, what we are doing is an old thing, which my background is very much in research, programming languages, compilers and these kind of things. And what we like to do, what we compiler writers like to do, we want to make the life of people who write code easier. And in this case, instead of letting people manually use these two different languages and then manually kind of connecting them and handing all the build system for multiple lengths, all this complexity, instead of every single contract developer doing that for themselves, we do it for them. So we have a compiler, which is more sophisticated and which performs the separation of the one program into two or multiples, according to your question, and tying the two up and making sure that it all fits together. That's, we automate that. We have developed infrastructure, compiler technology, which automates these things so that the Plutus developer doesn't have to do it manually anymore. So it's a matter of automation through the compiler infrastructure. Does that answer your question? Yes, it does. It makes sense. Thank you. Thank you very much. I think we have to stop with questions here because you may be interested to actually see this in real life. And that's what's going to happen next. We will have Michael Peyton-Stones and Jan Müller presenting Plutus Playgrounds.