EthCC 2: Tom Close

yeah hello oh hello hello okay hi everyone my name is Tom clothes and I am the founder of magma so magma is a state channel research and development team that is funded by the etherion foundation and today I'm going to be talking about state channel networks so what I'm actually going to be talking about is our latest research which is on nitro protocol which is a protocol for n party general-purpose state channel networks and in this talk I'm going to talk a little bit more about what that means and then hopefully give you an idea about how nitro works so when we're designing nitro we've been aiming for these two properties you wanted a state channel Network protocol that was both simple and powerful and the simplicity comes in so our channels are independent we don't have channels where you have to do atomic updates across them that makes it easier for people to work with these channels to build wallets that support these channels because when you have a channel you only need to focus on that channel to understand how it's going to operate you don't need to worry about what's happening in another Channel we have a very simple state format one state format for all sorts of states and we all of this is supported by a simple smart contract with nine public functions and the power side this is a protocol that gives you virtual channels and ledger channels so allows you to build state channel networks it allows general applications so you can write little applications that run the executed in a multi-party way inside these channels and that the protocol supports end parties straight out of the box okay so before I go on to talking about that let me start up with talking a little bit about what is a state channel and I'm going to give you a little example here that should capture the essential features of what a state channel is so the example I'm actually going to use it's not a state channel it's a payment channel I say it's not a staged payment channel is a type of state the payment channel is a type of state channel just as simplistic ample so the scenario here is we have two people we have Matt who's in the Hat and tests who's in the dress and they want to execute a load of transfers very quickly between them and they want to do so many transfers so many transactions that it's not gonna be worthwhile than putting all of this on the chain it's not gonna be economical and so instead of doing it all on chain they're gonna use a payment channel so where that starts out is they start off by exchanging a pair of commitments so these things are blocks of data that are signed so start off by Matt sending to tests I've got a commitment we're gonna split five of the coins yours five of the coins of mine and it's signed by Matt and then she replies okay I agree five of the coins of yours five of the coins of mine signed by Tess this is important because now it's safe for them to deposit their money into this smart contract so gonna have this smart contract on chain called the adjudicator it's role is going to be to hold the funds throughout the duration of the payment channel and then to split the funds only according to the last state at the end so Matt and Tess can now get going to start off with Matt transfers one to test so it's now six four to her and she agrees so they've now got both got sign commitment saying that's a new state they can do this many many hundreds of times very quickly they're limited in speed only by the speed that they can sign these these chunks of data and that they can send them to one another so this can happen like very very quickly a lot of that eventually get to the endpoint of their channel where they want to check out their money so they've got they've done like a hundred transactions here to take their money they clay they take the final state so one person submits the final state to the judicata and that signs that starts a timeout period at the end of the timeout period the GDK to then splits the funds and they get their funds back so what's happened here is by using this like payment channel technique they've managed to do many hundreds of transactions and they've only paid for a couple of on chain transactions sort of save themselves a lot of time and they save themselves a lot of gas fees so that's the basic of a payment Channel and that's also the basic of how a state channel will work so what then is a state channel network so in the example I just gave you we had a scenario where these two people want to do a lot of transactions with each other but that's actually quite an uncommon scenario if you're doing payments you typically pay a little bit to a load of different people rather than do many transactions to one person and in the scheme I just demonstrated we wouldn't get a lot of benefit from using payment channels because every time I wanted to do a transaction we'd have to like start with an on chain transaction then we could do a couple of off chain commitments and then we need to do another on chain transaction so we're very limited there like we have to do these two transactions and then if we're only doing a couple of transactions between us then we don't really get the benefit so a state channel network so what I just described there with direct channels a state channel network breaks the link from the unchained deposit to the state channels that supports so with the direct channel matt has done one on chain deposit and that allows him to have one state channel with someone whereas with the state channel network Matt can do one deposit and then open multiple channels and that's the bit that I'm going to explain in this talk I'm going to start off actually with direct channels so I'm going to explain to you how direct channels work in nitro and then at the end I'm going to extend to say how state channel networks work the same thing so in this talk I am going to be talking about these the on tone adjudicator and operations that happen in the Unchained do Decatur and then the off chain commitments and to understand how a state channels work you really need to understand the interplay between these two different things and to keep things simple I just I've color-coded them so the adjudicator is always going to be in blue and the commitment it's always going to be in yellow and the way to remember that is blue is for the blockchain so things that happen in blue happen on chain and things that are happening yellow have an off chain so gonna start off by looking at this commitment so Nitro Protocol as I said at the beginning we have this very simple commitment format this one format supports everything we do so if you're operating Nitra protocol you will be formulating states that look like this signing them and then sending them to the other parties in your channel and in explaining this I'm actually gonna use an example and the example I'm gonna use it's playing a game of tic-tac-toe so this is what I mean when I say these state channels support multi-party applications you can write a game of tic-tac-toe and we have written a game of tic-tac-toe if anyone's really bored now you can just go and play this game of tic-tac-toe it's really exciting so we've this actually works the stuff I'm talking to you about describes how this stuff actually is working today on roxton test net so the commitments this is the starting commitment for a game of tic-tac-toe it's going to start at the top so the first thing that commitment check includes are the participants and they are encoded as the addresses an array of addresses of the people inside the state channel you're exchanging these states and these addresses here they don't have to be actual real aetherium addresses that hold money all they need to be are the addresses that you're actually going to be signing the state channel updates from they could be like ephemeral keys you've generated just for the purpose of this state channel and then after the participants there's a nonce and the nonce is chosen by the participants to like number their state channels it's the way they distinguish between different state channels and these things taken together form an address for our state channel so the state channel address is formed by taking the hash of the participant addresses and the nonce step chosen so it's up to the participants to make sure they choose their nonce so each of their channels has a unique address but it's in both of their interest to do that otherwise things get confusing for everyone so we've got the first few properties the participants the nonce remain constant throughout the the state channel and that's enforced by the framework and I'll explain a little bit later how that happens the other thing I want to talk about here is the app definition so the app definition here is going to be the address of an Unchained contract that defines the rules of the application that is running inside this state channel so that contract itself is pretty simple so those rules that the library that defines those rules has to implement a single function and that function is called valid transition and it's basically saying moving from this commitment to that commitment what are the rules and make it valid so in tic-tac-toe that's going to be things like the board has one more mark on it this turn than it did from last time it's going to be things like if the player moving was crosses they needed to put a cross on the board and not a note on the board those sorts of things are all defined in this like application library and that's the thing that you write if you want to actually write an application that runs inside one of these state channels okay so here I've got the second state in this state channel so the first state was what player a sent to player B when they're like hey do you want to play a game of tic-tac-toe and what we're looking at here is B's response and the way this is interpreted is be saying yeah okay I'm happy to play a game of tic-tac-toe on those terms so what are the changes what's happened so one of the things that's happened is the turn number has increased and that's one of the rules of these state channel commitments the turn number must always increase from one commitment to the next and it's the higher and in the end when we get to challenging on chain it's the higher turn numbers that basically trump the lower turn numbers the other thing that's happened is the signature has changed obviously because B is sending this state to a so it's now a sign with B signature and one of the things in Nitra protocol is it's very very easy to figure out whose turn it is and who's moving so basically the rule the Nitro is that players must take turns so in our example all the odd-numbered states are going to be done by player a and all the even-numbered states are going to be sent by player B and this generalizes easily to like three or four or five parties you just have like more parties in your list of addresses and then you can figure out who is the signer at this point according to the turn number okay so that's just that's the state so if now got these two opening states a and B have done this like opening handshake AIDS proposed the game B said yeah okay I'll play that game and a and B both hold sign States from both of them saying they're about to play this game and have each agreed that they're starting total should be 5 5 so now they've got the stuff which allows them to safely deposit their cash into the adjudicator on chain so let's look at the adjudicator so in the gtatyr in this talk I've simplified it a little bit they're actually 9 methods but in here we're only going to talk about 6 and I'm going to introduce all of them to you throughout the talk the adjudicator is basically a very simple system of balances so we have an address we have the balance which is in this example is just going to hold a single number of coins but it could hold like multiple different types of coins and they've got an outcome which will introduce later so they said it's now we're now at the point where it's safe them deposit so let's see how that happens so the first person to deposit is a and it's a little bit subtle where it has to be a but it does have to be a has to be a because they have higher priority in the order so like if it all stopped at this point a would get those five coins back out again and not B so a goes first once B has seen a transfer has gone through B can then also deposit so the only thing that's stored on chain is the address of this tic-tac-toe game and the total number of coins that have been deposited into it and it's the ordering that allows them to safely do that we don't have to store who sent in the coins we just need to store like the total number of coins there so once this has happened they can now finish the setup phase of the game and we basically have one more back and forth so a sends a commitment to be increasing the turn number changing their signature saying okay basically what this is saying is okay I see the coins the game is funded I'm happy to proceed and be like it's like yeah okay I see that too I'm happy to proceed to so now in a point where we're actually ready to start the game and then this is the first state in the game so as you can see we've got the board there the board is encapsulated in the state as I said before like that updater is going to be interpreted by the game library so the format of that updater is basically specified by the game library here we've only got two things we've got the stake which is how much they're playing for and we've got the format of the board so AIDS gone first their crosses have gone in the middle the only other settle thing here is that the default outcome has changed and this is part of the I guess the game theoretic design of the game in this situation a has just moved and they've updated the totals as if they have won and that's kind of important because if B were to stall in this position it's B's move and basically what this is saying is if you don't move you forfeit and this change in the default outcome would be encoded in the rules of the games if you're designing games that run in state channels this is something you need to think about at each stage anyone can start moving so each stage you have to have like what is the fair outcome of this game at this point and that is part of designing your game to run in a state channel so we can we continue so B makes a move it's not great move but maybe they don't realize that yet and similarly they have updated the default outcome so that if a were to stop at this point B would win so we continue playing the game so it makes another move he makes another stupid move and finally a makes the winning move so at the point in this state channel how I've designed it you only get to play one game in in real life and in fact in the example online you can play multiple games but what's happening here so the updater is into a new state into the a has one state and the default outcome is now reflects the fact that a has won this game and finally we set this extra property called is final to true and the is final thing as I explained in a minute is a thing that allows a and B to skip the timeout period when claiming their funds on stage normally you need to have this like exit game in a state channel so that people can submit later state you can set it up and we've set it up so that you can skip that basically if both players agree and both players sign off on the fact that this is the final state of the game you have to be really careful with this though if you sign it before the end you basically broke in your state channel and once once somebody's signed this is final state then the state channel is basically closed and it's not safer players to continue playing so B then echoes that state back they've also so it's final states true they increase the turn number so if now in a position we've got two states with its final it's true both players to find signed off on the fact that this is the final state so now let's see what happens in the g decatur so now they've got that final state they can then claim their funds and chain how does it actually work well they use the finalize method so this finalized method can be used when you have this thing that we call a conclusion proof which is every player having signed in its final state so they send commitment number nine and commitment number ten to the finalize method they did you decatur will check that both of those have is final and that the two of them were about a transition between each other and at that point once it's checked that it puts the outcome from the final state into the adjudicator so we now have this this situation where and if this panel is closed channels have the property that once you've finalized one outcome you can never finalize another outcome so this channel address is done like if anyone created another channel with this address they wouldn't be able to finalize anything it's like constantly written off which is why it's important to have the nonce to be allow people to generate new numbers so that's great the outcomes now unchain how did the players actually get their money so to do that they use a transfer method so what's going to happen here is that a it's gonna transfer six coins out of the outcome into their own address when that happens it updates like this so you've noticed that the balance of the adjudicator has decreased by six a now has six in against their name and the outcome six has been removed from that outcome and then the next thing that happens is B does the same thing so we're now in a situation where the tic-tac-toe has no funds on chain a six B has four note that that outcome it's not empty it's like a done outcome I put that little cash there to symbolize the comp another outcome into that channel and in the final step is that a can withdraw their funds out of their balance so there's this withdraw method so a can call it withdraw from address a an amount of six coins to a destination which they can specify anywhere they like it could be like their aetherium address it could be their friends aetherium address it's where they want these coins to be sent and they have to provide a signature and the signature is signed with the key that they were using for for signing on the channel it could be a different key to the one that they actually send this transaction with and after that those funds disappear those funds are transferred out adjudicate a contract they go into their aetherium address so notice that something like slightly subtle has happened here we have two types of addresses we've got participant addresses there are generated by the elliptic curve digital signature algorithm they have corresponding private keys and that means that they can be withdrawn from because in order to withdraw from an address you had to sign it with the corresponding private key we also have channel addresses which are generated from hashing participant addresses together with the nonce they have corresponding channels and they can have outcomes and the opposite things are also not true so you can't put an outcome into a participant address assuming that you haven't broken the hashing algorithm and you can't withdraw from a channel address assuming that you haven't broken the signature scheme so yeah so it's important to anticipate those things it's also important to appreciate that just by looking at you can't see which a which on chain you don't know whether the address is a participant address or a channel address unless you know the corresponding participant or Channel so I'm going to talk very quickly about what happens when things go wrong so I mentioned before that like it's possible that one of these players would want to stall so in this in this situation it's B's turn and if you play for this game of noughts and crosses you'll realize that B is actually lost in every scenario there's no way that you can win this game if a plays optimally so maybe B wins maybe B realizes that and B is like do I want to keep playing this game maybe if I stop playing this game I won't lose lose the game I'll just get my money back and so this is like a common feature of state channels every state channel implementation needs to protect protect against this situation so the way that we do that so a is sitting there a hasn't heard from being a while it's like is B gonna move again which be just like stop because they don't want to play this game anymore and they think they're gonna lose so in that case a can challenge them on chain so this is the state of the adjudicator after the funding in the middle of a game a can challenge B so to do that they cheat they call the challenge method and they provide the last two signed commitments and basically what a is saying here is like hey B you sign this commitment and then I made this move and now it's your turn to move again you need to move and you need to move on chain otherwise this game is going to wrap up so it's like a is laying down that challenge to be it's really important here that a is provided one thing that's signed by B one thing that's signed by a and then it's B's turn to go next so what that does is that starts a timer and it puts that commitment on chain I've kind of abused the notation here a little bit of there'll be a separate sub challenge section somehow but that commitment would be stored on chain time would be started is then on B to respond so if B responds before the timer is finished B responds by providing the next commitment the the adjudicator will check that that is a valid move it will check that it's a valid move using the application library and also some checking some framework rules like the turn number has increased and stuff and if it all that checks out then the challenge is canceled and we go back to exactly the situation we were before and we can continue off chain which is kind of nice it means that challenge is not terminal you can recover from a challenge in responding to this challenge B is provided with a the exact same information that they would have done if they just responded off chain the other option here is that B doesn't respond if B doesn't respond then we end up in a timeout situation when it times out the outcome from that final state is put on chain so there are two ways that an outcome can get on chain it can either be finalized if everyone signs off on off in a final state or an outcome can end up on chained to an unanswered challenge and you note that this is where it was important that a that the rules of the game took into account there like a wins in this situation is treated as if B forfeits so now going to talk a little bit about the network side of things and ledger channels so you have given you the overview of like how direct channels work ledger channels are actually very simple and they come from asking this one question like in everything I gave you so far the outcome of the channel allocated funds to participants what if that wasn't the case what if the outcome of the channel could allocate other channels and in fact how to set things up we can't stop that happening no one can tell whether it addresses a participant address or a channel address so what we ended up in this situation so you have some channel ll4 ledger channel it's holding ten in its balance and then somehow it's got this outcome on chain where it's allocating six to tic-tac-toe anyone could then call the transfer function and end up in this situation where L only has four and tic-tac-toe has six and the observation here is like this is exactly the same as what would have happened if the channels have if the participants had funded this game directly so like it's exactly the same situation as if I had put in three and B had put in three so in this situation what would that actually look like off chain so imagine we've got this commitment here so I've got a new commitment this one is not running the tic-tac-toe application this run is running a special application called the consensus game the consensus game is basically a game it's just a force majest a nitro application it's defined by the game library like like tic-tac-toe Wars but this has a special rule which is the rules of this game is one person can provide can propose a new outcome and then the other person can either accept or reject it I've added at the bottom there a little diagram from the paper I'm not going to talk about that too much what this means the square means the adjudicator so this means the channel L is allocated 10 in the adjudicator and then it's default outcome is 5 to a and 5 to be ok so with that we already have this l commitment I'm now going to start off the rock paper sorry the tic-tac-toe game exactly like you did before so this is AIDS proposal to be hey do you want to play tic-tac-toe then this is B's response yes I want to play tic-tac-toe they're now both holding a state from each of them this is the point where if we were going to fund this one chain it would now be safe to do so but we're not going to do that we're going to try and fund this through the ledger channel l so how does that work well start off with a proposes a new outcome for the ledger channel and in doing this outcome they've reduced the existing outcomes by the amount in the ledger channel so sorry in the tic-tac-toe game so in the tic-tac-toe game for some reason here they're not starting with equal totals a is starting with 2 and B is starting with 4 and so they've taken two of A's total four of b.split total and allocated six to the tic-tac-toe game and if B wants to fund this off chain they reply and they confirm and the rules of consensus game is once B is confirmed that's a new outcome so a and B have just funded this game off chain the reason it's funded is if push came to shove and they didn't agree they could take this ledger commitment to the chain and get back into that situation I showed you at first where L allocated funds to T and then move funds out of L entity so yeah this is what's happened in the in the language of the paper we've funded this new game we had this game that wasn't funded and now it is funded so a and B can then play tic-tac-toe I'm gonna jump back in when at the end right at the end of the game so what's just happened here so a sent the final state to B be agreed and sent it back we can now close this channel off chain almost exactly the same as we we opened it a proposes a new update that incorporates the outcome of the game into that channel why would be sign this so like B is losing money in this game B didn't win the game of tic-tac-toe be lost out but it's still in their interest to sign this because if they don't sign this that money can be taken them from them on chain anyway and by signing it they say both of them some on chain fees so it's in both of their interest to sign this even though it's actually disadvantaging be somewhat and once that's happened we no longer need the tic-tac-toe game the tic-tac-toe game is done we can throw it away it's useless so it managed to open that game unchain and close it okay so our state general networks that simple no they're not but it's almost that simple so I've skipped over a few details as I said there are actually six methods in the adjudicator you have to account for things like somebody challenging with a really old state and be able to refute them in that case you have to be able to there's some slight subtlety it's around like allowing them to respond from a different move if people provide multiple moves with the same turn number how do you handle that that's um you have to handle in the protocol and then there's also this idea of virtual channels so all I showed you there with ledger channels so a and B between them can I can have multiple channels for the same deposit but I haven't yet showed you is how if a and B don't have an Unchained deposit but are connected through see how they can open and close a channel off chain it turns out to do that you need a different type of outcome and you need one more method on chain the claim operation and if you're interested about that then you can either read the paper or the code for this all of this behavior is coded up so you can read the contract one chain that implements this that's all I got thanks for listening [Music] [Applause]