2. Plutus Playground
Okay, I’m now about to do something very dangerous, which is tell you lot how to actually do something! And we’re even going to do it live in front of you to prove that it works. *pause* This is the point where the god of demos strikes me down for hubris...

3. Writing contracts Why are we here?
But seriously, what is the point of all this theory and infrastructure we’ve been wittling on about endlessly today? The answer is simple: we want to *actually write some smart contracts*!

4. Plutus Playground is an environment for writing and testing contracts
Fortunately, I’m here to talk about the Plutus Playground, which is about doing exactly that. This is an environment for writing and testing contracts in your browser. So we can actually write an end-to-end example of writing a smart contract on the Plutus Platform and running it in a test environment.

5. Anatomy of a smart contract
Wallet
Transaction
Off-chain code
On-chain code
But first we need to talk a little about the structure of a smart contract. The first thing we need to do is realise that most smart contracts consist of two parts: some off-chain code that runs in the user’s wallet, and some on-chain code that runs on the blockchain.
In Ethereum you would write the off-chain code in Javascript (running in the user’s browser wallet) and the on-chain code in Solidity (running on the Ethereum chain).
But these two pieces of code are quite tightly coupled, and they often need to exchange data between each other.

6. The Plutus Platform
Write your on-chain code and your off-chain code in the same language (Haskell!), even in the same file.
Use exactly the same types on and off the chain.
Run exactly the same code on
Cardano
Plutus Playground
Local emulator
In the Plutus Platform you can write both of these programs in the same language, even in the same file. You can use exactly the same types in both of them, which ensures that transferring data between the two is seamless.
Moreover, you can then run these programs (precisely the same, real programs) both on Cardano itself, and on various testing environments.

7. Anatomy of a Plutus smart contract
Wallet
Off-chain code (Haskell)
Transaction
User action/Trigger
On-chain code (Plutus Core)
Data (lifted Haskell)
Transaction block (PlutusTx)
Let’s dig a little deeper into how that actually looks. Of course, the place that the on-chain code is created is *inside* the off-chain code, so we expect to see something related to that inside there.
In PlutusTx you write the majority of your transaction logic inside transaction blocks, which are compiled into Plutus Core when you compile your off-chain code. This is an example of *staged* programming, which will be familiar if you’re a Lisp-er. We write our programs in stages, where the later programs use the output of the earlier programs. In this case, the off-chain Haskell code creates the on-chain code, and passes values to it to use later. But it’s not actually evaluated until it’s on the chain. The nice thing is that we can make most of this transparent to the user, so you can easily move stuff across the stages.
For example, you also want your code to do more than one thing, so these need to be paramaterized by any runtime data. This can be *lifted* into Plutus core and applied to the transaction block in order to make the program that you actually submit in the transaction.
Now, the nice thing about this is that it’s just function application. You write your transaction block as a function that accepts an argument of the appropriate type and it will all Just Work.

8. Anatomy of a transaction validation
Spending transaction
Spent transaction
Slot leader
Redeemer script
Validator script
Validation info
Data script
Evaluates?
We also need to know a little bit about how validation works in the extended UTxO model. I’m assuming most of you were at Manuel’s talk before this, so hopefully this will be familiar.
When a transaction spends another unspent transaction output, then in order for that to validate, a slot leader must check that the validator of the spent output accepts the spending transaction. It does this by passing the redeemer and data script from the spending transaction to the validator, along with some runtime validation information containing other data about the spending transaction, the block height, etc.
Now the nice thing is that again, this is just function application, and the validation information is lifted into Plutus Core in exactly the same way that your data arguments were in the previous slide. So not only can we share types between our on-chain and off-chain code, we can share types between our on-chain code and slot leaders!
The upshot of this is that validators have to be functions that take all these things as arguments, which we’ll see in a moment.

9. Four interactions to remember
Off-chain code + wallet
Wallet
Off-chain code + transactions
Ledger
Off-chain code + on-chain code
PlutusTx
On-chain code + slot leader
Validation
In summary, there are four interactions you need to remember, and conveniently these map on to the four Haskell modules we use to talk about them!

10. Demo
Okay, enough theory, time for some demos! I’m going to give you a quick introduction to PlutusTx, and then Jann is going to walk you through writing some actual contracts.