 I am Karl Flirsch, and I am here to talk to you about not just optimistic things, but optimistic roll-up. This is Ethereum Layer 2, the last talk, very inspirational, talking about how we can make Ethereum great and, you know, not suffer from the massive economic divides. And I'm just going to tell you how to make the user experience a little better. But I think it's very important, nonetheless. So of course, PG, that's Plasma Group, shout-out represent. Don't forget about Ethereum Layer 2, it is extremely, extremely powerful. So first I'm going to talk about trees. I recently started growing plants, and by that I mean I recently started killing plants. And it has been a wonderful experience every time I look at my plant, I see mathematical constructions with, you know, the golden ratio and these, you know, fractal branching patterns and just unbelievable, unbelievable complexity, emergent complexity, in fact, you know, that whole emergent thing was definitely not planned and very, very convenient. It's because it's about self-organization, all of these things coming together, all of these different pieces, you know, adding up. And emergent complexity, I had it in my slides, the growth of a plant from the, you know, the soil, the, you place it against the wall, you watch it grow, it's like this incredible thing. And of course, as I'm staring at my plant, I start to see crypto economics. I'm like, wow, it's the same thing. It's like you're planting the soil, you're fertilizing the ground, you're writing your smart contract that says, hey, if you wear a hat, I'll give you a token. And then people start wearing hats as long as you've positioned your plant right and you've, you know, watered it correctly. So it's this emergent phenomenon, both of them. And this entire community is this emergent phenomenon. It's really quite amazing. And so this is my plant is very, this is all what I do to think about how to not think about this very sad dying plant. But nonetheless, nonetheless, we continue on, very sad. So as I was, you know, preparing for this talk, of course, I, you know, stumbled across a Vitalik presentation as I often do. And one thing that he said was JavaScript was the foundation for innovation. He was introducing his new JavaScript framework. And, you know, he was introducing solidity and smart contracts, this Ethereum blockchain. And he said, you know, that is what I hope to bring to the world of cryptocurrency. I want to set the foundation by creating smart contracts, the ability to program smart contracts and use that to grow an ecosystem. And so, you know, Vitalik and many others worked really hard to bring us smart contracts. And it has birthed this incredible community. So many people that I am, you know, everyone in this conference is so great. Anyway, getting choked up about how great people are, but, you know, it inspired me to talk about crypto economics, right? In my DEF CON 3 talk, I was all about crypto economics. I was describing these mechanisms which we can create, hopefully, you know, driving good incentives and avoiding the bad ones and building the, you know, just the right mechanisms and learning how to, you know, design them in such a way that we actually promote good outcomes. And in fact, the kind of subject of my talk was Uniswap, because it felt like a very good, you know, crypto economic mechanism that would drive economic behavior. And, you know, thankfully that seems to have panned out reasonably well. But the dream, right, this dream of crypto economics and building systems with, you know, cryptography and economics and giving us all superpowers that we can all program our smart contracts, that dream became a little bit of a nightmare, right? Because when I actually used our systems, unfortunately, I would be presented with these, like, very, you know, 69-digit, you know, expansions and this, you know, crazy thing where we approve all of the tokens to be transferred on, you know, on our behalf for a random smart contract that we don't really know about, right? Like these crazy user experience problems and pending, you know, we're waiting for our transaction to go through and waiting, waiting. And no matter how much I'm metamask, I press speed up. It never gets faster than 15 or one minute or even 10 minutes sometimes. This is horrible, horrible situation, which I, you know, hope to remedy. Anyway, all of this to buy my crypto kitty and spend 30 cents on gas, right? This is the experience, the plight of the incredible dream that we have. And really, honestly, we have come so far. Like, this is, you know, no shots against it, but a lot of, you know, this is, this is, it's tough love. Anyway, so this caused me to kind of talk about scale and how do we solve some of the big problems that face, you know, the, the Ethereum ecosystem today. And like, how can we build solutions which scale up and resemble, you know, the quote, centralized, the great experience that centralized systems can give you because they don't have to deal with all of this, you know, complexity about, you know, ensuring user safety and all that kind of stuff, you know, that's an afterthought. And so how can we actually build our system so that they resemble those and we can get that massive adoption that we need? And so, of course, you know, myself and a few others, you know, Jing and Ben are in the, in the audience here today for Plasma Group and, you know, tried to solve this, solve this usability problem using Ethereum's layer two, right? And so we could upgrade Ethereum using layer two, using only smart contracts. The actual, like, ability that you have to, you know, impact change with smart contracts is massive. And so just superpowers, right? These smart contracts are incredibly, incredibly liberating. Such power, much wow. And so a couple months later, we, you know, released this test net and we, you know, scaled thousands of transactions per second with Plasma and it was this amazing thing. But then, like an annoying parent, I would hear from people like Hayden and others, but can it run Uniswap? Right, you talked about Uniswap, you love Uniswap, but can it run Uniswap? And the sad truth is no, it couldn't at the time run Uniswap. And so we went back to the drawing board and we thought of generalized Plasma and this time it had predicates and plaps and just, you know, we can actually upgrade the possibility, the functionality of Plasma and, you know, really unlocked a bunch of, you know, technically smart contract programming, you know, features. However, yet again Vitalik was like, but can it run Uniswap? And once again, the sad answer was no, it cannot. We did not have smart contracts. We did not have the unstoppable smart contracts of Ethereum Layer 1 using a developer experience like Solidity that people are familiar with. And so that was a real problem. And to kind of demonstrate this problem, here is a little graph which shows the different ways that we solve the validity and availability problems of Layer 2. I won't get into the details because there's only, there's only some, you know, so much time, but for those in the know, on the right-hand side, you have put all data on chain. That's rollup. On the left-hand side, you have Plasma. And on the top, right, that's how we provide availability. So either we put it all on chain or we use this availability game. And on the top, we have optimistic validity proof. So that is essentially this kind of, you know, the classic Layer 2. It's only, it's correct. We assume it correct if there's a timeout that occurs and, you know, no one has challenged it. And then we can also use fancy math to solve the availability, to solve the validity problem using zero knowledge proofs. And so there's a whole bunch of Layer 2 solutions on this kind of map. And notably, something that is a little strange is there's a little bit, you know, a section that's kind of missing. That was definitely missing from my conception of Layer 2. And, you know, very, potentially very interesting. And so before I go into what that section is, here, generalized, these are the kind of benefits of each system. So generalized computation, when you have one of these validity games enforced with crypto economics, you can do general computation. And on the bottom, you have objective proofs up front. That means that we can prove to the main chain validity immediately because it's succinct enough to be verified. And here on the rollup side, we have no data withholding, which means we don't have to deal with the same problems of a plasma operator going offline or whatever it may be. But here, on the plasma side, we have infinite transactions per second because we don't have that availability bottleneck. But of course, there is this blank open space. So what is that point? Well, we're very clever. And so we came up with the name Optimistic Rollup. And so it turns out that within this trade-off space, you can get general computation. And you can get the no data withholding problem, the kind of unstoppable nature, the liveness properties of Ethereum. And so that gives you what really resembles smart contracts inside of Layer 2. And that is a huge, huge deal from a developer user experience perspective, which is honestly a user experience that is often neglected, especially in Ethereum and other places. Now, notably, this kind of trade-off space had not been explored before. Not not been explored before. In 2014, Vitali came up with Shadow Chains, which is essentially what this is. And a bunch of other people had also come up with this. And so this is a kind of work expanding on Shadow Chains. And so now I'm going to give an Optimistic Rollup overview in two minutes. I was told that my talks, I was giving a slower talk, and they were like, I want a really fast talk, Carl. And so I was like, OK, how fast can I make this fast talk? And it's just way too fast. So you're not going to understand it, but you'll experience it, and you'll love it. You'll love it. So bam, oh yeah, I was going to do that. Bam, that's another one. All right, so we have Ethereum, right? That's pretty straightforward. We have an Ethereum block. We deploy a Optimistic Rollup contract to Ethereum. There's our Optimistic Rollup chain. It's deployed. We have an aggregator. They are bonded. In fact, we can have multiple aggregators. Anyone can submit new blocks, as long as they have a bond. Now, we're going to enter the chain pretty straightforward. We can send a transaction to the main chain and deposit in. Or you can just receive money on the chain itself. Either way works. Now, the next thing is we can send transactions. So remember, that block down there, that is an Optimistic Rollup block. And so we're going to create more of those. So Alice is going to send a transaction to the aggregator. The aggregator is going to create an updated state root. They're going to calculate what the actual state root is. Notably, this is an account model, not a UTXO model, that is kind of more familiar in Plasma, because we can do that with this technology. We're going to commit to these transactions and intermediate state roots so that we can prove invalidity in one step. Then we are going to submit that as a block to Ethereum. Submitting the block to Ethereum, we're going to create a Merkle Tree of that block, which is probably the most confusing part, because we're doing a Merkle Tree, and a Merkle Tree, and a Merkle Tree, and a Merkle Tree. There are four layers of Merkle Trees here. We're going to then add it to a smart contract with a large number of blocks. It is constant size, and so we get to save a lot of gas. We'll talk about the exact transactions per second that we get later. And now, we're going to submit that block. Great, we've done it. And so we can download that block off chain, calculate our off chain state, and we are set and good to go. Now, we're going to interact with the smart contract. Pretty straightforward. Someone deployed a smart contract to Ethereum. The same thing that you do, that there you do an optimistic roll-up. It goes off chain. Now, someone sends a transaction to Uniswap off chain. The Uniswap balances get computed. Any smart contract execution gets computed, and we compute a new state route, and we're good to go. We submit, we commit to that new state route. And now we submit all of that in a roll-up block, and we are set. And we, of course, update our balances once again. Now, we're going to do something bad. The aggregator is going to be evil, evil, malicious. So now, what is going to happen? Well, we're going to create an invalid transaction. We're going to create an invalid state route, compute that state route, and we're going to place it onto the main chain as a block. Oh, are they going to get away with it? What's going to happen? Well, everyone's going to notice that this thing is invalid, from either scan to you, to your infura, to every full node that's running in a full node optimistic roll-up chain. And they're going to challenge that invalid block. Notably, this challenge is not interactive. That makes it a lot easier, because honestly, these programs, these protocols are too hard to build. They're way too hard to build. I've done too much work, and I haven't seen enough progress. But now, they're way easier, because we made simplifications. So now we submit this validity proof. I'm not even going to explain it, because it's just so ridiculously complicated. But you can read the smart contract, and we will have it formally verified, because formal verification is important. But that verification is not validation. You should read about it. Now, also, we're going to burn the aggregator deposit, because this is a totally, totally attributable fault, and we all have a challenge successful. So great, we can delete that block, and we can continue moving. The aggregator got screwed, but there's another aggregator to take its place. Anyone keeps going, great success. You know, it's very good. So if you don't understand what I just said, which no one did, then you can just think, we put a blockchain on the blockchain. It's real easy, everybody. Put it in, the in, the in. There's the Fibonacci, there's the golden ratio. Breathe deeply, okay. But can it run Uniswap? Yes, my gosh, of course it can run Uniswap. That's why we did it. It's very, very hard to do. Oh, oh my God, I'm exhausted, whoa. Okay, well, not only can it run Uniswap, but we built it in the past month and a half or something, we worked very hard. Shout out to everyone, Will. And the Uniswap team, so sorry, we collaborated with the Uniswap team, us Plasma Group, them Uniswap, and we created Unipig.exchange. Everyone in this audience has used it, I heard, right? If you haven't used it, you have to go to Unipig.exchange and support the team Piggy. There are two tokens, one Pig, one Uni. What you do is you get AirDrop to Piggy and Uni and you dump the Uni, that's the game. No, I'm just kidding, you can dump the Piggy if you want. And notably, we're doing this and we're solving those horrible UX problems that I talked about in the beginning. For instance, there's no approve all tokens. Of course, you can solve this on main chain Ethereum and you should. Don't do the approve all things. It's just very scary, unless you're really confident. Maybe don't do it anyway. Another thing is we get pretty good transactions per second, we're not at plasma infinity scale, but we can get easily 200 transactions per second, put, bump it up a little bit more. This is, by the way, based on the availability bottleneck that I'm talking about. And then additionally, we can get way, we get a 2000 if we optimize with something like a BLS signature, but that's also pretty hard and definitely we'll get to 200, 400 that area and then we can hit the BLS optimization if we so choose and then we get way more with Ethereum 2 or any availability oracle that we choose. If we make the data available and we trust it's available, then this scheme works. Additionally, probably my favorite thing, I don't know, is how fast these transactions get confirmed. We get really, really fast transaction confirmations and this is basically, you can tune the optimistic roll of parameters and get either fast confirmations and anyway, we can go into that in another lightning section of one of these talks. So this is pretty cool. It is a user experience that kind of rivals centralized stuff in my humble opinion and also is a secure Ethereum DAP. I'm very, very happy. So Unipig.exchange, shout out to all the people who made it. It's really, really amazing that it came together and Team Piggy, y'all Team Piggy, get it to represent. So back to Vitalik. We're setting the foundation for innovation and part of that foundation means giving users good user experience so that when they use Ethereum, they're using, they're feeling good and they're not dropping off after the first two minutes and we hopefully can provide the same, we can provide the same smart contract development experience that we know and love about Ethereum and we'll know and hate but we'll get better, we'll work together to get better and make Ethereum smart contract development and experience even better. And so back to this wonderful tree. I don't remember how I tied this in actually. I made these slides very recently. So just pray for my plant. I just hope it gets better. I just hope it gets better and grows into, that's right. It's gonna grow into this magnificent plant because right now the soil, the lighting, the watering, definitely my watering is sub par and so hopefully with the right circumstances it will grow into this amazing thing and so we can use cryptography, we can use economics and really achieve the global impact that we want and notably remember that whole, the debt discussion and that stuff that the last presenter was talking about. That's a very real thing and I'm very worried about that as well but once again, this is a humble talk about user experience. Thank you very much. I technically should have a two minute, one minute, something like that for questions if y'all want. Everybody wants. Is there just one aggregator at a given time? Great question, in my diagram there was but it's a very goofy, it was accidental to be honest. No, so there are different schemes but probably in all of them essentially there are multiple aggregators. Because we have this property that we can detect in validity and like attributably destroy it, it makes it much easier for a bad aggregator to come in, submit an invalid block, we just prune it and then we go on with our day. So it's not this kind of, you need one aggregator, one system that we have in off-chain systems oftentimes because the actual, the downside of a really malicious aggregator is huge. We've kind of reduced the bad things that they can do and that gives us the ability to have many. Do you also have denial of service issues where I could know who the aggregator is and take them down? If we're all talking to one central server, could I like to ask them? Oh yeah, 100% and I heard this person say that they feel like we think a lot about clients but we don't think enough about aggregators because aggregators are going to be like real targets for denial of service. Now how we solve denial of service, of course there are fees that's clear but also just general like our traditional DDoS vectors will have to employ standard techniques and we actually have employed standard techniques on our Unipig.exchange to kind of protect the aggregator. But don't mess with our aggregator. Cool, thanks, it was a fun talk, thank you. Oh thank you, I appreciate it. Can you get that down to one minute for next staff gone? I'm planning on investing all of my time and energy into telepathy so I can go on stage and I can just go and then leave. So next time. All right, great talk, man. Can you explain more about the verity group that you have used that it is complicated? So how can I prove that the state transition is going wrong? Great, so I'll answer it from two perspectives. The first perspective is pretty simple, from a client perspective, all I do is I take all the transactions, I run them locally, I compute the state route and I compare the difference and I say if the state route is different, I know something went wrong and I can automated easily send a transaction, proving fraud and delete the prune the block. Now from the kind of formal verification of the smart contract side, this gets into a whole nother area of how do we make sure that we sandbox our state transition environment? How do we make sure that we don't run into out of gas issues? How do we make sure that we are doing all of the hubbub around formal verification and of course auditing? However, thankfully this is a closed system built in a smart contract and it's so it is very isolated. One of the real problems that we faced with layer two constructions oftentimes is how do you audit this multi-agent, multi-party distributed system where everyone is adversarial? Turns out to be extremely, extremely difficult. So doing that is quite hard and doing an audit for a smart contract state verification game is at least more tightly scoped. So that is the hope for why that is significantly easier. And actually in fact, we know it is significantly easier to do the smart contract style stuff because if we were to think of, for instance, building a order book exchange on optimistic roll up, technically you can do that, but doing Uniswap was way easier because everything is on chain, everything's in a smart contract, there's like, it's much easier to kind of manage conceptually. Anyway, a little long winded, but that's that. Thank you.