 I'm really interested at, and I think a lot of people in the security field sort of should be as well, and that's escape hatches for roll-ups. You've heard a lot about roll-ups, so let's give a brief introduction about what they are, and then we'll talk about the specific feature I care about, and then we'll talk about some features that those features should have, so what a good roll-up might want. So this would be sort of similar to my colleague's talk from earlier, except not Bridges, but... Okay, so what is a roll-up? You know, attended a lot of these talks here at DovCon or Elsewhere, you know, you see a bunch of, more or less, you know, mutually consistent definitions, but essentially it's some sort of layer two scaling solution or maybe layer three or layer four, if you're really forward-thinking, and it's some system that just takes transactions and executes them off-chain, and then batches them and compresses them and does something to get you some sort of savings and pushes some data onto layer one, and so essentially it's a system that's replicating your layer one blockchain like Ethereum, but it's doing it elsewhere with some nice advantage that gives you, you know, scalability in some sense or savings. And so how does the system work? Well, usually you get some transactions, and then your system design is very dependent on the implementation, but typically there's something called a sequencer that gives an order to the transactions that are taken, and then this order set of transactions is executed in some state transition function, the state is updated, and something gets pushed to your layer one chain, where it's, you know, eventually considered final. But this is great when everything works, but what happens when things don't work, in particular, if your sequencer goes offline or some other component possibly, but typically these escape hatches are discussed in the context of sequencer failures, what happens? Because if you had a bunch of money or assets or tokens locked up in one of these rollups, and suddenly the transaction that says, give me my money back is no longer sequenced, you're kind of screwed. So the functionality of an escape hatch is some way to get program state or digital assets, because, you know, tokens are basically just program state, off of this rollup system, even when your sequencer or some other component has failed. Now, obviously there's some sort of caveat, some things probably can't fail and always work with an escape hatch, right? If you have a bug in your smart contract, maybe no escape hatch functionality is going to work, because maybe that's what's broken, but we'll talk about that. And some people have actually started to look at this. This list, thanks to L2B, but rewritten for our paper, does suggest that various rollup projects right now are thinking about this and trying to implement these solutions. Now, some of them have the none there, we're not going to talk about the specifics, and I'm also, unfortunately, I don't have enough time to talk about even one of these approaches. But if you are interested, let me know or go contact the project and say, hey, how do you do this? But even when they're implemented, they're often not exactly done. In some cases, the design is not well understood. In some cases, the code is literally a stub, and it says, hey, it's going to come later. But now that the rest of the rollup functionality is done, like the ZK parts are all coming together and everyone's got rollup state working, it's time to start thinking about this feature that you sort of kept pushing off into the future. Because ultimately, while I hope this feature is never used by any rollup ever, we would like to see it exist so that if someone does have any issues, you get your funds back. And things work out in the user's favor. And then, ideally, you fix it and your rollup gets back up or whatever. So it's being done, but maybe not done all the time or entirely correctly. And so I'm going to discuss what I think some nice features would be in a rollup. Now, these would vary. And just like in the cases for bridges, for features, some functionality is probably contradictory, and you can't necessarily do all of these at the same time. But there's some things that probably should be nice and obvious. First, they should be well-engineered components of the system. That usually means very modular, and in case you need to upgrade your rollup, you can upgrade part of it or all of it, or just this part. Maybe this is the only part that's concerning, because if you saw on that list, some people just force a transaction, whatever that means. Others suggest proposing new blocks, whatever that means. But this should be a full-fledged feature, not an afterthought. Second, it should be secure. Well, we always think about security at Quadsnip, and certainly a rollup is essentially a bridge that's even more complicated. And we don't want to have to deal with exploits that arise for the rollup because of this functionality. If you do this, do it right, and make sure you test it and not of it and all that. And finally, it should be corrected. You shouldn't really have to use consecutive escape hatches. This is a bit confusing, but I have heard some people say, well, our plan for a rollup escape hatch is to just migrate the state to another copy of our rollup, and then everything will work. But as a user, am I going to be really trusting of the same type of rollup that just went down on me? I'm not so sure that that's going to be the case. So ideally, something that gets you out of the system, maybe correcting some of the best name, is something that I'd like to see personally. But beyond that, we can think a little bit deeper about what it means to escape from a rollup. In particular, if you're taking assets out, that's pretty well understood. And a lot of them do have functionality for forcing transactions for ERC-20 tokens, for example. But what do you actually really want to escape? Maybe you want to escape more than just ERC-20 tokens. The obvious case is, what if you have an NFT minted under a rollup? Obviously, you probably want that back, too, without having to go through extra hoops. This also very much depends on the actual bridging that's being done, but maybe there's some other things you want that are valuable to you. They should be built in. If you have a DAP that you have on L1, you should sort of migrate it to L2 and sort of expect minimal extra friction introduced by this feature. So in particular, if that DAP is supposed to escape some state as part of this functionality, it should come for free in error quotes, because doing extra work sucks. And finally, it should be transaction efficient on the layer underneath. If you escape from a layer or two rollup and everyone else is trying to do this, there's going to be a gas for, and things are going to get expensive, and things are going to get messy. If you can do this in a nice way that aggregates many user state or does something clever, I think that's really the way to go. Now, I'm not saying I have solutions for these, but that's just what I want to see. Some other properties would be really nice. Be global. So in particular, if you call an escape patch functionality, you don't have to do it for every DAP that you've deployed on that L2. So if I'm using Uniswap and something else on some rollup, I want to just say escape everything, not escape Uniswap and then also escape whatever the other DAP is. That would be ideal. That would make my life a lot easier. And it should be automatic and live. Ideally, it's always available, because who knows when the system could go down? Hopefully never. But if it does, we don't know when it'll be. And it should be triggered hopefully automatically. So we're not depending too much on social consensus. I mean, it might be unavoidable, but it should be very clear when you can trigger this functionality, and when you want to do that, it should be available to you. Or at least the community should be able to make the decision. But automatic would be ideal. So that's what I think they should do. Have I missed anything? Please let me know. Do you disagree? Please also let me know. You can contact me, email or put her there. Find me around here. And we do have a write up of this at a non-blockchain conference. So I can send you some papers about that. Thank you.