State Channels by Liam Horne & Tom Close (Devcon5)
Devcon·Fri, Oct 9, 2020, 12:00 AM
Speaker
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/5/state-channels Over the past several months, Ethereum's leading state channels researchers and engineers have worked to unify their protocols and implementations. The result is a single state channels network, compatible with all major state channel implementations. Liam Horne and Tom Close will introduce the audience to their work, the State Channels Improvement Proposals (SCIP) process, explain how developers can get started building on it, and provide a live demo of the network in action. Speaker(s): Liam Horne, Tom Close Skill level: Intermediate Track: Execution layer Keywords: state channels, technical Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
Transcript
I'm coming up first tom was gonna comp it a little bit and we're gonna talk about state channels and give some updates on what state channels that org is and the latest kind of collaborations that we've been doing and then talk about our roadmap kind of going forward so I get as mentioned what's going on the state channels where we going what do you excited about so State Channel org you may have seen this website at some point it was on Twitter some talk about it what we're mostly doing here is we're trying to standardize the way the state channels work in this industry myself and Tom and a bunch of others will show in a second have all been working on this first like a couple years now and there's been a lot of progress across the tech stack and it's come to be the point where we can begin standardizing a lot of the lower level primitives and working our way up towards something that got a mass adoption by taps trying to get benefit from this technology in the in the coming year so about I don't know if four or five months ago we all went to New York together for an event called East New York and doing New York blockchain week and you can see here we have people from the etherium foundation from prune from cellar from Maggie mocha next a bunch of companies all together we had a bit of like a state channel summit we got literally gotten through a room and we said okay look what are we doing why aren't we collaborate anymore why are we kind of all rehashing the same work together and we had a lot of like really great results one thing that is important to note is that standardization sometimes can be kind of critiqued whether you're looking at it from a VC perspective where you might want to see what you know one killer app dominate the industry first until you see some standards a dot I get adopted or get proposed but one thing that we've noticed that's been critical to aetherium success is defining standards and defining interfaces early on has led to some of the biggest actual booms in the entire industry you know most notably ERC 20 right after that was you know begun to get standardized is when we saw this ridiculous boom you know which for the most parts finance took a lot of our actual operations here in the industry we've seen here see 27 21 lead to like standard marketplaces for collectibles we've seen 7 12 lead the standard wallet signing interfaces and there's many many more examples of once we get together figure out how to do this thing right the rest of the community which is largely builders actually begin building on top so this is extremely critical so these are some of the companies that are involved we all have a really cool history if I had more time I'd tell you the whole story of how we've all been working together over the last little while but we have l4 karoon prototype ol connects cellar magma funfair pisa all these companies and and there's some even on other blocks teens have been collaborating another time it's been working on this problem together for the past couple of years and it's only been recently that we've been able to all kind of come together and standardize at the lower levels so so that's quite that's quite good and I want to just show the case for Standardization what most people don't realize about state channels is that it's not just you know you write this thing once and all of a sudden you know magically all applications go wicked fast it's actually quite a put a huge tech stack that is under the hood of the word state channels and I'll kind of show some of them you know one is the most obvious one is how do you actually progress state between two parties precisely what are those objects precisely what are you signing the other one is like how do you fund these channels how they how do they actually get funded in such a way that anything you do is meaningful on the chain that itself has yielded many papers of different protocols the many many open standards difference across chains networks themselves they're built on top of this the actual implementation of those engines which themselves are large software libraries that we've seen again through multiple different companies implementing these things many archive repositories and github trying to get the stuff working the wire protocol itself how do you communicate to other nodes if you're familiar with lightning and inter ledger and stellar and all these other network attempted channel constructions these things are dramatically different across all of them and that's what's led to years and years of lack of interoperability for the most part and anyone here that's worked on things like in our ledger for example know that once you start getting multiple protocols across different chains together it's it's disastrous if because there's no standards integrations at the wallet level is as well like a massive problem once you actually have a good protocol that works when you go to a wallet it can take months and months and up to years to actually get that thing in well into wallets and again we've seen that with lightning where it's been it's been taking quite a long time they had to get even lightning abled wallets and then finally the UI itself when we talk about end users what did what does it mean to have a channel it's at a card is it some other object in your in your channel is it the wallet itself we've had so many discussions about this and the benefits for each of these things should be extremely obvious at each level what for example with the wall at UI level when we have a consistent UI we have one set of UI components that every wall can standardize around and that you just can have a familiar experience with when it comes to integrating itself we can have one API that a wallet just needs to import the API for and have a standard interface to how they open and close channels at the wire protocol level I kind of gave the example communicating nodes between different block chains is incredibly important the implementation of protocol engines we get this thing done right we can reuse the code in multiple different contexts when it comes to funding we can also have reusable collateral pull collateral kind of hubs so that if you ever wanted to you know reuse a hub and lightning at work in the state you know say channels networking aetherium or in any of the existing state channel networks that we have on the theorem you would definitely want to have pooled collateral and then obviously at the lowest possible level if we're gonna have shared contract code if we're gonna do any kind of formal verification if we're gonna do anything at all about assuring this thing actually secure it like we say it is then we need to have at least one standardized protocol so it should be obvious that these are ridiculously good benefits that are worth pursuing so that's roughly the case for state channel that organ the case for standardization what I want introduced now is just some updates on what we've been building in a project called state channels which I'll get into is the collaboration between a couple other products in the space already so one is we've already taken the whole stack that I just described in the single implementation and we've got it on production today so it's been a tremendous amount of effort between our teams connects specifically that have been building on top of it to get a full generalized 8 channels network on production today and this is actually a ridiculously good accomplishment I'm talking most in this talk about standardization but the fact that we've been able to have all the stuff working at the point that now we have an example with which we can begin to standardize is an enormous success so like kudos that connects on getting this working and the great part is we now have a feedback loop with with wallets with infrastructure projects with applications that are actively using this that can give us feedback on what things they would like whenever we're discussing which standards to adopt so that's been a great success a second thing I want to mention is what I kind of said we're taking immediately the step of merging a project called counterfactual which is initially the combination between two other those companies prototypal and l4 and magma and producing a single project which is what I just described state channels and this is a phenomenal example of how once we begin to agree on standards we can dramatically amplify our efforts and you can see this on our github where we have now several people extremely good engineers from multiple different backgrounds multiple different companies collaborating daily on in building this infrastructure which you know obviously is it going to lead to a lot more output a lot quicker and a lot less redundancy which for me and a lot of people in this room that I've been working on state channels or other larger constructions the ability to say that we're all working together directly is an incredible success so that's one good result from the state channel tool org initiative so I kind of just mentioned a lot of that stuff in practice if you want to follow that specific project we're continue to work on it it's called state channels we're gonna have a smooth upgrade path for anyone that's already working on it you can see the code today if you go to add state channels on github you can follow us on Twitter and we're we're actively doing updates on that there yeah like you mentioned this is how you can keep in touch with that project so yeah that's mostly the case one to make we've taken strides through all the recent efforts this year of standardization immediately gotten something in production that works based on our initial and I've agreed upon standards and we're now merging projects in that set of projects to get a a single implementation that's gonna be production ready for everybody else to take part in over the next little while so yeah that's that state channels and now I'm gonna pass it on to Tom who's going to talk a bit more about it's not just what we're done so far but what we're gonna be doing next yeah thanks Liam so I'm Tom Klaus I am the founder of Mike Mo and Liam mentioned we are one of the projects have come together into the state channels to org project and I just wanted to take this opportunity to thank Lee I mean for his role in that and really like getting the teams to work together and creating this project there's going to drive forward state channels and aetherium and ultimately get state channels into the hands of developers so what I'm going to be talking about here is what we've been working on in the last couple months and what our road map looks like for the months coming up so what are we actually working on in this new state channels to all project so this is the image you've already seen from Liam displaying the different levels of the stack and I'm just going to pick on a few projects that we're working on at the moment and explain which and they're all from different parts of this stack and I'm going to explain what work we're doing and each of those projects the first project is project that we're just calling protocols and contracts and that's to do with the underlying protocols the challenge and response mechanism and the contracts that support that I'm also going to be talking a little bit about our work on the client and the hub so this is the stuff that you need if you're actually gonna run a state channel so this is gonna be running on your browser it's gonna be running on a server somewhere it's gonna be running the wire protocol it's going to be storing your States and all sorts of things like that and then finally I'm gonna talk about a few things from right at the top of the stack and in particular I'm going to focus on some of the ideas we've been discussing around browser and wallet user experience use of state channels introduces all these additional challenges in terms of how you explain what you're doing to a user and how you interact with the user so to start off with I'm gonna I'm going to start talking about these protocols and contracts project so this is where the majority of our work has been so far and so protocols the underlying protocol and the contracts formed the foundation upon which the rest of the stack sits and changes in this layer have to ripple up all the way through the stack so at the beginning this con of this collaboration we've been focused on trying to get consensus at the base layer having a firm foundation that we can then build on top of so we came to this project we had like we each had our slightly different protocols and over the past couple months we've been working to merge them together and work towards a point where we can actually freeze these contracts in this protocol so there have been a couple of different areas that we were working on here the first one that I'm going to talk about is protocol hardening so this goes to I guess the very essence of what you're getting from the state channel and the the guarantee that you want to give people is that a participant in a state channel should be able to progress that channel or terminate it and withdraw their funds within a fixed time regardless of the behavior of other participants so even if you're in a even if you're the only honest participant in a channel you should still have safety you should still be able to withdraw your funds in you if you need to and not have them indefinitely locked in the channel so we've been looking into this when we came into this we were pretty sure that our protocol was already already pretty good and didn't have many holes we've been thinking about it for a long time and then we started using this new tool so we've been using this tool called TL A+ which was a I guess it's a protocol specification language and protocol verifier and checker that was invented by Leslie Lamport so it's for checking the behavior distributed systems and we built a model of our protocol in this specification run it through the checker and it just threw up a ton of problems that we hadn't thought about so this was really interesting and I'm going to point you to some where you can find out more about it the I guess the to give you an idea of the sort of problems that it threw up it was things like if you are able to front run transactions so it's pretty easy to die in a state channel framework so that if I can get a transaction into the chain then I can definitely progress this the State Channel what we started thinking about is what happens if you can get transaction into the chain but if your opponent can get another transaction in before yours what happens then and we found that in certain circumstances your attacker could like lock the channel forever which is pretty bad so this is really interesting I think we're now in a place where we've closed up a lot of those holes if you want to find out more about this you should go to this Research Forum which we've open-sourced today so if you go to research dot state channels to org you can see about a lot of the conversations that are going on some of the things that been thrown at the highlighted by the A+ stuff and other conversations about the protocol level specification and later we also have this basically going to be our place where we discuss all the changes to this protocol right the next thing that we've been working on is gas optimized contracts so you're probably aware the whole point of state channels is to help change scaling and throughput and your ability as a scaling solution is very much limited if it costs a lot to open and close a state channel so for us coming into this project this was a very important thing we want it to be really cheap to open and close a state channel on the happy case and also as cheap as possible to launch a challenge and respond to a challenge if there's bad behavior so we have these two metrics the first one which I've just described is the happy path and that's how much it costs to deposit into the state channel to close the state channel collaboratively and then withdraw your funds and when we started out this was pretty expensive so this was six hundred counts which is I guess like 30 transactions may be a few slightly fewer than that but like that's pretty significant like you need to be doing quite a lot of activity in your state channel to make it work it's this expensive and we've now managed to get that down to sixty-five if you're using eath 185 or ERC twenty so this is these are changes that happen in the last couple months most these changes are due to like basically reducing the amount of stuff you store and chain and we think we can do even better than that though this is before we've started like matching transactions and stuff so we think we can bring this down even further and the second part of that is the challenge part so how much does it cost to launch a challenge if your opponent blocks and then how much they're cost to respond to that challenge and this was originally a whopping 11,000 gasps 1,100 gasps condom breed numbers anymore we've now managed to get that down to 200 K cos so we're beginning to get into the range where these things make sense and it makes sense to use this as a scaling solution finally and the final part of this that we're working on is the protocol and contract documentation so if you want to find out more about these protocols today you have to go and read a couple of different research papers and most those papers are out of date because of these changes that we've made in the last couple months so what we've been trying to produce is an authoritive and always up to date specification at the protocol and contracts so this living documentation there's always guarantees to have the most accurate up-to-date information and we've made some progress on that still working progress we hope to be able to release this in the next couple of months but this will exist in the future and this is an important part of what we're working on in order to help the community like understand and use this framework so our goal here and this is going to be the focus mostly for the next three months so we want by the end of 2019 to be able to freeze and release the v1 protocol and that's going to include a fully robust protocol the optimized and verified smart contracts and full documentation okay so I'm now going to talk a little bit about the client in the hub so this is work that we're doing in parallel but like so this is like teeing it up for the next thing going to work on when we've managed to freeze the protocol so the goal here is to provide a reference client and hub that implement the protocol and this will be something that wallet users can take wallet creators can take and put into their wallets it's going to have libraries that if you want to build everything from scratch you can and it's basically gonna have the design patterns of actually how to interact with this protocol and there are lots of things this needs to do so we're merging these two code bases one Campania factional month of magma and both of these code bases did a subset of these things and we're trying to merge them together to get one that does everything that it needs to and so that includes robustly storing your states these are states like money in a state channel if you lose them you lose lose money validate transitions detect and respond on chain challenges launch your own challenges if you need to and support virtual channels through the hub so this is another another part of the work that we're working on and we'll also be working pretty hard to try and merge those two code bases together over the next three months and finally I want to talk very briefly about some browser wallet UX design things we're thinking about and these are things that I think the whole community will have to get involved in but we've spent we're trying to build a example application and thinking I've been thinking a lot about what the actual user and experience with the state channel could look like so questions if we think about here is how should a user interact with a state channel how do you explain to user that they're locking some funds and they're going to be able to doing things but their fronts are kind of locked and they have to do something to get out another question is can we avoid approving every single signature so anyone who's used the DAP today will be used to getting a meta mascot now the whole point of state channels is to allow multiple transactions a second and you don't want to be doing multiple meta mass pop-ups a second so can we avoid that coming in our wallet can we allow our client to sign some things for you and in that case how much these years I have to trust the app you know if the Klein is just gonna sign things the out sentence to it how can we keep the client their user safe which is this next question to what extent can your channel wallet protect you and then finally what policies should a channel wallet be able to enforce and very quickly we're thinking we're beginning to think that the state channels the thing that makes sense is to have a policy based permission system so you like approve a budget for an app rather than you're approving each channel or each each interaction so you could imagine maybe something look like this in the future your tunnel wallet pops up they ask you to approve the budget it will ask you to prove a spend budget of 2 e for a given site you proved that and then your tunnel wallet helps it takes care everything else it opens it closes virtual channels it opens channels when it needs to it closes them the only constraint is it doesn't go above that to eath limit so yeah if these things are interesting to you or if you've got a use case and I want to have input into how we're thinking about this stuff please come and talk to us or go to the state channels Research Forum these are the sort of conversations we want to have with everybody in the community so yeah that's it from me and from Jim who is no disappeared stay tuned so this is ongoing work and follow state channels on Twitter and thanks for listening [Applause] you
Automatic transcript — names and jargon may be misspelled.