 Okay, hello everybody. Thank you to DevCon for having me. Thank you to Prague for hosting DevCon. The conference is 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 2. We're going to kind of give you a clear conceptual description. So first of all, who am I? My name is Josh. I'm a co-founder. We're going to call it L4. 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 of 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 2 means. If you are not a developer, this should be 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 going to talk about four things. First, briefly, what are the kind of fundamental limits of public blockchains that require scaling solutions? Secondly, what is Layer 2 and what are Layer 2 scaling solutions? And then we're going to talk about two examples, state channels and plasma. So first, fundamental limits. Blockchains like Ethereum are expensive and they're slow. They're expensive because doing things on them requires fees and they're slow because you have to send something to the blockchain, wait 15 seconds for a confirmation, and then do something else. Anyone that's ever dealt with this or tried to interact with the blockchain when there's something going on, like a cryptocity spawning incident or a poorly constructed ICO is very aware of this. Just to give you a sense of scale of how Ethereum 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 PayPal or Visa is very minimal. And if we look to non-financial applications, the numbers get even more frustrating. So today Ethereum 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 Ethereum blockchain for the purpose of the next 27 minutes. It is slow. It is slow. And that's sad. Why is that? Well, a slightly more accurate geometrical representation would be that Ethereum 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 Ethereum. So if you birth a cryptocity or you send a transaction or an ERC-20 contract updates its balances, all of that is being separately and individually processed by each node. And that is kind of the fundamental bottleneck of blockchains. That Ethereum 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 Ethereum. It's not something we just kind of do away with. Nodes don't have to trust other nodes. 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 many 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 remember that 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 Ethereum 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 in the Ethereum technical community we want to do better than that. We don't just want to slide down the scale away from decentralization 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 blockchains like Ethereum 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? What if there's a way to not do that? What if we split all of the nodes in the network into two categories A nodes and B nodes and we had them separately process transactions but still resolve 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 most basic possible description of the insight behind sharding. Sharding is much more complex than that but that's the core idea. Sharding 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 ETH 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 there are probably more than just these two that are on the schedule that would touch on in some way and encourage you to check them out. But that's not what this talk was about. So there's a second kind of approach to solving this fundamental problem. So instead of changing Layer 1 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 1 but do way more useful stuff with those transactions. So Layer 1 gives us this kind of hard kernel of Serenity. No code on it will execute as written. Instead of using it just for everything like raw on the actual Layer 1 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. Okay, so Layer 2. Now this isn't a kind of precise technical definition but it's kind of the three like main things that like Layer 2 technologies share together that I hope will give you a 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-chain. So instead of asking Ethereum to do some calculation run the logic of some smart contract we're doing that 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 that 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. 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 Ethereum, these anchors can 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 different Layer 2 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 kind of understand what Layer 2 is not. Because often kind of misconceptions here that I want to try and clarify as best I can. Layer 2 is not just any technique that moves operations to an off-chain environment in order to obtain performance enhancements. And to make this point clearly I'm going to do a little live demo on stage here. And I'm going to 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 maybe sitting up for it? Oh, there he is. Okay. Here's what we're going to do. Thank you, big hand for Mitch who's doing this. Okay, so hypothetically, let's say that I have locked up some ETH on the Ethereum main chain into an account and I've written the private key for that account on the inside of this fancy little L4 sticker. And that's also because 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. We're going to pass it back and forth really, really quickly. Does anybody have ETH stats open on their laptop right now by any chance? No. Okay, well then we're just going to pretend that we're doing this in real time with a block. Okay, so here we go. Off-chain 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 just being kind of dumb. Well, let's kind of compare this to maybe an 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 blockchain with a different set of consensus rules. And we can do stuff there with it much faster because we have kind of like a chief execution environment, one that is simpler, that's made a different set of compromises. And this can like have many different scales ranging from kind of proof of stake side-chain or something else. It's up to that exact side-chain. And then once we're done, we move it back to a theory of main chain and you're good to go. So why aren't either of these things kind of properly layer two 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 one to build anchors that tie that environment to main chain. And we want to preserve the same risk model as layer one or at least as close as possible to it. So neither of these kind of do the second or third thing as I've described them, right? They're just doing the off-chain thing. With the paper example, like Mitch and I kind of 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 ETH and all the other assumptions you make about this security environment. So layer two is set up. And it might be very secure of what you need for it, but it might also not. The point is that it's an adjacent environment. They're not things built on top of layer one. 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 off-chain 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 side chains or the teams that are using them or working with them. They're a really important kind of technique right now because plasma, which is kind of a layer two-ified side chain we'll talk about later, isn't ready for deployment yet. And also that many of the companies 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 one? That word's been doing kind of a lot of work in what we've spoken about so far. And I'm about to give you kind of two like precise technical examples of what that means, but I want you to 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 one and layer two, 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 courts and just bear with me here. 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 drafted up an NDA and had someone else sign it or any other number of contractual agreements. But probably very few of you have actually had to go talk to a court to get that contract enforced. 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 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 two, where apps can use Ethereum, but they don't have to interact with it all that much. Layer one 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 Vitalik earlier about what Serenity will look like and how main chain will be much faster. Even in a world where we have sharding, we have Serenity, we're still going to want layer two solutions because they're always an improvement on whatever layer one can do. And instant free transactions is always better than anything, 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 blockchains that they are somehow identical. The point is just that future payoffs and penalties shape behavior. Ethereum is an excellent toolkit for creating mechanisms for 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. So, now we're going to jump away from kind of the abstract general to talking about two specific layer two solutions and giving an idea of how they work. So, we're going to start with state channels. State channels are the kind of foundational layer two 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 Ethereum blockchain, and then she pays some fees, and then they wait, and they wait, and they wait, and they wait, and they wait, and then 15 seconds later Bob gets a confirmation, and they can move on and do something else. There we go. Now, here's the Eve. 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 have both deposited some amount of ETH 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 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 as 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 say, hey, this is a real transaction, and everybody's keeping copies of all the transactions that they've 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 Multisig what the latest state is, what the latest transaction that they both agreed to is. And they both say it's transaction number four, and then the State Channel Multisig knows the amount of ETH based on what that last transaction shows their balances to be. Great. Now, this is the optimistic case where kind of everything goes well, but you might just be asking, well, what if one of them lies? 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 Multisig, well, first there's a bit of choice words. Then our State Channel Multisig 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 the 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 is a new thing. And because both parties agree 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 10,000 times instantly and for free, at least in terms of blockchain cost. All those things were messages sent over the internet back and forth. And as soon as either Alice or Bob had that transaction 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 one. And you also get some privacy benefits. One of the really cool things about State Channels is 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 co-ification here is I've given you an example in 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. They 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 because there are other ways of responding to those problems. I don't have time to get into them now, but I hope you'll watch other talks this week about State Channels to learn more. So let's kind of return to 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 in 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 like the on-chain bits. And then lastly, we have kind of the same risk models layer 1. As long as users are following the protocol and as long as layer 1 is available, meaning they can get a transaction to layer 1, 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 through the process and follow the protocol. So a few kind of like little advanced topics very briefly related to State Channels. So one kind of really cool innovation that we've been working on a lot at L4 are what are called generalized State Channels. And the idea here is that, well, 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 ETH payment channel, a chess game, a die payment channel, a financial contract of some kind, all just with that one State Channel that you can have in the same payment channel. So that's kind of a big improvement on the efficiency of how we can use State Channels as well as the 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 Alice and Ingrid, the intermediary, have a State Channel with between them, and if Ingrid and Bob sign a certain set of commitments, you can have this kind of Meta Channel between them, where Alice and Bob effectively have a State Channel between them, and Ingrid routes it but doesn't have control over what actually happens. Third sub-topic, hubs are kind of an extension of the metal 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 hub with that hub. All these topics, we're going to hear about more in 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 mainnet, 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 time with 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 in your schedule as well. But please attend these talks, they're going to be great. All right, next thing, plasma. So the first thing you 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 available applications on Ethereum. It is kind of a family of techniques that all have a similar route but are being done in different ways. So the basic intuition behind plasma is that sidechains 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 of five, one where users always had a guarantee that if something goes wrong, they can withdraw 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 idea is you should be able to withdraw even if that happens. So I'm going to go over just two of 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. Hopefully this will give you a bit of insight about what's going on here generally. So first just kind of like what is called the plasma root, which again is a smart contract on Ethereum. And then we have our plasma chain which is kind of like very similar to a sidechain in other respects. It is a kind of a separate environment. And the validators for the sidechain or the plasma chain can communicate with the plasma root. 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 and how it reaches consensus, which means things are quicker and users 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 are state commitments. And the basic idea here is that we need a way for the kind of plasma root 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 is, and then the plasma root keeps a concise record of that, and then we do this over and over and over again as things progress. This is important because when we get to exits, we're going to need that information. So the basic idea in a lot of the heavy lifting with plasma is how do we make sure that people can actually exit to 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, I'm going to go back to main chain. And so Alice has been kind of keeping track and keeping copies of the 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 root checks this against their own concise record and then waits to see if someone challenges Alice, because maybe Alice is doing what Bob did in the previous example in trying to withdraw old state. If something 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 one to build these anchors that tie off chain to layer one and here the on chain root contract ensures that users can always withdraw if something goes wrong. And thirdly, we're trying to follow the protocol and as long as layer one is available, we're not introducing additional risks. You can always withdraw to main chain. And again, I should say this is obviously a very general description and there are many caveats to basically everything I've said because this stuff is complicated and the implementation details are complex. So if you want to learn more, I encourage you to go watch some of the talks. Now there are kind of like three primary there are more than this, there's one called Plasma MVP which only handles payments so no smart contracts on plasma chains for here. And it uses a UTXO model similar to Bitcoin. And the idea is to get something pretty simple that can be implemented rather easily. There's Plasma Cache 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 NFT that says I own 10 ETH on this plasma chain. And then you would trade those. It's a lot easier for users to use applications to track their balances, but it does introduce the problem of how do we actually split an NFT worth 10 into 5 and 5. There's not an easy way to do that. And then there's Plasma Debit where things get really weird. And here, like Plasma Cache, the assets are NFTs, but assets are also payment channels that exchange between users and between users and one master validator. This is very complicated. And there's a lot of active work on kind of like refining these different designs, trying out new ones, figuring out kind of where in the full spectrum of Plasma there's something that makes sense for different applications. There are four talks, at least, about Plasma at DevCon 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 too, 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 Ethereum's programmable blockchain is not just useful for running DApps. It also gives us this incredible performance toolkit, the fact that we can create any sort of mechanism we want on Ethereum. Because Ethereum 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 fortativeness of the main 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 the spectrum of using this general technique of using crypto economics to ground off-chain processes in the security of layer one. And all the time we're developing new ways to do this. All the time people are looking at state channels and looking at Plasma and finding refinements to the design, 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 layer two. Thank you for coming to this talk. I hope it was useful and enjoy the rest of DevCon.