Making Sense of Layer 2 by Josh Stark (Devcon4)

[Music] okay hello everybody thank you to Def Con for having me thank you to Prague for hosting Devcon the Commons off to a great start and I can't wait to finish my talk so I can watch all the other ones so this talk is about layer two we're gonna give you a clear conceptual description so first of all Who am I my name is Josh I'm a co-founder kinda called elf or you can follow me on Twitter if you would like to and at l4 we're building a project called counterfactual in collaboration with many others and counterfactual is a framework to make it easy for people to use state channels in their applications if you want to find out more there's lots people wearing these t-shirts around come chat with us so the goal of this talk is to leave you with a clear conceptual understanding of what layer two means if you are not a developer this should be a kind of a good way to understand the intuitions behind these techniques and why we need them if you are a developer this will hopefully give you a kind of better set of context a higher level view of how these different technologies relate to each other and why they're important so we're you know about four things first briefly what are the kind of fundamental limits of public blockchains that require scaling solutions secondly what is layer two and what are layer to scaling solutions and then we're going to talk about two examples state channels and Plasma so first fundamental limits blocks means like aetherium are expensive and they're slow they're expensive because we're doing things on them requires fees and they're slow because you have to send something to the blockchain wait you know in 15 seconds for a confirmation and then do something else anyone that's ever you know kind of dealt with this or or try to interact with the blockchain when there's something going on like a crypto kitty spawning incident or a poorly constructed ICO is very aware of this just give you a sense of scale of Hagah how aetherium today compares to other things we might compare it to it's not great right 20 transactions per second maybe a little more maybe a little less depending compared to pay power visa is very minimal and if we look to non-financial applications the numbers get even more frustrating so today a theorem is obviously not where it needs to be to kind of satisfy the ambitions of all the people in this room so why is that this purple rectangle is the etherium blockchain for the purpose of the next 27 minutes it is slow it is slow and that's sad why is that well a light slightly more accurate geometrical representation would be that theorem is actually made up of many individual nodes so it actually looks more like this each of these nodes is separately processing all of the things that happen on ethereal so if you Berthe crypto kitty or you send a transaction or an e or C 20 contract updates it balances all of that is being separately and individually processed by each node and that is kind of the fundamental bottleneck of block chains that aetherium can only do as much work as we are willing to require from this one node and all the others now there is like a and this is an important feature of aetherium it's not something we just kind of do away with nodes don't have to trust other nodes they they figure out what happened for themselves without having to refer back to some sort of master node so there is a naive solution to this problem which is that well let's just require individual nodes to do a lot more work so let's say now you have to process two times as many transactions and so the whole system will be able to do more and now our blockchain can do more stuff now that sounds great but it comes at a cost and the cost is that now nodes are more expensive to run and so there will be fewer of them because we've raised the price to do that and now instead of this blockchain we have something that looks a little more like this there are fewer nodes it is less decentralized and it's less secure those of you kind of with more context might remember that you know the Bitcoin block size debate was essentially about this parameter should we raise the amount of work that nodes have to do or should we keep it where it is and it's also notably kind of the technique or the approach used by many of these so-called aetherium killers where they are claiming massive scalability benefits and the way they're doing that is something like this where there are many fewer nodes but they're far more powerful and can process a lot more stuff but the in the etherium kettle community we want to do better than that we don't just want to slide down the scale away from the centralization to performance because that's how it seems we can get performance we want to break that trade off we want to find clever ways to get around it so that we can have the benefits of scalability while still preserving the reason we have block chains like aetherium in the first place so there are two real solutions to this problem being pursued one of them the insight is like well what if we just didn't have every node process every transaction well what if there's a way to not do that what if we split all the nodes in the network into two categories nodes a no a nodes and B nodes and we had them separately processed transactions but still resolved as some common state on some schedule if we can do that then we've effectively doubled the transaction capacity because now the limiting factor is what two nodes can do now this is like the the most basic possible description of the insight behind sharding shrouding awfully much more complex than that but that's the kind of the core idea and charting is a core part of what we are apparently now back to calling serenity but I didn't get the memo in time for these slides so what we're calling each 2.0 you can hear a lot more about that obviously the talent just talked about on the bench and there's a bunch of talks all week where you can learn more about sharding and related systems I think they're probably more than just these two they're on the schedule that would touch on in some way but I encourage you to check them out but that's not what this talk is about so there's a second kind of approach to solving this fundamental problem so instead of changing layer one with sharding what if we found ways to use it radically more efficiently so we could have the same number of transactions actually happening on layer one but do way more useful stuff with those transactions so layer one gives us this kind of hard kernel of certainty we know code it will execute as written instead of using it just for everything like raw on natural layer one we can use it as like a foundation for other technology built on top of it and if we're clever about the way we do that these on top technologies layer 2 can have very nearly the same security as layer 1 so again back to our purple rectangle instead of changing something about it we're just going to change the way we use it we're going to use it as a foundation as this base layer for other stuff that we do that remains anchored to layer 1 and retains as much as possible of the security properties of layer 1 and those are layer 2 technologies and that's what this talk is about ok so layer 2 now this isn't a kind of precise tactical definition but it's kind of the three like main things that like layer two technologies share together that I hope will give you a really kind of clear understanding of what we're trying to do so the first thing here is that with layer 2 we're building applications where most of the work is done off change so instead of asking aetherium to you know do some calculation run the logic of some smart contract we're doing that on a on a different computer somewhere else and what that is we'll talk about it a bit later secondly we're still using layer 1 but only to kind of create what I'm calling anchors the kind of tie this off chain environment to layer 1 security and thirdly we are preserving the same risk model as layer 1 or as close as possible to it to kind of maximize the security that we have and what's really amazing is all this is again happening without changing layer 1 and this has some kind of cool implications you know in order to get access to these scaling technologies we don't have to go through a hard fork and do all that we can just write software that runs on the theorem these anchors and then also write client software that interacts with it and get these things today and it also means that different applications with different threat models and different needs can use a different layer to scaling solutions to find something appropriate for them instead of again changing layer 1 and forcing everyone to make the same compromises so it's also really important to understand what layer 2 is not because often kind of misconceptions here that I want to like try and clarify as best I can so layer two is not just any technique that moves operations to an off chain environment in order to obtain performance enhancements and kind of to make this point clearly I'm going to do a little live demo on stage here and I may require the assistance of volunteer Mitch kosowski who is backstage somewhere and I'm going to come out again right now I hope Mitch does another volunteer may be sitting up for oh there he is okay so here's what we're gonna do thank you a big hand for Mitch who's doing this okay so hypothetically let's say that I have locked up some eath on the etherium main chain into an account and I've written the private key for that account on the inside of this fancy little elf or sticker and let's also cuz caveat out that Mitch and I did this together we both trust that this is the only copy of that private key and I haven't cheated in some way then we're gonna move this asset to a high availability carbon-based often execution environment namely this stage and us and all of you and then we're gonna pass it back and forth really really quickly does anybody have each stats open on their laptop right now by any chance no okay well then what it's going to pretend that we're doing this in real time with a block okay so here we go off gain scaling okay and then there's another block so we did I think nine transactions in that time each of them had you know instant finality I had possession of this which is much faster than we could have done if we had been waiting for blocks I would have had to send a transaction wait for it to confirm Mitch would see that send something back to me and so forth and so forth so here we go off chain scaling Thank You Mitch very much for your help Oh Mitch keep this so why is that not layer two I mean aside from it is being kind of dumb well let's kind of compare this to maybe a more like relevant example right so let's look at kind of naive side chains what I'm calling them so for a long time we've you know known that we can lock up an asset on main chain and we can move it to another execution environment like a side chain which is just another block chain with a different set of consensus rules and we can do stuff there with it much faster because we have kind of like a cheaper execution environment one that is simpler that's made a different set of compromises and this can like have many different scales ranging from a kind of proof of stake side chain or something else it's up to that exact side chain and then once you're done we move it back to a theory main chain and you're good to go so why aren't either of these things kind of properly layer to the way I use the term well remember our definition right we want to kind of take advantage of off chain environments we want to use layer 1 to build anchors that tie that environment to main chain and we want to preserve the same risk model as layer 1 or at least as close as possible to it well neither of these kind of do the second or third thing as I describe them right they're just doing the off chain thing with the paper example like Mitch and I kinda have to trust like this whole environment we have to trust that someone is going to run up on stage and take that paper from us because then it's gone we have to trust that we're going to be able to get with the paper to a computer to actually kind of claim our eath and all the other assumptions you make about this security environment with a side chain you have to kind of trust however that side chain is set up and it might be very secure of what you need for it but it may also not the point is that it's an adjacent environment it's not they're not things built on top of layer 1 they're things built to the side of it that you can then return to and that's a really important difference because it's a difference in kind of what your risk model is and yeah so layer two are you know often technologies where a user does not have to trust a separate environment and I should also be clear that this is not a criticism of sidechains or the teams that are using them or working with them there are really important kind of technique right now because plasma which is kind of a layer to affine sidechain we'll talk about later isn't ready for deployment yet and also that many of the company is working on side chains are also working on plasma the point is just that these are technically different things and you should understand that distinction so just one last thing before we jump into kind of state channels in plasma what do we mean by anchors on layer 1 that words been doing kind of a lot of work in what we spoke about so far and I'm about to give you kind of - like precise technical examples of what that means but I want you understand the intuition behind it first they're not anchors in the sense that there's just some sort of like informational relationship between layer 1 and layer 2 but there's like an economic or an incentive relationship between these things and I want to kind of give you like a conceptual intuition about how these things work and how they can't work so conceptually this is kind of like how we use quartz and just bear with me here you know people use legal systems often but they rarely interact with a court probably most of the people in this room have at some point in their life signed an employment agreement or written drafted up an NDA and had someone else sign it or any other number of no contractual agreements but probably very few of you have actually had to go talk to a court to get that contract enforced right court is expensive and slow but it is reliable and authoritative depending on where you live and the fact that a person could go to court to enforce a contract is usually enough for that contract just a piece of paper to actually affect people and like you know provide enough trust for commerce to work so this should sound kind of familiar right it's a little bit like the intuition we use with layer 2 where apps can use aetherium but they don't have to interact with it all that much layer 1 is expensive and slow but it is reliable and authoritative and the fact that you could go to layer one using this anchor at any time is enough to kind of let layer two systems be extremely secure and extremely trustworthy and I should also say because we just heard from italic earlier about what you know Saran II will look like and how main channel be much faster even in the world where you know we have sharding we have serenity we're still going to want layer 2 solutions because they're always an improvement on whatever layer one can do and instant free transactions is always better than paying a fee no matter how small so keep in mind also that this is just an analogy I'm not making a strong claim about legal systems and block chains that they were somehow identical the point is just that future pay off some penalties shaped behavior if theorem is an excellent tool kit for creating mechanisms payoffs and penalties and that other systems have existed in the past that do this in a similar way and we can kind of learn from them at least on an intuition or conceptual basis all right so now we're gonna jump away from kind of the abstract general to talking about two specific layer two solutions and give you an idea of how they work so we're gonna start with state channels state channels are the kind of foundational layer to technique and the way it works like this is that we have Alice and Bob and Alice and Bob wanted to make payments to each other now if they do it on main chain kind of the naive way then the way this works is Alice sends a transaction to the etherion blockchain and then she pay some fees and then they wait and they wait and they wait and they wait in the wait and then 15 seconds later Bob gets a confirmation and they can move on and do something else there we go now has these this sucks right I mean anyone that's ever worked on a wallet or talking to real users the idea of having to wait 15 seconds before any kind of state change whether that's a payment or something else is horrible we need to do better so let's do this now through a state channel or a payment channel in this specific example so this contract the state channel multi-sig is on the blockchain it's just an account and it has Alice and Bob's money inside of it so Alice and Bob are both deposited some amount of eath into it beforehand now instead of sending a transaction to the blockchain what Alice and Bob do is they exchange messages over any communication protocol and each message is a transaction and I don't mean a transaction as in like one that is confirmed by the blockchain I just mean like the literal data structure of a valid transaction a script that could at any moment be sent to the blockchain and it will be accepted it's valid and so forth Alice and Bob both keep all the copies of the transactions that they've received and sent and they're always signing both of them so keep in mind these three things right so each transaction is signed by both parties they're all valid at any point you could go to the blockchain and say hey this is a real transaction and everybody's keeping copies of all the transactions that they have received and signed and sent and so forth so then Alice says okay this has been great let's close the channel I'm done transacting with you and they both you know kind of report to the state channel multi-sig what the latest status with the latest transaction that they both agreed to is and they both say its transaction number four and then the state channel multisig knows to pay out the appropriate amounts of eve based on what that last transaction shows their balances to be great now this is the optimistic case we're kind of everything goes well but you might just be asking well what if one of them relies what if what if Bob doesn't tell the truth about what the most recent state is well let's go back to the step where Alice wants to close the channel and this time Bob lies Bob says that transaction number three is the most recent one what happens well our state channel multi-sig and well first there's a bit of you know choice words then our state channel multi-sig has some rules built into it and one of those rules is that the more recent update is the true one and that if a party submits old state we punish them in some way so it can tell that there's a newer transaction between their two are submitted and it knows that the newer one is the real one and the way that works is just that each transaction has a nonce and it updates each time as a new thing and because both parties have signed it they've already agreed to that being the most recent state so what is using state channels get us well Alice and Bob were able to pay each other four times but it could have been ten thousand times instantly and for free at least in terms of blockchain cost all those things were were messages sent over the Internet back and forth and as soon as either Alice or Bob had that action in hand that both parties have signed they can then at any point close at the channel and withdraw the worst case for both parties is that you have to submit an on chain transaction to resolve a dispute and so the worst case is well you're just back to using layer 1 and you also get some privacy benefits one of the really cool things about state channels that the only on chain thing that someone can see is just a generic multi-sig they can't tell that it's a state channel and they certainly can't tell what's going on inside of it because that state is just like kept between the parties and so an important kind of like Calif occation here is i've given you an example of a payment channel because the simplest one to explain for this talk but the same kind of technique can be used for kind of any kind of state right a payment channel is just one application inside the larger box of state channels people are using them today for kind of games gambling etc that can be used for any kind of complex thing complex financial contracts derivatives etc there are lots of teams finding other ways to use this and I should also say that of course this is kind of a general description there are many other things that could go wrong in a state channel and there are other ways responding to those problems I don't have time getting them now but I hope you'll watch other talks this week about say channels to learn more so let's kind of return our definition quickly and just see how this applies so for the first kind of criteria yes because you know transactions are being exchanged just an off chain messages nothing is really happening on chain except for what happens to our state channel multi-sig and then the only on chain piece is that multi-sig which is used to kind of instantiate channels to withdraw to disputes to handle the like the on chain bits and then lastly we have kind of the same risk models layer one as long as users are following the protocol and as long as layer one is available meaning they can get a transaction to layer one then we're not introducing additional risks you can always kind of submit your transactions to main chain because they are valid and ready you just have to go for the process and follow the protocol so a few kind of it's like little advanced topics very briefly related to state channels so one kind of really cool innovation that we've been working on law l4r what are called generalized state channels and the idea here is that while in the example I gave there was kind of one application running in the channel between Alice and Bob which was a payment channel but you can actually have multiple applications in the same payment channel still with only one on chain component so Alice and Bob could have an eighth payment channel chess game a dive payment channel a financial contract of some kind all just with that one state channel multisig this is kind of a big improvement on like the efficiency of how we can use state channels as well as the kind of usability experience because you don't have to open up new ones for every application and you can install these applications in the channel with no on chain fees another side topic meta channels the idea here is that well you can kind of have channels that route through other people so if Allison Ingrid the intermediary have a state channel with between them and if Ingrid and Bob have a state channel between them that as long as Alice Ingrid and Bob sign a certain set of commitments you can have this kind of meta channel between them or Alice and Bob effectively have a state channel between them and Ingrid routes it but doesn't have control over what actually happens third subtopic hubs are kind of an extension of the middle channel idea that if we had a hub kind of in the middle that has state channels open with many different people then as long as you have a relationship open with the hub you kind of can get a meta channel to any person that also has a relationship with that hub all these topics we're gonna hear about more and other talks this week and one really cool thing about all this is that most of what I'm just talking about is being implemented today this is no longer just theory this is real stuff running on main at running on test nets very close to deployment and I hope that you will take the time to watch some talks this week we have a huge number of talks about state channels and none of them overlap so if you want to spend Devcon just learning about state channels which i really encourage you to do you can kind of get up-to-date with everything and none of these conflict so please check these out obviously it's all new schedule as well but please attend these talks they're gonna be great all right next thing plasma so the first thing to know and all the plasma features are always telling us this plasma is not a single project there's not just one thing that is plasma plasma is a framework for building scalable applications on aetherium it is kind of a family of techniques that all have a kind of similar route but like are being done in different ways so the basic intuition behind plasma is that side tunes are really cool but they require these kind of additional trust assumptions and you have to trust the consensus of whatever the sidechain is using so what if we had a sidechain that was layer two if I'd one where users always had a guarantee that if something goes wrong they can withdraw back to main chain and something going wrong means something like all the validators on the sidechain suddenly turn malicious and try and steal your money with plasma the ideas you should be able to withdraw even if that happens so I'm gonna kind of go over like just to the basic components of plasma there are different implementations like I said that are quite different and so it doesn't make sense to try and cover them all I hope it does give you this like a bit of insight about what's going on here generally so first just kind of like what is the basic setup we have what's called the plasma route which again is a smart contract on aetherium and then we have our plasma chain which is a kind of like very similar to a sidechain in other respects it is a kind of a separate environment and the validators the sidechain or the plasma chain can communicate with the plasma route and then we have our users Alice and Bob and we have all these applications that run on the plasma chain because the plasma chain is making kind of a different set of choices about how the consensus works it can be much much faster and how it reaches consensus which means things are quicker and news are paying much lower fees you could have games on plasma chains you could have exchanges on plasma chains you could have lots of other stuff so first kind of basic thing about plasma our state commitments and the basic idea here is that we need a way for the kind of plasma route to know what's happening on the plasma chain so there's kind of a regular schedule through which the plasma chain reports what its state was at a certain block and then the plasma route keeps a concise record of that and then we do this over over and over again as things progress this is important because when we get to exits we're gonna need that information so the basic idea and a lot of the heavy lifting with plasma is how do we make sure that people can actually exit - main chain if something goes wrong in all circumstances the basic idea is that Alice would say okay I'm done interacting with whatever I was doing on the plasma chain I want to move my assets back to me you know and so Alice has been kind of keeping track and keeping copies of the like blocks and information that's happening on plasma chain and so she has a proof that she owned some asset in a certain block the plasma route checks this against their own concise record and then waits to see if someone challenges Alice right because maybe Alice is doing what Bob did in the previous example in trying to withdraw old state there's an appropriate waiting period and then if nothing happens great Alice can withdraw her funds plasma in the simplest possible way so remember our definition again we're trying to build apps where most of the work is done off chain and here that's happening on the plasma chain instead of main chain we're only using layer 1 to build these anchors that tie off chain 2 layer 1 and here the on chain root contract ensures that users can always withdraw if something goes wrong and thirdly we're trying preserve the same risk model and again as long as you just follow the protocol and as long as layer 1 is available we're not introducing additional risks you can always withdraw to main chain and again I should say that this is obviously a very general description and there are many caveats to basically everything that I've said because this stuff is complicated and the implement details are complex so if you want to learn more I encourage you to go watch some other talks now they're kind of like three primary there there are more than this there's seemingly a new one every week but there's kind of three primary like versions of plasma that are being worked on right now there's one called Plaza MVP which only handles payments so no smart contracts on plasma transfer here and it uses a UT EXO model similar to Bitcoin and the idea is like to get something pretty simple that can be implemented rather easily there's plasma cash where the assets on the plasma chain are actually unique non fungible tokens so you would just get kind of like a crypto Kitty equivalent an NF T that says I own ten Eve on this path of chain and then you would trade those it's a lot easier for users or use applications to track their balances but it does introduce the problem of how do we actually split an NFTE worth ten into five and five there's not curly an easy way to do that and then there's plasma debit where things get really weird and here like plasma cash the assets are NF TS but assets are also payment channels that exchange between users and in between users and one - validator this is very complicated and there's a lot of active work being done on kind of like refining these different designs trying out new ones figuring out kind of like we're in the full spectrum of plasma there's something that makes sense for different applications there are four talks at least about plasma at Def Con this year again none of these overlap and none of them overlap with the state channel stuff either so if you just want to spend a week learning layer two I encourage you to do that and I encourage you to check these out all of these talks are on Friday so let's wrap it up with just kind of what is the big picture here what I want you to take away from this is that if theorems programmable blockchain is not just useful for running gaps it also gives us this incredible performance toolkit the fact that we can create any sort of mechanism you want on aetherium because the theorem is programmable we can write software that enforces economic payoffs and penalties and we've learned now that these mechanisms can let applications retain the security and authoritative nough subdomain chain while still achieving the benefits of off chain execution that's amazing and it's also only the start state channels and Plasma are probably best understood as different points on a spectrum of using this general technique of using crypto economics to ground off chain processes in the security of layer 1 and all the time work time developing new ways to do this all the time people are looking at state channels and looking at plasma and finding refinements the design finding points between them finding points where they can work together so I think there's a lot more in this new design space and I think the future is very bright for later - thank you for coming to this talk I hope it was useful and enjoy the rest of DEFCON you