[trustless://interop.landscape] Workshop - How to build a Stage 2 Ethereum Rollup

Transcript

Hello everyone. Hi, thank you. I'm Tom Layman from Facet and I'm here to present on a topic called how to build a stage two Ethereum rollup. And uh Facet is the only general purpose stage two Ethereum rollup. This is from L2B. So uh those are my qualifications. I'm and I'm here to talk you all through how to build uh a stage two rollup. How we did it, how you can do it. But actually uh this morning something happened. Uh I click this button. Uh this is the uh sign the trustless manifesto pledge pledge button. I'm sure you've seen this pledge. And uh the issue if you read this pledge, you sign it. You have to um pursue the cause of trustlessness. And actually after I sign it, I realized I can't give uh the presentation I wanted

to give. I have to give a new presentation which is called how to build a trustless Ethereum rollup and why stage two actually isn't enough. If you sign this manifesto, you are not allowed to give a presentation on uh why to and how to build a stage two rollup. And I'm going to tell you I'm going to tell you why. Okay, so to review first uh the stages, right? If you you go on L2B, you can look this up. Uh and here are are the stages. You need to have something simple and I really appreciate L2B even though I don't agree with everything on there. Uh green, yellow, red, you have red stage zero, that's the centralized stage, fully centralized. The green stage two, that's fully decentralized or that's the idea. And then you have the kind of centralized in stage one. If you see uh L2B today, you'll see many many

people in the kind of centralized bucket and only uh two people only two roll-ups in the stage two bucket uh and Facet is is the only general purpose uh one. But uh is stage two actually fully decentralized? And um in fact, was Facet's goal even just to build a stage two rollup? Well uh if you look at the criteria for stage two, you can see there are um there are a few elements. Uh first two elements are pretty uncontroversial. uh anyone should be able to exit the system uh withdraw your money without operator uh help. So that's a fully open proof system. Uh you should be able to get transactions included without um a centralized sequencer helping you. So that's forced transactions. Uh and then there's this question of the exit window. Uh stage

two rollups are still permitted to have admins permitted to have privileged users who have more power than normal users. Uh but this uh power is restrained by an exit window by uh a restriction that if an admin wants to change the rules of the system uh in a way that hurts you in a hostile way. Uh they can't do it immediately. They have to give you time to react. A 30-day exit window uh is required. And so one question you might ask is uh how good is this uh exit window? Uh and particularly how good is it for trustlessness if you sign the manifesto? If you didn't, you should listen before you uh sign it.

So if you believe in the trustless manifesto, if you signed it, you cannot support exit windows. This is my uh contention here and this is why you cannot support Sage 2 alone. And the reason for this is very simple. Trustlessness requires absolute guarantees. Okay, this is an absolute question. Is a system trustless? Right? So one absolute guarantee is this is a quote from the manifesto uh censorship resistance. Any valid action can be included, right? any valid action. Okay. Uh an exit window gives you this for the next 30 days. During the exit window, any valid action can be included. So what is the difference between these two guarantees? Obviously um a lot because of you know 31 days out uh you have no

uh guarantee. And so you could sign a modified version of the manifesto that uh restricts the guarantees to the duration of the exit window and that's fine. uh but if you sign the main one uh I don't think you can accept the fact that censorship resistance is not uh absolute and so you know the trustless manifesto also uh mentions landlords landlords are a good metaphor for uh uh for this you know you have a privileged person uh who has power over uh where you live right in the real world that's pretty powerful thing on the blockchain uh it's equally powerful when you think of uh someone in that position and uh if a landlord can shut you out of your uh house. Uh that's bad. Even if they can give you a notice.

Worse still, in the real world, you can take your stuff with you if you get evicted from your house. You can pack up your couch. Uh but in the rollup, uh there are things you can't take with you. So if you have uh assets that you've issued on the rollup, if you have in progress open bets, so perpetuals, uh if you have a vesting contract, you have things that uh are in progress that cannot be easily settled in time to leave. uh you can't exit with them. And in fact, we see a very surprising fact which is that uh the Ethereum uh foundation's own guidance is basically don't issue assets on the L2. Don't create things you can't move when you get evicted. Right? The Ethereum Foundation says uh you know issue on the L1, bridge the L2. This is on the Ethereum Foundation's guide to uh

institutions using Ethereum and this is you know good guide for anyone using uh Ethereum today. Don't issue on the L2. That's what they're saying, right? And that is very valid advice. But you might want to ask yourself uh do I want a system where I can't issue assets? And users have spoken uh they're issuing a ton of assets on the L2. And in fact, you have to issue assets on the on the L2 when you use apps. Liquidity tokens are one very simple example of this. So uh this is a difference between the L1 and the L2 that we're going to unpack a little more. So perpetuals are a great example of this because the uh reason that perpetuals can live on a blockchain is because blockchains can have at least nominally this notion of perpetuity. It can go on forever. You can have open bet

uh forever. There's no built-in uh system within the EVM that limits uh the duration of a contract's existence and ability to compute. 30-day exum is not perpetual. A thirdp is not a perp is that as good a 30-day. The point is you could have a perpetual called ap, but no one would buy it. People want the perp, the real version, the perpetual that lasts uh the full um uh the full duration of the open of the open bet. So what we need is uh rule by code.

That's what trustless is about. Rule by code, not by landlords. And uh that means we can't have landlords with power. Very basic. So uh no one should be able to change the code that governs your uh experience on a blockchain if that blockchain is going to be called crustless. No one. It's immutable. And so this is an interesting parallel. You might imagine like, okay, there was a time uh on the iPhone when you had to manually update your apps, right? Every time you need to update your app, you'd open up your phone, go to the app store, update your app. Very, very inconvenient, right? Then they released automatic updates. They in fact have automatic updates on your uh operating system on your iPhone at least. You might ask yourself, why not do that for the Ethereum L1? Why not build in an upgrade ability into Ethereum nodes to

enable the Ethereum Foundation to upgrade everyone's node went to the correct version quotequote correct version when there is a hard fork so much more convenient than what has to happen today which is you have to actively take an action uh obviously despite convenience people would uh reject this right because uh the upgrade has to be uh voluntary and the uh roll-up environment is not different from the L1 in this way we should have the same demands so we need immutable roll-ups. How do we do it? This is kind of the other side of it. So, the first element is transaction inclusion. Can you do anything on the rollup? And this is uh a fairly simple thing uh to fix, which is why it's kind of bizarre that today uh roll-ups um are so adminated on force inclusion because

you know the term force inclusion uh sort of indicates that if you're forcing a transaction, you should be able to get around these admins. You should be able to do it anyway, even if the ads want to stop you. And yet in typical rollups force inclusion uh flows through a smart contract that is admin controlled and admin upgradeable and this can be actually uh disabled. And so uh the first step and this is like a very simple thing I think robes could do today is to stop routing force inclusion through an upgradeable contract and do something different. Either use an immutable contract uh or an EOA address an address with no code. And so uh [snorts] you could do either just you know by way of example of facet we use an EOA inbox for forced inclusion which is uh this all zeros in phase 7 looks

like uh facet uh this is nice because if there is a hard fork users can continue to use the same inbox uh they don't have to change contracts when the rules change because all of the rules are enforced uh offchain. Um that's one way to do it. You could do an immutable contract. I think actually the best thing to do uh and what we are working towards is to enable any address to be the inbox for force inclusion or any type of uh transaction sequencing and the uh the benefit to doing this is uh you can have um the the fewer restrictions you have the greater potential you have to share data availability with other uh roll-ups. So if two people want to uh force transactions on two different rollups they should be able to do that in the same Ethereum L1 uh transaction.

So now we have the uh the question of uh the proof system. So this is the main uh you know we're got to protect users. You know training wheels uh you know standard roll-ups have uh proof systems that support messaging. Uh but these uh cross-dommain messaging proof systems have uh back doors or training wheels as you might call them uh that enable uh bugs to be fixed and uh systems to be tuned for new to new upgrades. And so what you end up with is the uh entire structure of L2 L1 messaging on these roll-ups uh governed by uh admins. And so no contract on the L1 can uh trust that uh with unconditionally without also trusting the uh the admins. And so what we need uh here which is obvious

based on what I've said so far, but also how are we going to do this, right? We need immutable proof systems. We need to get rid of upgrades on proof systems. We need to get rid of uh training wheels. Uh we need to make them fully uh immutable, right? And so, uh, easy to say, right? Easy, pretty easy to say. But, um, you know, what about proof system bugs, right? This is the, uh, you know, you can see a lot of, uh, uh, discourse about this, right? Shout out to Tim Clansancy. Shout out to Sigil. You know, I saw Tim, uh, going back and forth with many people on on Twitter. But the, uh, the idea keeps coming up. If you have an immutable proof system or even a proof system with an exit window, how are we going to protect user funds? Because there are bugs, right? There are a lot

of bugs. These are three random tweets. They all kind of relate to succinct, but you could Google for two seconds and see a million bugs basically for uh uh proof systems. And this is understandably scary. On the other side of the coin, you have the bugs with the multisig. They're not exactly bugs in the same sense, but uh they are uh surprising uh tricks that have been pulled that are impossible to uh anticipate uh in advance. And so in that respect, they are like bugs. They can't be found by uh inspection. You know, who could have ever uh seen foreseen how uh the buy hack would work? So uh from the first instance here uh the proponents of upgradeable admin proof systems have a little bit of a challenge. You can't just say the bugs are the problem uh with the proof systems. The bugs with

the multisigs are also the problem. And um you know one question is you know which bugs are are worse right? So uh you had um uh you have Vitalic wrote this great blog post and he said uh here are some admittedly basic assumptions right his assumptions are not good and he admitted them right but it's a good place to start shout out good for him for writing this and he said here is the model here is the model uh in terms of what you have to assume about how good the proof system is versus the uh uh uh corruptability so to speak of the security council and here's how you choose what stage you are on uh today everyone universally and there's only one general purpose stage two rollup uh which proves this everyone universally chooses assumptions uh that indicate

that the greater risk is um proof system bugs but uh where are the models right so this is my shout out it's like if you believe that the proof system bugs are worse uh you should make a model and spell out your assumptions and say and say why uh because uh both things are are bad and so you know just shouting out the trustlessness manifesto uh is it an excuse or is it real we don't actually uh know I think think the people who are uh um believe proof system bugs are worse are genuinely trying to create good outcomes for users. Uh but it's always tempting to have admin control. So anyway, the big picture here is proof systems are prone to bugs which is tough. Uh multisigs are prone to bugs which is tough. Uh which one you view as worst depends on you

know how you model things. But uh since we're looking from the perspective of trustlessness uh we are trying to uh eliminate the the the admins and see if the best we can do with uh a trustless uh system. And so how can we do that? So we're going to do that by kind of changing a little bit about how uh rollups uh work uh or at least in terms of thinking about how what roll-ups are supposed to be and supposed to accomplish. Okay. So um there is this um you know the issue with proof system bugs is that they lead to users losing funds but they don't have to. Okay, proof systems are abstract ideas uh and um they don't necessarily the consequences they have depend on uh

interpretation. So uh when we talk about uh rollups uh there's a lot of uh often the term bridge uh gets two concepts conflated. So uh there is one side of bridging which is messaging communicating back and forth messages between L1 and L2 smart contracts. Uh and there's another side of bridging which is actually holding on to funds on the L1 putting funds into an escrow contract and uh removing them based on the messaging system. So, uh, the messaging system says, uh, you know, hey, L1 contract, this is me, your L1, L2 friend contract, and I'm telling you to release some funds to, uh, to Tom, and it's going through this, uh, proof system, um, secured messaging system.

And, um, and then the L L1 escrow is the app that decides what to do. So, if the escrow uh, hears this uh, claim, you know, hey, I'm the L2 friend of yours. Give Tom money. Uh, the L1 Escrow can uh, decide what to do. and uh they don't have to trust uh messages blindly. The apps that are consuming the proof system are ultimately responsible for securing the users's funds. Okay, the proof system uh is a um at least in this vision, right, is a a neutral um kind of newswire that says uh here's what the code says the truth is and apps are responsible uh for adding safeguards or trusting messages. And

>> [snorts] >> um this is uh better because users can choose apps but they can't choose the rollup or rather once they're on the rollup they are committed to the rollup. And so uh you can have an app that chooses whether or not to trust a proof system or how many training wheels to add. And that app can be chosen or not chosen based on how good it is uh from the user standpoint versus the protocol wide landlord. So this is how it works on the L1. All of this is modeled on the L1. So, uh, USDC, USDT on the L1, they're overlapping. Neither are trustless. Uh, Ethereum is not trustful because it has trust trustful stable coins, right? Uh, what keeps the L1 uh trustless is that you don't have to use any of these uh

escros, right? Uh you don't have to use any uh uh uh you don't have to use any of these escros. You don't have to use either. You can use one or not the other and so forth. And the uh L1's job is to securely let you do what you want to do here. Let you choose or not choose. uh and that's how uh L2 bridge escros uh should work. L2 uh you know rollup should not be uh prescribing certain uh escros because if you prescribe at the protocol level then uh problems with the escrow infect the entire uh protocol. So uh this is how it already works today in fact. So you can see the red is uh appbased uh escrow uh value and the blue is uh rollup based uh escrow uh value.

And by rollup based I mean rollup uh uh uh uh escros that that that that rely uh uh completely on the canonical messaging uh system that don't add additional uh training wheels. And as you can see, users prefer uh the appd driven uh uh the app-driven sources of value. And um this is something where um there is one giant exception though uh and this is something that roll-ups do really need to uh change in order to fit this model is uh the gas token bridge.

So roll-ups can't get out of the business of escrowing funds if their gas token is minted in response to deposits to an escrow uh on the L1. In other words, you put ETH into an L1 escrow uh and then you get a protocol level asset, a gas token on the L2, right? So uh this links the L2 to this escrow. And so having training wheels on this escrow uh means that now uh the entire uh protocol can be compromised. you know, notably admins could, you know, freeze gas issuance or or worse still mint infinite gas themselves and freeze everyone out of of of transactions. And so, uh, again, we have this issue of a single, uh, escrow admin becoming the landlord

for, uh, the entire protocol, which is what we want to avoid. And so, on Facet, uh, we handle this by, uh, having a non-brbridgeged gas token. So a gas token that is uh uh that has no admin that has no L1 contract uh um that is capable of of minting it that is minted purely uh by um uh code. So when a user takes an action on the L1 in this case force including a fash transaction the uh amount of ETH they burned uh in that transaction is uh used to uh is multiplied by a mint rate to determine the amount of um L2 gas token or FCT as we call it uh the user uh gets. So uh there is no uh trust involved in getting the gas token. That means the gas token

cannot be corrupted. Uh which means that no admin can control the gas system and the rollup. And so this is a u a very big pill to swallow if you are used to using ETH on the L2. Uh but if you want to um avoid uh the trust associated with that, you really have no uh choice. Mutable rollups have three components. You need a mutable force inclusion. You need an imutable proof system and a proof system that doesn't say, "Hey, give this person money." It says, "Hey, this is what the L2 code says is true."

Right? That's it. The L1 has to decide whether that means to give the person money to let the person withdraw uh from the escrow. Uh and then we need an immutable gas token uh which um uh which very likely today means that it's an algorithmically algorithmically generated um native token. We needed a couple escros from the protocol and L2B is already doing this. Uh Luca Dono has a great post on uh L2B's discourse discussing how uh the notion of the canonical bridge in L2B is is is going to be shifted to uh refer more to the uh canonical messaging system versus any escro attached to it.

I think this is a very very important uh move they're making. And um and then yeah, just to sort of uh sum things up like this is not saying uh here is a better way to build a rollup, right? This is not saying if you build it this way, you're going to make a lot of money, your users are going to be happy. Uh same is true for Ethereum, right? You you cannot say uh Ethereum is uh uniformly good. It is a uh as the manifesto says is it is an enabler of freedom, right? Uh immutable roll-ups promise non-inference. users might lose money, but if they do, it's because of their relationship with an app that ideally they uh chose, right? It's not because the roll-up admin did something.

They have control of their destiny. And this is uh exactly what the uh L1 hopes to do. Uh not make sure that you don't lose money, but make sure that you have the freedom without interference to engage with apps as you uh as you like. And so there's this guy, Dio is a cynic, famous guy from history. His friend once saw him and says, "If you would eat lentils, excuse me, if you would flatter the king, you wouldn't have to eat lentils. You would be able to eat better food because the king would give you better food. You'd be more comfortable. You wouldn't have to sit in the forum eating lentils."

[snorts] And uh Dioynes said, "Well, if you would just learn to eat lentils, you wouldn't have to flatter the security council, I mean king." And so that's kind of what this is about. You should choose uh what you want. Not every rollup should endeavor to be uh immutable. Uh but uh every rollup that talks about trustlessness, every rollup that talks about the values in the manifesto uh and and and aspires to to live them uh in my view must be uh uh immutable. So whether you want to um you know eat lentils or flatter uh is all good. But uh read the uh if you sign that that that pledge, you should um you know take this immutability thing uh seriously. Thank you so much. And uh we have time I think for some questions.

Ask a question. [snorts] Don't don't run on each other. Just, you know, get in line. >> [snorts] >> Hello. Hello. All right. So, we have a uh remote uh question being asked. >> I can't I can't hear actually. Is there a >> Yeah, you can just come over.

>> I'm staged here. Let me uh let me get >> Oh, no. >> I got this. Yeah. Yeah, this is good. >> Okay, try now. >> Okay. Okay. the question. Uh, so I'm just the messenger here, but if we're encouraging L1 application safeguards on top of L2 proven messages, how do we prevent kicking the can of trustlessness down the road? >> Yeah, that's a great question. So, look, I uh it'd be quite something if I could come up and say here's the secret, right? You know, like here is the uh uh the answer where you can have and eat cake, where you can say uh we are trustless uh and we don't have to sacrifice uh you know, anything. So you know very valid criticism could be okay so uh you know someone needs to be able to be able to

secure escrow right so if the protocol uh is not going to do it someone has to do it and so who's going to do it right I think that's very valid and so this uh topic this um idea is not about saying uh you know uh I I recognize that by moving it out of the protocol uh we might simplify things in one place but create complexity another place is that a net gain I think yes it is a net gain and the reason is because users have choice about escrow uh about apps they use. It's basically that users have choice about the apps they they that that they use. And so uh you can have uh a competition between these escros and those will compete not just on the on the um uh on the dimension of the level of trustlessness. They'll they'll

compete on the entire world of what users want to experience, right? Users really like stable coins. Uh maybe stable coins are quote go bad or trustful or whatever, but you know users like them. So people compete for users. Uh so users have the choice. Uh the better uh escros will quotequote better. The escros that serve users will better will uh uh emerge. And crucially there won't be an issue where uh a single escrow's problem uh kills every other app and every other escrow. So you know the gas token escrow being this big example like if that's compromised on a robe today someone mints infinity gas to themselves bids up the gas price to infinity. uh the whole thing is is is the whole network is uh is broken whereas a single uh a single escrow is

ideally contained. Now you can say to that well even on the L1 that's not really true. If USDC got compromised then uh you know circle would you know force a hard fork through because they actually control the L1. So there's that issue too but that's also uh on the L1. I'll say another thing that's bad about my idea here, another objection against myself, which is that uh if you have competition over escros and that competition, even if that does a good job in terms of serving user interests, uh you are still going to end up with chaos, right? Like two escros compete for the same asset, right? USC, USCT are examples of of this. It's the same asset. It's a dollar. uh if you have that uh on a grand scale then um you're

going to have a lot of chaos. Users are going to be like wait I'm getting this this this token on the L2 that represents uh the same thing as this token but they have different trust assumptions. What? So yes this is a problem. That's another downside to this approach. Uh you get more chaos. It's a lot simpler uh if you just say price of admission at the door. The landlord uh I trust the landlord. The landlord controls uh everything. Which is why um I think not everyone should have a trustless uh uh L2 but uh if you are an app you should weigh um is having the convenience of one asset representation one security assumption all the stuff is that convenience better than uh the uh promise of non-inference

non-interference meaning that like you know it's all the stuff good or bad that happens is between you and and your users and so it's like non-interference versus that convenience and there is no right answer I would say basically like it's uh uh you have to you have to choose um as as an app as a user >> you got all >> uh what do you think about the future of immutable roll-ups like facet in uh a world where we have also native roll-ups >> right so that's a great question so uh what's up with native roll-ups how do they relate so um native roll-ups And there's a new EIP on this from the great Luca Dono. Shout out Luca if you're

watching this uh in heaven. You know, my theory is when you die, you get to watch everything that's ever been said about you or he could watch the live stream. But there's a new there's a new EIP about this that's either merged or not. Uh and I've been trying to get a chance to sit down and like really pour over it. But like native roll-ups are happening. Uh a it's going to be a long time, right? It's going to be years from now. So in some sense it kind of doesn't matter uh what we say because like who knows what the world is going to look like. uh then and the history of Ethereum is being made you know today but the promise of native roll-ups is the proof system is guaranteed to work right the uh uh the um the proof system is guaranteed to work that if the proof

system of the roll-up fails the L1 has failed and there'll be a hard fork and a social uh recovery and so in a world uh where the proof system is guaranteed to work then this uh changes then you could have a situation uh where um everyone can blindly trust the same proof system because they're you're trusting the same thing you have to trust anyway. There's no additional assumption. Uh and I think that would be great and that would definitely change this a lot. I would say that uh native rollups do require um obviously you know if you know about native roll-ups that one they require certain restrictions you have to have the uh exact state transition function uh that Ethereum has. Uh, so that's a major restriction. Has to be EVM equivalent in every way, right? So you can't have an extra pre-ompile. Like

when people say EVM equivalent, they often mean like basically that, but it has to be exactly the same. No pre-ompiles, which means maybe less innovation for some roll-ups that want it. So that'll be relevant. But the main thing I would say is uh native roll-ups are great. Uh they're down the road. They could change this calculus, but we have to like build them uh first and we should all like try to do that. And I definitely want to contribute. And it would be great if this whole presentation were rendered completely obsolete uh by uh native rollups for sure. >> Okay, so my question is um >> hold on a sec. My my thing died here.

>> Did I uh hold on this can I can I so annoying? Sorry. So sorry annoying. >> Can you hear me? >> Yeah. Yeah. Good. >> Good. Good. So I I would argue that not even Ethereum itself is mutable, right? So what do you think about instead of having full immutability have some decentralized form of governance? So not a single admin but decentralized voting on on upgrades, >> right? So it's a good question. So is so what's going on with even the L1? So part of it is I just want to say hey like L1's not my problem. Like I'm just trying to be as close to the L1 as possible. uh you know um so that's one thing like I'm I'm trying to say let's

get a rollup that doesn't have additional stuff like the L1 has code uh you have to accept that and norms the rollup has code let's have there be nothing else on top of the L1 as the code is kind of the idea versus like what's going on with the L1 but yeah how decentralized is the L1 uh anyway um you know this guy Vitalik uh very smart guy has outsiz interests uh there is literally the case of the you know uh stable coin holders like there's a very famous blog post on medium from like five years ago uh that says basically the L1 can never be forked again right this was five years ago the L1 can never be forked again because of stable coins the Dow hack can never happen or can never happen in that way the recovery and people on Twitter even recently were

kind of talking about this question what happens if circle you know wants to fork and then it's like welcome to five years ago like this is like a major thing so yeah I think uh the processes that uh lead to change on Ethereum are in practice rather centralized. Look where we are today. This is not just some random uh thing that happened. People planned this conference and planned you know everything around it and you know if you look at the EF's priorities uh they drastically shape what happens right like they put out these three priorities scale the other one scale the blobs uh improve UX and then you know that makes a difference in what is happening. Um, but I still think it's pretty great that you in the end end of the day at least uh you can keep running

the the old version. I think there's a soft power kind of thing there that keeps people uh in line. So, um I am still I'm still very partial to the way it it works where at least you can't force someone uh to do it. I'm also like my uh history in life like before this I was uh you know I have a whole origin story with this company I made called genius.com which is a lyrics website and I was the CEO of that and so in that many year thing I had all these experiences with like company governance who's man how you organize a company and board and corporate governance and um you know this was a pretty small company

in relation to what I'm sure many people out here have even like run or been in contact with and like it's just so hard. It is so hard to do uh good uh uh governance and there's a reason why um corporations in America uh you know are not are run by dictators basically like that is kind of the uh uh you know the dominant mode for for a reason. So um I think it's just very hard to do like the DAO type uh type thing. But this is somewhat of my bias maybe. But yeah, that's kind of how I feel about the about the L1. Shout out L1. I still I still love you.

>> Thanks. Yeah. >> Yeah. There's only one more question from uh Okay. No more. Only one. What? No. Okay. Okay. Anyway, thank you all so much. I really appreciate it. I'm Tom Layman from Facet. Uh please uh hit me up on Twitter, dumbname numbers. Working on changing that handle pending uh Twitter's uh marketplace, but you can always hit me up. uh really appreciate any feedback you have in this presentation or if you want to collaborate on anything uh relating to um immutable roll-ups. If you are uh or any rollup even with an exit window, right? If you are listening to this uh you are uh in the top 0.001% of uh people who care uh about

decentralization and trustlessness. So even if you agree with even you disagree with a lot of what I'm saying like we probably agree on a ton. So please uh hit me up and um and thanks so much. Have a great Dev Connect. Peace.