 So, yeah, if the presentation gets you excited about developing some DAPs, this is here to help state channels making your application practical. So a simple problem. You're going to build your awesome DAP. This is the age of Ethereum. Your application has access to the world's most secure, decentralized and trust-free mobile phone from 1999. How do you deliver an amazing user experience in top of that? Large scale DAPs. You already run into these limitations. And the answer is state channels with the giant display rank bottom that you do not have time to read. So, we're going to quickly review the concept of state channels. State channels are something that have come up, I think, in three of the presentations so far. But I know not everyone will be familiar with them, so we're just going to do a brief overview of what these are. Step one to making a state channel. Find someone you want to use Ethereum with and create a special smart contract. The idea of this contract is that it's a very simple judge. It doesn't understand a lot, but it mostly understands that if you made a promise, you need to keep that promise unless you changed it later. So, if you send a promise in with a judge and it says it can be changed later, it kind of waits around for a bit and says, was there a later promise? I didn't hear a later promise. This must be the final promise. And then it basically does whatever the promise says. That's the basic principle of what we're doing. With that principle, we can take a lot of very important things that your application does, take them off of the blockchain where it's expensive and slow, and make it cheap and instant, just directly between the parties. So, we have this judge. We want to take some state and put the smart contract in control of it. Now, before you do this, make sure you get a promise that you get control of that state back. That's very important. The judge will enforce these promises, and because in a state channel, nothing can happen, no new promises can be added unless all the parties to the state channel agree, then nothing can ever happen without your permission. That means that having the judge in charge is still safe. It still gives you the guarantees of the blockchain. It still gives you the properties that you need in the security and reliability of your app's execution. So, step three, now we're all set up, we're ready to go. This is the awesome part about state channels. The two parties can just agree on new promises. They can just agree, this is the new thing we want to do. This is the new thing we want to do with our state. This is the new way that we want to transfer these tokens. This is the new way that we want to update this value that the smart contract is in control of. And because you know that the judge will always give you time to tell your side of the story, the instant you receive that promise that has been agreed upon by both parties, it is instantly final. Because as soon as you have it, you know that you are guaranteed that you can get it to the judge in time. Even if the other party tries to pretend that a previous version was what was going on, the judge will not be fooled. They will always give you time to submit your response. That means that all of these promises can stay off of the chain. We can update these many times, the rate example this morning, streaming live payments for an energy application that switches something off if you don't have time, if you run out of funds, or if you decide to stop paying for it in real time. These are the kinds of applications that we've envisioned for blockchains for a long time, but they're not quite performant and practical if you're going to have to actually execute all that on chain. Going back to looking at broader dApps, if you're trying to give a good user experience, and your user has to do something critical in the app, and then click and then wait for three or four block confirmations, that's a major interruption in your user experience. These promises are instantly final and that's fantastic. So you're all set up. Everything that you want to use inside the state channel just between the two parties, you can just agree, sign new promises, update the state between the two of you, three of you, four of you, hope you're in the state channel. If you do want to take some of that state and use it somewhere else, there are some things you can't do inside of state channels, that's your big disclaimer text in the bottom there. Then you can just sign a final promise and it's straight to the judge. You do not have to wait out that time period if you're both available and in agreement that this is something that you want to do. So withdrawing from state channels can be as fast and normal as any other transaction on the network as long as the parties are available. And that's your basic overview of the state channel. It's very simple. In fact, it's a little too simple, so we're going to make it more complicated. So let's make it a little bit better. Let's amp this up a little bit. So first thing I lied, you don't put a judge in the blockchain. You can put the judge in the promises and then you just have a multi-state in the blockchain. This is much better. It's tighter, it's more compact. It gives you better privacy properties. If someone's looking at the blockchain, they just see a multi-stake that occasionally makes transactions. Nothing suspicious about that. Second, users tend to go offline. One of the challenges if you are using a state channel is that you have to be available to tell your story to the judge. Well, users are often not available. So this is another key insight here is that users who are going to go offline, you don't have to be available yourself. That promise just has to be available. What you can do is you can just take a bunch of bystanders, set up an agreement with them. This can be in state channels as well. It says in the event that the other party does publish this old state, I want to make sure that you publish this latest state. If you set things up correctly, there's going to be a big giant punishment to that other party for publishing something that's out of date. Actually, Joseph Kuhn is going to talk later on about the security models that you work on in the context of state channels. So there's going to be plenty of money to fund the participation of these third parties and it's very competitive. If one of them doesn't do their job, the other one is able to get in and get that little edge. So this is something that you can really rely on market dynamics to do for you. And then third, the most important thing, like Haiko's presentation earlier this morning, is you want to build these channels into giant networks. So if you are going to be in a state channel with another user, you don't want to have to set up that state channel just for that one thing that you're doing. That is not taking full advantage of power of state channels. Instead, you want to build these into giant networks so that if you have someone that you're not directly connected with and you're not even one person away from it, but you're two people away from it, you can combine those three channels together. You can make agreements across the channels that are all conditional on each other in a nice, clean way. I think Joseph Kuhn is going to show us a little bit of an example of that. And build these giant networks so that you don't have to have a dedicated channel for every person that you're going to interact with in your application. And this is exactly where Raiden comes in. This is what this is all about. Most of the time in channels when we think about these pair-wise relationships between two parties, there are lots of contexts where you want to put more in. In a lot of these situations where you have many different links, it ties up a lot of resources. One of the challenges in state channels is even though they're instant and they are trust-free, they do tie up a lot of resources if you are super safe with them, which you should be. Instead of having those resources spread across multiple channels, you can sometimes have a group of people who have a reason to be in the same state channel together and tie up your regular multi-stake with just a few extra keys. And that works perfectly well as well. So let's make this concrete. Let's talk about a specific app and how it would change if we're using state channels. I went out and I grabbed etherdice.io, which turned out to be a bad example, because I thought of it and then I went and checked, and they're offline now, but that's fine. Here's a rough overview of what etherdice.io does. This is a gambling contract, an app that tries to be provably fair for some definitions of provably fair. The idea is that the operator of the bet generates some entropy and they submit a hash of that entropy, that secret, into the smart contract. The users then submit bets that are going to be based on the RAM value that's going to be calculated later. After a certain period of time, bets can no longer be submitted, they stop being submitted. Once those bets have confirmed deeply enough to be safe, and this depends on what size of bets you want to be able to support, then the entropy generator submits their secret, they reveal their secret, you combine that secret with the other existing entropy, and you calculate some random values and you select some winners and losers according to the pre-agreed odds. Now the users are able to claim their rewards. Typical design for a simple dab, right? Here is the result of designing your dab in this fashion. You have multiple on-chain transactions, there are plenty of transaction fees at each step, there are minimum practical bets that you can make in this context because you have to cover the cost of those transaction fees. The users have no experience of instant gratification. Anyone who is in the gambling industry knows that that is something that you are always striving for. The user experience for a gambling app like this is that you bet, and then maybe you win, which is not quite the user experience that you're opting going for. And most importantly, if this app were to take off in the current blockchain context, you cannot have millions of users running this app. We're trying to create amazing solutions that are going to scale up to support real-world problems. This is not quite going to work. So here is EtherDice.io on state channels. A lot of the steps look similar. First, the entity generator hashes their secret, but now we're not going to go to chain with that secret. The users are already in a channel network such as Raider. They connect to the gambling operator by the channels. They make a contract for the bet offer in a sub-channel. That bet offer includes the hash of the secret from the gambling operator. The user then selects their bet. They decide the amount that they're going to bet. It's various associated entries. They can generate a random number. Transmit it into the operator. After the operator receives the promised bet, it's guaranteed that it will receive those funds. The gambling operator can release the secret to the user. The balances are updated with either a winner or a loss, and the user can keep playing the end or the channel is closed. Here's what that user experience looks like. Bet, ooh, I lost. Bet, ooh, I lost. Bet, ooh, I won. Here's our results. We had zero on-chain transactions for this entire process of interaction. We did not have to go to the chain once. We could have gone to the chain if any of these steps hadn't worked out. For example, if the user had submitted their bet and the operator refused to respond with the secret, then we would have been able to go to the chain, but the operator would have known that, and we wouldn't have managed doing that. Similarly, with the balances, the user can take those balances out to chain, but there's really no need to. If you're in a state channel network, you can send those around and do other things with them, and that's probably what you want to do. So zero on-chain transactions. Transaction fees, not so much in the picture. These are very low cost. We're talking about sending and receiving a few very short messages, much cheaper overall this entire process than the Google homepage. This cost that's in the network, if you have to pay those other participants to build up the links, that's still a very small cost, and that could probably be absorbed cheaply by the house if you have some kind of margin on the gambling operation, which means you can take very small bets. This is practical to bet micro amounts. Users can bet and get a result right away at the normal web-like experience where you just load a page and get the result barely even notice that it's happening. And most importantly, this level of transactional activity is something that can conceivably support millions of users with only a small level of server investment by the gambling service operator. This is a comparable style of scaling to normal web applications. You have to have a web server that can handle millions of requests, but that's doable and not terribly expensive. So, I think I've run out of time. I think I'm at zero here. So, thank you very much. If you're more, if you're excited and interested in state channels, come find me and let's talk about this more. Thanks.