DAPPCON 2018: State Channels Today - Tom Close (Magmo)

Transcript

right hi everyone thanks intro I'm Tom so I'm pretty new to the blockchain space I started working in the blockchain back in November before that I led the engineering team at SSD which was a YC startup which was acquired by square earlier this year and before that I did a PhD in quantum computing which was a very long five years of my life so at magma we are a state channel research and development team we've recently published the force move games framework hands up if you've heard of this not very many so this this is not the crypto paper of the year but it's

probably not even the state channel paper of the year it's probably almost definitely one of the top five state channel papers published this year that's about as much as I can say about it anyway so I'm going to be talking a little bit about this in this talk so for the structure this talk I'm going to talk a little bit about payment channels and I'm gonna go over the basics of what a payment channel is and then I'm gonna explain how state channels are different from payment channels and finally I'm going to talk a little bit about the force move game framework and how that can be used for building state channel applications okay so in order to explain payment channels and state channels I'm

going to introduce some new friends so it's customary to use Alice and Bob in these situations but like I figure that they could do with some time off so I've introduced three new characters here for you and I've tried to make it the names easy to remember the characters by so here's Matt how would you remember that that's Matt yeah so that's Matt in the house how do you remember that one's Tess yep and how you remember this one's Jude Jude's in the nude okay so we're gonna have a little bit of test because I know it's like mid session after lunch everyone's probably asleep so start off who's this

okay let's try a bit oh come on get some energy in this room who's that who's this he says that one well then okay so now let's go home with the information of payment channels so payment channels have been around for some time I'm just gonna do a quick recap of how they works a lot the patterns that used in payment channels are also used in state channels so payment our interaction starts so we have Matt we have tests they want to transact with each other off chain and they're going to be doing a lot of transactions they're going to be doing like hundreds of transactions they want to do those transactions very quickly and so it's not going to be feasible for

them to do all their transactions on chain so the way they start off their payment channel is they put their cap third coins into a non chain contract so left is on chain right it's off chain and so they have their coins in this contract which I'm going to be calling the adjudicator once those are there they can start exchanging agreements about how those coins should be split at the end so this first agreement says five goes to testify goes for Matt Matt sends that to Tess he signs it that's his signature at the end there and Tess replies for the same state signed with her signature so now they both hold sign states that they're both agreed that the front and the chain are going to be split five five so happens next is Tess wants to update the state so maybe Matt bought

some before her and she wants to let him know that like it's now four six so she sent a state over to him he echoes back the same state with his signature on it so they're now at a new state that both agreed the funds are now going to split for six and they can do this many many many many many many times and at the end say they've done 99 turns in this case they want to go to the chain and they want to get those funds back so it's finished up that is eight to Tess and two to Matt so one of those presents that contract to the adjudicator unchain and that starts a timer so that timer starts ticking when the timer has resolved they can then split the coins according to the final state that they present it to the blockchain

so let's have a look at their common features here which will be common to all the state channel staff and payment channel stuff that I talked about today so we've got an untrained deposit we've got off chain messages which are versioned and we've got unchained settlement after timeout so that timeout is crucial to making this system secure why is that time I important well let's have a look at this situation again so in the final state Tess had 8 and Matt had to where's in the second state matt had 4 so it would be advantageous for Matt at this point to try and cheat and present state number two instead of state number 99 so if he does that he takes state number 2

gives it to the blockchain the blockchain doesn't know that's not the last state at this point so it starts the timer the timer starts ticking and Tess has that time to respond she can send the latest state there and then the contract can tell it wasn't a later state it just compares the version numbers and it cancels that challenge and resets resets and the state to how it was before so that in all these systems the timeout is key you need to give someone a time to like challenge the state that's actually also shared by plasma and a load of other off chain solutions so that was a very basic payment channel I'm now going to talk about hash time lock contracts so hash time lock contracts are the way that

payment channels become useful because the moment the only thing you can do with the payment channel it's do loads of payments in one person but it's actually quite unlikely that you want to do that it's very rare but you want to do hundreds of transactions with just one person you more like want to do hundreds of transactions with different people and you don't want to do it on train deposit with every single one you really want to do one chain on train deposit and enable loads if of chain transactions so this is where hash time lock contracts come in I'm gonna do a very quick review of hashes so we have these two things we have X and we have Y and they're related by Y it's the hash of X and you can undo that or you can rewrite that statement by saying X is the

inverse hash of Y or the preimage of under the hash function and the point is that the hash function is very easy to do and the inverse function is very hard to do so the only way you can provide X is if you knew X and you hashed it to get Y originally so the way we add hash time-lock contracts the payment channels is to add an extra kind of statement into the chain payment channel so so far we only saw things where you had five to ten three to Matt now we can have two to this hash time lock condition and you think about that as a conditional payment so Matt will send to to test if the inverse hash is revealed

before a given time so you think of it as putting a locked payment in the payment channel and when the key is revealed it becomes the real payment so you can make that payment conditional on the revealing of the hash preimage and this enables multi-hop payments which is what makes payment channels really exciting because it allows you to do one on chain deposit and pay anyone connected in the payment channel network this is what lightning does this is what Raiden is doing so very quick look at this so now got Jude Jude wants to transact with tests that dude has an on chain contract with Matt and Matt has an on chain contracted test so Jude starts

by generating his random X hashes that to collect to calculate Y puts his hash conditional payment in the channel with Matt Matt puts a conditional payment in the channel with tes tes is like I see the payment is here somebody's going to give me the two either you want to send me if somebody reveals the hash the preimage so so Jude is like here's the key tes unlocks her payment and in doing that she gives Matt exactly the information he needs to unlock his payment so we've managed to connect these two payments in a way that their atomic like we reveal the hash that pre image to the hash and they both go through or neither of them go through

and that's what enables payment tunnel networks so that's a very very brief overview of payment I'm now going to talk about state channels and how you can think of state channels as a generalization of payment channels and in what way that's true so the first concept of a state the first step towards a state channel is actually just introducing conditional payments so in fact we already had a conditional payment in payment channels we had mass Matt sent to to test if if oh dear to ifs wait if the preimage the hashes revealed before time t state channels can generalize that by making more

conditions possible so for example we can make the payment if England win the 2022 World Cup which will probably happen or and and just to say that like what I mean is like the way would make that actually feasible it would pick an on chain Oracle that we're gonna trust with that result and then in 2022 either the payment happens or it doesn't so we could also make a conditional on Bob winning a game of chess being played at a given contract address and you'd have to tell the payment channel how to understand who'd won but like that's a well-defined thing that can happen or and this verb begins to get even more exciting is if Bob wins an off chain game of chess played with a given ID so

the idea there is like even they were playing this game off chain we could put it on chain and then we can make that a condition on the payment going through and then of course we can join in all these conditions with like boolean logic so we can begin to make arbitrarily complicated conditions for payment channels so this is like almost a state channel network in itself it you can almost do arbitrary state channels and I think this is basically what the seller network does but don't completely quote me on that because I don't completely understand it but like this seems to be like these conditional payments you can do almost everything you need to do with conditional payments but you can also take it a step further so with the

conditional payments we'd defined how much was move and where it was moving to beforehand and then we were just giving a condition about whether that payment should go through or not so we can actually do something more general in that you can make a delegated payment which is a term that I'm just using for this I don't know if there's an actually actually accepted term but there you have a statement at the forum we're gonna send money to an address that's going to be determined for an amount that's going to be determined for a condition that's going to be determined and all of those conditions could be looking at something on chain so it could be like I will send an amount according to the exchange rate of eath to some other token at that given point in time the address could

also be something else most likely what you'd have is one contract which determines all three of these values and to give a quick example of that how this could work I'm gonna give the example of virtual channels virtual channels is to state channels what hash locks payment networks are to payment channels so what virtual channels allow you to do is if we've got this pair of people with an on chain adjudicator and an on train deposit and a open channel then we can allow the two people at the edge to construct a new channel a virtual channel without any on chain payments and it's really exciting because now that channel is like any

other channel in that they can do arbitrarily arbitrary things in here including supporting new channels including playing chess including anything you might normally do in a state channel so this is like this this work here was actually published earlier this year by Perrin which the team out of damage dat and Warsaw this is really exciting because this makes state channels really exciting it means that state channels you could have interactions in applications where I want to play a game with you I can open the channel off chain I can play the game and I can close a channel off chain so you could do entire actions off chain like playing a game of chess backed up by the chain let me quickly show you how this works I

think I'm running out of time so the way that would do is you'd put delegate agreements so they had five five channels they agreed to ten of their funds delegated or delegated to the outcome of this channel so then student s do loads of interactions in that channel in this case it's just a payment channel they come up with $2.99 then they update these channels to reflect that notice that Matt who put in five five on each arm to start with has ended up rebalancing his funds so he still got ten back but he's taking eight from the Armagh dude two with the arm from TAS and he's allowed them to rebalance so you can rebalance off chain so that was

state channels and gonna very very quickly with through what forcemeat games are so when we were looking at these things which you can delegate to there are certain rules about them that you have to follow so like if the thing that you delegate to might never finish then you're in trouble like you need a way of forcing that to finish or like if my opponent goes offline and I can't like close out that delegate game that's also a problem because I've like locked my money forever so what the force move game framework does is it gives you a safe way of building little state off chain interactions that are safe to delegate to so like you can delegate too many things but force mu games give you a way of building things that are safe to delegate to I'm not going to go

through this this is like how you would say play rock-paper-scissors the basic idea here is instead of sending states of balances you're sending signed bundles of attributes that represent the state in your game and you can think of your game therefore as a state machine so when you're making a force move game what you do is you define a set of states and a set of transitions between the states that define the interactions you can take off chain and therefore smooth game handles all the stuff about challenging and making sure the game will finish so writing one of these things you just write a game library with a valid transition function it looks a bit like this and we have a

proof concept that we worked on at the moment where we're building the game of rock-paper-scissors on the for Smoot game framework including all the user interface stuff so this is a work in progress but we're doing it in the open if you want to have a look have a look on github follow us along you can see a slight thrashing around and making a mess of it and maybe even help us out and point us in the right direction so that's all I got thanks for listening you can find more about it at mad no comm and the work so far has been funded by James Bickle and L for so many thanks to them thank you [Applause]