Liam Horne | A secure state channels framework for Ethereum | CrossLink Taipei 2019

kind of like I'm gonna in really quickly on one specific part of state channels that kind of set the understanding of how state is progressing the state channel and generally what it is and I'm gonna zoom out afterwards and just talk generally about the project that we're working on and yeah hopefully give you a general overview of like what state what's going on with state channels so yeah and then also I would encourage you if you're following along and like you don't get something it makes no sense or you just curious about something else just you know raise your hand and we can make this interactive as well so yeah let's get started so yeah this is just outlining what I basically just said we're gonna talk a little bit about the lifecycle of a channel really briefly just so we're on the same page the state in state progression protocol some components that you actually need to make any of this stuff work for anybody in production and then what's going on today and then what are we doing in the future so e Li fire state channel life cycle just so that we're on the same page here's like the easiest way that I can explain a state channel in like a nice graphic if the animations work so state channel li5 you got two people it's call them Alice and Bob and they have some coins and the idea is what you want to do is put some coins in a contract so you lock them up for some amount of time and then off chain send messages to each other updating the allocation of those coins so like let's say that says five they're on each side the beginning that's five five and then Alice says hey now actually at the number two version of this now it's actually watching it's still five five in this example then it's four six number three and you know so four six and you do this over and over and over and over and over again until let's say you're done this Nick ninety eight times now you have like eight for Alice to for Bob and all this stuff is just like messaging like they just sign messages back and forth off chain there's no transactions nothing like that and at some point they're like okay we're done here we've we've moved on money around we're happy with what's happened eight for me two for you great and so they take the latest version of this tell the chain hey this is the allocation you know worst case if you need to that's a timeout to you know ensure this is the latest version of it the contract says that's true and then dishes out the money okay so level setting that's basically what a state channel is about off chain updating state without using the chain at some point later on you put the latest version on or equivalent eally you tell the chain what the latest outcome is and then the money gets distributed back out on chain the nice perk obviously is it's instant all these messages and you don't have to worry about confirmation time stuff like that so let's say channel so I'm gonna now dive deep very quickly into specifically what is the standard around which you actually update that state so you saw like you know version 1 version 2 version 3 I'm gonna talk very quickly but specifically what that protocol looks like so let's talk about what's actually in the state of in a state channel what are you actually storing and there's a bunch of fields and I'm just gonna say in English what each field is and you can kind of get a bit of an intuition for what's actually being exchanged in each one of those back and forth boxes that are signed by each person so these are pretty straightforward things I'm gonna just go through them but they're pretty straightforward obviously you need to know who's involved in a state channel you have a fixed group of people it's like Alice and Bob is two fixed group of people maybe you have Alice Bob Charlie it would be three fixed groups of people and you need to know who those people are you need to know what chain you're on this is pretty straightforward you and maintenance in whatever you need to know also some unique identifiers for the channel so in that one example I just gave that was like some payment channel let's say it was the you know unique it a unique identifier I've just you know anything at all this is just to make sure that you can't replay the same channels over and over again you need to know how long of a challenge period is this channel going to have if you need to go to chain you want to know you know what version number is it again this is pretty straightforward stuff if you're going back and forth over and over again each time you hop Alice signs bob signs out signs Bob signs you increment some number so you have a latest version number you also have this notion of the outcome so I just gave you an example earlier where it was like Alice had 4 and Bob had six that was both the and the state in that example but in a more complicated example you might imagine the state being something let's say like a tic-tac-toe board and then the outcome would be who would be the winner so you can imagine in the game of tic-tac-toe if the state is a state with three X's in a cross then the winner is whoever is player X and the outcome would be such that they get like ten coins and the O player gets zero coins so the outcome and then you have the state and you'll want to store the outcome at each state additionally you want to know is it's a final state which is obviously in tic-tac-toe it's like hey is this a cross is it a vertical cross or is it still a game that's in motion so this is also something that each one of these states has and then you want to have the actual definition of the state machine like what's going on is it this tic-tac-toe game is it a payment channel it's a backgammon game is it roulette whatever the actual thing is which defines this a channel and I'll show some function which explains what that looks like and then this application-specific data so this is like literally like where are the X's in the o's and the tic-tac-toe board what are the actual values of the application so yeah and then obviously the signature for each person so this is like pretty specific right I literally went through every single list of the fields in a state on a state channel but I think it's useful to keep this in mind that every single time you pass a message back and forth between people all of these bits of information are encoded within the message that's sent and this is the standard around which we've basically gotten now within our state channel this kind of community for every state update so yeah it's pretty specific but it's pretty useful to kind of just generally keep in mind that these are the specific fields that you can store so great here it is the same thing I just said but encoded with some data types for your own reference you can see it's pretty straightforward what each type represents and you can also notice that these things are actually is you can kind of split them some are fixed every state update so you can see for example the list of participants always stays the same the chain idea stays the same obviously the the unique identifier the definition of the application but some things change right they take that to a board state will change the signature changes and again it's just useful to keep in mind what each state has so another interesting component of the state channel protocol that I've kind of glossed over but it's kind of unique to the way that we've designed the system here is that each state is signed by just one person and the way that it works is each state has a particular person that's expected to sign it and it's it's you can use this calculus formula to calculate it it's basically the participant at the index of the turn number modulo the list the length of participants so this kind of fancy way of saying you take turns Alice Bob Alice Bob Alice Bob Alice Bob you keep going in a cycle and if it was three people like Alice Bob Charlie Alice Bob Charlie Alice Bob Charlie and each state again is signed by just one of those people and it's exactly one of those people that's expected to sign each state and this is also important for a number of reasons I'll get into but basically this means that you always know who is expected to sign the next state which means you can force somebody on the chain to make that next move to sign the next state and if they don't and the timer passes on chain you know that that person basically forfeited their chance to progress the state some other stuff you notice is pretty straight forward but obviously you have to be it has to be your turn if you're gonna sign the state you can't sign some other person's state you should go without saying but this is just an explicit way of showing that you can't sign some other person the state and then a nice part of this system also is that you can exit at any point in time if you're done you don't want to play anymore you can say this is final I'm setting is final flag to true I'm done and if the other person also signs the is final flag is true then you have to or more generally n sequential states where they all say this is final and so you can basically consider this to be a conclusion proof and to this channel will be done and again what an important part of the system that I mentioned is that you should sign the outcome yet each state which means that at any point in time the protocol could break and whatever the last state is that was signed needs to encode who gets the money so an example with tic-tac-toe is if I just placed my X the outcome is such that I win and this is this is interesting because it means that if no o is ever placed ever again that basically means that o is forfeited they've left and so it should make sense that I X as the last person that made the move should be considered online available and I should be the winner so you encode the outcome at every step of the way at no point is there some limbo state where it's not clear who gets money every single state encodes it and so you can see that also means that if you want to just like exit you can exit and this is a basically equivalent to forfeiting in this case so again these are these are pretty specific points pretty simple points but shockingly these are the types of things that trip people up when they start to really thinking about channels and they can understand what happens in every scenario the other part of the whole system is that we have a very simple way of encoding what is a valid state transition and that is basically literally we have a function called valid transition between any two states so 1 & 2 2 & 3 and a state transition is only valid if the definition of the state machine which I alluded to earlier has this function valve condition for which the two subsequent states went past in return true so most basic possible example is like a counter how do you write a counter app here's how you do that the counter is an application where every time you update the state you just add the number 1 to whatever the last counter was so you can see here if I can use the red dot thing counter 0 is good 1 is 1 more than 0 2 is 1 more than 1 so this is a good transition but this is a bad transition because 5 obviously is not 1 more than one so you can encode literally any arbitrary pure solidity code and more generally speaking like static function that you can run in the EVM using this general function and there's also nice ways of encoding this so that it looks prettier so you can write like action based function signatures but generally speaking you just need this function to return true and that allows you to write any arbitrary state machine in aetherium for which you can fit this within one block so again pretty straightforward but this is exactly how you write a natural application first a channels great so that was like that was the zoomed in part very quickly I said okay here's exactly how you update state this is one part of a much broader system and that system is this generally speaking this is like the set of all stuff you need to kind of think about witness and state channels land and I just spent like ten minutes talking about to be honest at a pretty high level even still the state progression protocol so reason I'm talking about this stuff is I want to try to convey a bit of information about what are all the things you have to think about in state channels and how they can very quickly get complicated and and and hopefully give you a bit of intuition for when you're thinking about the overall system what you can let google or go to learn more about so I just talked about this there's a lot more Doc's and this talks online do in a lot more detail now I'm gonna give you a bit of context on what's going on with all the rest of this stuff with our overall work so that's dive into that stuff I break this down into three categories one is the actual protocol and contracts like you know the quote the cool cryptography stuff then there's a client hub which is more of the engineering challenges that are involved with building a state channel system and production which is like the software that implements all this stuff and both for the client the users if you're in a browser phone whatever and the hub on the back end and that's facilitating some of this work and then and then the browser wallet ui/ux all the other cool stuff they even think about when you're building an actual end-user application so I just talked about the state progression protocol like I've said that's this thing take turns your sign States one signature that's an app definition so on and so forth but what's this thing there's also a whole other protocol for how you fund those channels so I abstract Lee just mentioned a second ago that you have some channel with some money in it and you progress it using the general protocol I described but how do you actually get money to be assigned to a particular channel it makes it kind of makes sense if you have one contract being one channel right because you just put money into the contract and it's like a deposit and withdraw and seems fairly straightforward but it gets a lot more complicated when you wanted to put money in one time for some set of people and have many channels perhaps running in parallel maybe thousands of channels at the same time and so for this we have a protocol we call it right now the Nitro protocol you can go to our repo which I'll show in a second look at this in a lot more depth but this is the other part of the system and we have this now completely specified and implemented and this is where it gets a lot more complicated this is a picture from the paper that defines roughly speaking how you go from having a contract with you know a and B having five and five going through this protocol that we define you don't need to understand what these pictures mean exactly this is just from the paper your situation when you have a channel now with some money allocated to it and this protocol we're gonna hopefully do some formal verification on later this year then there's the part above that which is what exactly does do two people say to each other to actually actually operate this protocol and so for this we have defined an exact protocol between some number of participants through a hub precisely which message is sent to each other participant in order to fund a channel in accordance to this general protocol which is like the mathematical description and again this is online as well you can check it out and I'll share some links at the end there's the other part of a state channel system you kinda need to be aware of the part on top of that is actually the code that implements it and this is like where the engineering part gets quite fun this is what we call kind of a state channel client we've designed ours to run in the browser and it's a pretty interesting software because it needs to both implement this protocol in accordance you know to this this over this overall design and you know work in the browser store State on behalf of the user make sure it doesn't draw up state and all these things and then finally once you have some software which implements all of that the next thing to think about is how do wallets like a meta mask actually use it in such a way that gaps can communicate to their wallets to take advantage of channels and so here is there's a picture I've added which shows the roughly what the API looks like as of today between an app let's say like a browser window and a wallet let's say meta mask - how they communicate to one another so you can imagine like an example as an application might say hey I want to create a channel so it sends a Chan underscore create message and the same it's kind of similar the way that web 3j s works if you're familiar into meta mask meta mask is running the the client code that I mentioned and meta mass is expected to basically follow the protocol exactly as specified using that software and then return back to the app saying hey the channels created and now you have this new object to use in your application and so this is a whole other a domain which is interesting and you know a lot of interesting problems to work on here and then if you're interested in just purely the design aspect there's also like a whole bunch of questions about what does an end user actually look at when they're looking in the bra and in the browser at an application with channels so I think this video should play here's the connect Die card UI it's to be honest it's kind of boring which is probably good for for a UI of the stuff but it allows you to send money instantly with no pop-up so you just click a button and some payment happens and what's going on in this gif is basically and I'll play it a second time is basically a message is being sent into the wallet the wallet runs the code to run the protocol I showed earlier message gets sent to the other guy it's signature on the state showing you know I want to update what the state of the application is and then a payment is made and you can see that the UI in the end of the day is pretty basic so yeah this is like a full stack of state channels very quickly just kind of giving you a broad idea like when we'd say state channels what the hell is actually happening it's all of those problems I'll bundle up together great so now I'm gonna jump a little bit over into specifically some updates from us on our team that we've been working on so the first thing is it all works which is an amazing accomplishment the stuff actually is today on main net the most like I guess notorious example is that the Connect company is currently running that exact application I just showed you on main net with payments going through their users on the die card application which is what I just showed and they're trying to build a bit of an ecosystem around this so they're trying to get some applications to build on top of them and they're basically running a client on top of our client at the moment they're trying to get some infrastructure built on top so connecting into in fewer and dramatic Network and they're trying to integrate into wallets so we've already some work with metamath they're working with a bunch of other wallets and we're trying to build a bit of an ecosystem around this a channel is protocol and I think have a tweet yeah and this is literally yesterday actually he did a proper announcement you know after we ironed out all like the bug someone not saying you know hey this stuff actually is live right now you can use it today so if you guys want to you can just like Google connect sky card and you can see all this software running under the hood so that's like the first nice update this stuff Sun maintenance ekend thing is we're growing the team so one thing that we've been doing in state channels world over the past little while is we've noticed if as many teams all working on the same stuff which maybe you guys have noticed especially people that work in its industry like there's a lot of overlap in this industry where people will do the same work and so we've tried very hard to try to create standards and the protocol I showed earlier is the standard state permission protocol across all state channels teams right now and and so one thing one example of that manifesting is recently the open source project which I didn't really discuss so much in this talk kind of factual has merged with this company called magma for which we've been running two separate protocols for state channels and we're launching this new project called state channels org and there's a bunch of people now which is pretty awesome to see like across multiple different companies all working on this open source together which is great you can see us on the internet at github comm slash state channels there's like I think now is about ten people working across the stack on the wall at integrations and the protocols on the contract itself and formal verification of these things there's a lot of cool problems being solved across our teams and this is actually like a pretty awesome accomplishment because like I mentioned there's been so much redundant work in this industry and now we're really starting to get into a stride with a single implementation of that single standard which is great news so great so what are we actually working on what's like the next stuff that we're focusing on that's of interest to us right now here's the stack to reiterate within each section here's like some stuff we're doing so for the protocol and contract side we are doing like I alluded to some formal verification of the actual state progression protocol so we want to guarantee this property at any given point in time any participant will be able to basically exit their money in a fixed amount of time so this sounds like you know pretty straightforward property of channels but you'd be surprised like I don't think any channels construction anywhere has this may be lightning but like but like in especially in etherium so we spent a lot of time actually modeling the protocol we've come up with we used a tool called TL A+ which is very useful for finding weird edge cases in your protocol for which this property might not hold we even found some bugs where like you can get into front-running scenarios where one person observed the transaction be able to put on chain and the other has to and the other will then try to like basically front run that with a different transaction causing an error and it gets pretty hairy but we're trend are really hard in this protocol so that you have an absolute guarantee that anything that follows this protocol will not lose you money and specifically will have this property so so this is the nice benefit of standardization as well it actually pays off to do this kind of work because we're certain this is gonna be the standard a progression protocol other stuff we're doing is that we now have a Research Forum so if you're interested in any of these things we have a forum now the website is researched at state channel star org you can go there we have like all the people in the state channels world checking this thing getting email updates so if you have a question you want to ask or an idea or something you want to poke a hole ad in the protocol we're now like more actively iterating on it so we're kind of creating our own separate state channels world outside of like the pure aetherium world where we can start discussing and coming to conclusions on technical details of the protocols this is also a pretty cool thing another thing that we're doing is we're making this stuff wicked fast and we could cheap so you can see we did like a full deep dive into the contract code that we had for running this protocol and then the past like a month and a half or so and we reduced the costs dramatically for both the happy path and the challenged path of a channel so you can see in the happy path now I used to be quite expensive and now we've we've I think we've got it down like as small as you can possibly get it without just doing inline assembly to about 165 Kay cath gas for for any number of channels which is pretty good and then the challenge path if something goes wrong and someone challenges you want chain you can respond and get your money out with 200k gas which is reasonable at this point I think for something of this nature so that's something we've done and we're also documenting everything so you can see that we have a website it's not actually live unlike a public URL yet but this stuff's all open-source on our repo if you want to dig into it and just run it yourself but we're gonna put this up later a full protocol description of exactly which messages gets passed between each person the exact rules the motivation behind all of it and this is also something that we're trying to get out by the end of this year in such a way that I could share this with all of you and it would make perfect sense how it all works so a lot of documentation and we think we talked about in the panel yesterday the importance of documentation so hopefully this becomes useful to anyone interested client and hub so one thing that we're doing is I mentioned earlier that we have an implementation that's version 1 that's what connects is running we're now it's creating a version 2 which we hope will be like the go-to implementation for anyone here that wants to use it for first aid channels and there's a couple properties that we're aiming for so one is we do store all of your states right now but it's kind of like a bit janky it's stuck in local storage we don't have like exact guarantees that you don't like accidentally lose some of that so we're trying to make it be the case that we can guarantee you're never going to lose any state we're gonna automatically detect and respond to challenges that might occur between you and a hub you and any other kind of party in any part of the protocol and we want to make this like you mentioned the go-to pression quality software for hubs if you want to run a hub or for a client such that any wallet can implement this and that's like what we're doing now and then finally in the browser and wallet UX we're also doing a bunch of research into what exactly should a browser show for channels so there's a bunch of open questions here one is like you know how do you interact with us a channel like like I showed one example in that gift earlier one is like you know how do you actually get get consent from a user because if you have more than one channel like it's you don't want to have a pop-up every single time how do you trust the actual application that you're running it could be the case that the application code is in which case you just basically trusting some solidity code that will just lose your money so how much trust does it use need to have in the actual app to what extent is the wallet going to add to protect you and what policies which I'll show a picture of in a second should the wall actually be able to enforce so one example of this is we have like this idea right now a budget per tab in the browser working with meta masks on this right now and we also have a demo that we're gonna try and release in the next few months which inc which encodes this general idea which is when you go to a tab the wallet will ask you how much money do you want to allocate to this tab and then what you're doing is essentially saying this tab can open and close an unlimited number of channels for any number of reasons up to this amount and the wallet software obits if we enforce that so here's like one idea of like how we're looking at this from a UX perspective so again I'm going pretty quickly through a lot of different topics but the point here is to show that this is a big area with a lot of open problems and interesting things to work on so yeah I think that's if you're interested in generally keeping up to date with what we're doing this is our Twitter at state channels there's an enormous number of problems like I've kind of been saying and yeah thanks for listening thank you very much do we have any questions from the audience if you have any questions please feel free to raise your hand any you you mentioned that there's a bunch of applications live on may Annette could you recommend some to sort of play around with it and investigate more applications to play around with I think the the there's a couple things you can do we yeah the the one that you can go to right now on your browser is at TTT magma calm there's a Khattak Tac Toe application it's not following exactly this protocol it's more of an older version but it shows the general workflow of how you deposit money into a contract play tic-tac-toe off chain and then get some money out if you want to use the exact most up-to-date stuff it's less of a fun app but you can use the connects to stuff so you can make payments one thing that they've built using this is actually off off our pseudo offline payments where you can basically give someone you can give someone a claim on some money that either you can you can claw back if they never take it but they can also claw towards them and make it so you can't take it away so it's like an offline payment in a way I'm going gift card that's an application that they have in their in their Die card right now I would say probably yeah the latest stuff you should try the Die card otherwise if it someone on the toy around with it you go to TTT magma calm there's also a rock-paper-scissors one I think RPS magma calm those are the more like for fun like just generally get an idea of it stuff we do have an application with building we haven't really announced it yet but it's yeah as you can mention it briefly we're trying to build an application right now where you can download and upload so basically seed and leech arbitrary torrent our chief files using the web torrent protocol where you have in the browser several concurrent virtual channels so you and some other persons if you're if you're downloading they're connected to like maybe 10 15 people that are uploading and you're paying them per byte and so we actually have an MVP of that thing locally in our repo and we're just trying to like get that thing working such that we can release it later this year hopefully maybe super early next year and the idea is that it'll include that policy UI I showed and hopefully it'll encode all the things I talked about and like a really cool demo that actually like is useful for something because you can then get paid to upload files and you can also pay to get files hopefully faster than using the regular web torrent application wonderful do we have any more questions from the audience yeah so the fun like example is TTT mag mo ma GMO comm and then the the production software is uh I guess connect dot network I think the website is actually die-die card I oh I maybe someone can correct me I don't know the exact website for the dai card but dai space card if you google that I'm sure you'll find it ok well take one more questions ok so anything else you want to add yeah I guess like yeah the jet the most important thing is like if you're interested in this stuff there's a research forum you can go to you can ask questions the repo github comps are state channels has not perfect documentation but it's at least tractable you can go in you can add an issue you can check out the code it's we're progressively moving forward with a big team on this stuff and so if you want to contribute or just ask a question we're all available and yeah the goal is just to make this stuff work and make it coherent and tractable for everybody in one package versus in many disparate several separate packages great well thank you very much for your sharing thank you [Applause]