L2 Interop Working Group #11

Transcript

Uh yeah, welcome everybody to the L2 interrupt working group. We have three agenda items today. Starting off with a brief review and sort of yeah just a overview on the wallet and privacy work. From there, uh, we have Ian from Polymer on native interop upgradability and then finishing up with M team from Spire on based rollup uh, and how this fits into the larger interop vision. So starting off with privacy. Um yeah, so um just briefly touching on the topic of privacy and the experimental wallet

that um uh sorry that that folks from the EF Wonderland Amire and others are working on. We shared a bit about this on the last call. For anyone that that missed it, it can you can review the recap or recording from the last call. The TLDDR is we are working on an experimental wallet uh which is a fork of empire to help accelerate work around interop and privacy. Going forward the wallet will have a larger privacy focus uh which we believe uh is something quite critical and valuable to accelerate. Uh there were some uh recent understandable questions or concerns maybe raised around what exactly will this look like?

how are we thinking about which privacy protocols to leverage? Um, and just these kinds of things around okay, yes, like I think many people here agree around uh privacy being an important thing and the wallet being a valuable vehicle for it, but um there's some path dependence here and just some questions around what is this actually going to look like. So, um we may have Vitalik joining us to share his thoughts. I'm not sure if he's here right now. if you are um yeah maybe unmute yourself and jump in but um otherwise I think we also have some folks from the Wonderland team here. Yes. Um so maybe yeah maybe anyone from Wonderland if you want to start off and share your thoughts around the wallet and kind of latest thinking

around privacy there. Hey everyone, I'm Gorilla from Wonderland. Yes, to give you a very brief summary for the ones who have not seen the previous one, the wallet will enable in terms of privacy, private sends and private receipts. How can you send funds to another wallet without sewing either the sender nor the receiver and how can you make that like with an amazing user experience, right?

For example, how do you share your wallet address like the Stell's wallet address so that anyone can send money to it and then it aggropates to your real private deposit address without people being able to link those two together. There is some protocols which are aiming to help expand privacy in the ecosystem such as rail gun and privacy pools. The goal of the wallet is not to enshrine any of those but to create the privacy standards so that any privacy protocol can build on top of this SDK that the wallet will integrate. Yes, the LDR of the SDK

it's literally the heart and soul of what we're doing. Yes, the wallet like literally is the whole value of the Kohaku wallet that SDK. Our aim is to move the ecosystem forward and to get wallets like Metamas, Ravi, OKX and many others to integrate this this SDK and actually integrate privacy in an easier way. If they would like to do it right now, it would be nearly impossible or very very very hard. So we want to make it easy and to display the capabilities of that SDK. We will have the wallet prototype which is the fork of umpire.

Did I miss anything Josh that you want to share or scalia you want to add something? No I think you covered it. Um yeah or anyone else want to jump in? I can take the question from Frank Hido. Um, what standards are needed? So, we need a few things. Uh, the most important one is address derivation. So, for you to be able in a non-interactive way find the let's say private key or secret that you will use to deposit for another person. Um this is uh something that we are working with and it's

similar to stealth addresses as you know it. Uh there is also the standard of how do you um communicate that secret uh to the receiver. For example, hey I created uh this secret for you. How do you find uh that you now have u an increase or or a new note or a new private private balance? uh and then there is a more uh boring standard which is uh APIs and how the does the wallet actually communicate uh with these uh privacy protocols um which is not so fancy but it's something that we need to standardize as well for the SDK um and that's mainly it uh we do have some components uh of chain

regarding indexing and how um to be able to as privately as possible will not leak information when you're trying to find your secrets. Um but yeah, that's mainly it. We'll have more like we have some details on the address reservation. Uh we can share a document uh with you guys uh right now on the chat. Next site, did you want to jump in? That's for me. Yes. Sorry. Yeah.

Awesome. Um, cool. Yeah. Hey, hey, everyone. Um, so, uh, real quick, I just wanted to, uh, to kind of give you a quick update on what we've been building so far. Um, I think it's kind of relevant to to our call. Um, I I posted very quickly on the chat uh, group I think last week about that. So, yeah, it's mostly related to to privacy. Um what we are doing now is um within service network. Um so service network uh is L2 based on the linear stack we do uh GS transactions um natively meaning we like anyone can submit pretransactions. Uh we implement

a spam prediction backed by ALN so ZKP um to guarantee that you're not spamming the network. Um, and we also have status as an app, right? Like the the the OG wallet. And so the goal now is to implement more privacy into what we're building. Um, and uh, one of the cool aspect of GS transactions is that it reanimizes the wallets because you can basically submit transactions from wallet that has zero gas. Um, and so it's not like with all the different uh privacy solutions that are currently implemented where you

always need to found somewhere a relayer, a bundler, something that will kind of take charge of that and so that in the end it kind of links to other wallets and and for the anonymity um of the the wallet it's not very good. Um, so with G transactions we can really have like a pretty pretty good anonymity set in the end. Um and and so we're working now with rail gun um to implement their solution at the uh kind of base layer on the L2 um meaning that uh from the status app uh and from any uh app that will be built on status network you'll be have you will have the

choice to either go private or not. Um, and so it's very early still. Uh, but it's just like I I wanted to to kind of u get you guys feedback or like at least let you know that yeah, we're working on that direction where we want to have uh private transactions and private app interactions built in at the wallet level but also directly on the chain as well. Uh and by the way uh Lineia so we are based on the Lina stack. So Lineia is also working with us on that. Um and they are currently implementing rail gun for the Metamas cards. And so the goal

is basically to also have it implemented uh at the MetaMask level. Um we we're not there yet, but yeah, it's it's going to um to be we're working on right now. So probably in like next few months we'll have some something to show. Awesome. Thanks. Cool. Anything else on this topic? Try our test nets. It's free. You don't have to bridge.

Sounds good. Cool. Uh well, if nothing else on privacy, we can move on to the next agenda item. I will hand it over to you, Ian. Thanks. Let's see if I can share my screen. I haven't used Oh, yeah. One second. I got to let you Okay, there you go. See if this works.

Sorry, I've got to adjust my permissions by computer. I'll have to leave and rejoin.

Yeah, I also might be able to share much second. Hey, Mac OS tells you to restart. I think you don't need to. Yeah, I was going to say. Oh, you've had the same experience. Yeah, exactly. Okay, I'm going. There we go. Here we go. I think this will work now. Okay, here we go. Yay. Cool. Um, see if I can see.

All right. Thank you. Sorry about that. Um so yeah today I want to talk about something which I spoke about at Zuberlin and I think I spoke to a number of you like separately as well about this topic. Um and so sort of the basis of this topic is assuming like the foundational axom is that um you know eventually we do want to achieve native interrupt between rollups and by native interrupt what I mean is interrupt that's verified as part of the L1 state transition function you know under L1 consensus and this is achieved um it's achieved using the outputs that rollups settle to the L1 and you know looks somewhat like this and then of course other roll-ups can absorb

those outputs into their own execution environment. Whether this is done using L1S load or L1 origin uh once they have these roots inside their execution environment, you can make arbitrary you can verify arbitrary claims about the counterparty L2 inside of that uh L2 execution environment. So that looks great in theory, but there's this problem in practice that actually every rollup basically settles somewhere different and in a different format. Um so it's very heterogeneous the the layout of the uh outputs on the L1 and so it becomes quite difficult actually to deploy a contract on some L2 that is configured in a way that it can locate and make sense of the settled outputs of

all the other counterparty L2s. Um, essentially what you need to do is you need to configure this verifier contract with a mapping of chain IDs to a location and a format that that uh that the L2 corresponding to that chain ID uses when it settles. Um, and you know, you could do this with your verifier contract up front. You can figure configure it with this information. Uh, but roll-ups are not oified. Um, so what happens when you know the one in the middle here changes? it upgrades from let's say optack bedrock to opt uh its settlement location its settlement format it it changes in that process or what happens when a new L2 enters the system and we want to also connect with that L2 well we need to

configure it as well um and so what this sort of necessitates in practice is that you have to have some upgradability in your native interrupt uh verifier contracts because Ethereum is upgrading the L2s are upgrading and so these verifier contracts have to be able to upgrade in order to maintain par with the system as as it evolves. Um, and this is obviously a bit of a problem because you don't actually achieve native interop, right? If you have a multi-IG somewhere in the system that allows for upgrades to occur. Um, so is native interrupt even possible? Like can we actually even achieve this in practice without a fully oified system, you know, without effectively having

sharding? Um and I think that you know I think this is something that everybody has come up across you know various teams have been working on native interrupt protocols such as bases standard and and arbitrums broadcast standard um and so anybody who's been working on native interrupt protocol has surely ran into this um and I think you know at a high level there's basically like three ways that you address this either we standardize settlement um which probably never going to happen. Um you know you can have standardization within a cluster which is this is kind of an argument actually in favor of like incluster interrupt because part of what you solve in incluster interrupt is this

problem. uh but you still need to interrupt between clusters, right? I don't think anybody I think everybody on this call will agree that we're not all going to agree on a single uh rollup stack to use. Um but perhaps within different roll-up stacks is a way of standardizing settlement logic such that it is shared across otherwise divergent stacks. Um and of course native interop or sorry native roll-ups are another opportunity where this type of uh the settlement logic could be standardized as part of a native rollup. It could actually be enforced through uh the native rollup pre-ompiles potentially.

Um so I think that's something to consider. Um but then again you still have the problem where not every rollup is going to convert to a native rollup and so you still have to have a way of bridging between the native rollup cluster and other clusters. Um, so another way of approaching this would be to push the upgradability down to the L1 um, and have somewhat of like a configuration or registry contract on the L1. Um, and then you can actually use the L1 view or you know the L1 origin or L1 S load to prove updates to your routing in your system. um just based on changes in the configuration that occur at one place on on the L1 in this L1 contract, you can absorb those changes into the L2s to affect those

changes in the L2 contracts. And the advantage here is that by pushing the upgradability down to one place on the L1, well, it's easier to maintain like a a better like a higher quality security council to to to you know to manage the upgrades of this single contract on the L1. Uh you could potentially have like a consortum of like people from every major rollup who are part of this security counselor for this like shared registry contract on the L1. Or you could even taking it a bit further. You could put it under the purview of the L1 fork choice rule where this is like a system contract that gets upgraded only you know during hard forks or you know according to the L1

validators and that would truly put this under uh this that would truly make this allow this to be a native uh interop in the sense that it would be the L1 validators that are uh controlling this routing information. Um and then you know a third and it's worth mentioning here that this has some overlap with the onchain uh config work that's being led by Marissa uh which is focused on the ERC 7785 uh right now. Um I think you know potentially we could add this information on top of uh the other information that's already stored in that config contract. And then the third approach which is I think like the sexiest best approach in theory um would be that every rollup sequencer in the

same way that they should be absorbing the L1 state route into their execution environment according to the L1 origin uh or in order in order to support the L1 origin they could absorb essentially all of the settled outputs the latest settled output for every other rollup that they're aware of um as part of their state transition function. And this has the advantage that it reduces the level of um the levels of Merkel the number of levels of Merkel proofs that you have to uh provide to prove a counterparty state because if you do it using the L1 origin view or you do it based on having uh yeah if you do it based on the L1 origin view you first have to prove the settled L1 the settled

L2 state inside of that L1 view and then you prove your L2 state inside of that L2 state route that was in that output. Uh but if you just absorbed the outputs directly into the L2 execution environment, then you would only have to provide a single merkel proof against the L2 state route that was absorbed uh into the L2 execution environment. But I don't think this will work in practice in part because uh some stacks when they settle, you know, you don't actually store uh like the actual roots in storage. You store like a hash of them or a commitment to them. And so it's not as simple as like reading from a location on the L1. You actually need to like run a full node for the L2 or communicate with a full node for the L2

in order to get the pre-image for the hash that was settled to the L1 cuz the actual the actual L2 state route is not, you know, present in a storage slot on the L1. Instead, it's a hash that commits commits to an object that contains that state route. Um, so that's actually all the slides I have prepared. And yeah, I kind of just wanted to stop this and leave it as like an open question for discussion. I'm curious what other people are thinking about this. Maybe this is like a little too far out. I know it doesn't really relate to our current uh priorities of you know, improving interrupt UX uh immediately um because this is a much further out problem. But you know if the goal long term is to support native interrupt um once you know once we have

real-time proving etc that has settlement times uh much lower than they are today then this is something that we should start thinking about now in my opinion which of those options do you feel like is the most feasible as of right now I two two feels like the best way to deal with the variety amongst rollups because one and three both um just seem to have a lot of nuances for edge cases. But I'm curious which one you feel most optimistic about. I I I agree with your analysis there. Um, and actually we've already implemented like a version of this registry contract. And I should add that like a lot of this was actually

inspired by arbitrum's prover pointers. And in a way this registry on the L1 or this configuration contract on the L1 can be thought of like a global prover pointer that has been pushed down to the L1 instead of having to like maintain different prover pointers uh inside of the L2 execution environment. Um, and I do think that like today this is actually kind of the only way you can handle it. Um and um yeah, I think the amount of standardization that would be required to handle it using the first or third approach is probably not um achievable or I'm doubtful that it is.

Got it. Yeah, that's helpful. And and and the the pattern was a little bit familiar with with broadcaster. It makes a lot of sense. Um especially if you can just bank on the L1 being the best place to go to get that information reliably. Yeah. Oh, thank you. Cool.

Well, thank you, Ian. Any other Oh, yes. Calvin, do you do you plan to propose an ERC or make this uh contract into an ERC? Maybe. I think I'm I'm I'm kind of curious what people think the best route forward is because yeah, I don't want to I guess I don't want to spend time too much time writing a standard if it's not something that people will actually like rollup teams aren't actually going to adopt. Um so I think it's important that there's like some consensus arrived at ahead of time so that we know that you know the the standard will actually um uh it'll actually amount to something is is my opinion. Um, I think the probably the best way forward would be to I think

roll it together with the uh the ongoing uh uh L1 chain config work that MRSA is leading. Um, and yeah, perhaps it would be just a uh an addition or a amendment to the um existing ERC or maybe another ERC as well. Okay. Yeah, I can send the link to the group where we're started to chat about some things. Thank you.

Yeah, I think that's a valid question. Um, you know, and like yeah, the kind of the founding axom, right, is that this is something that's worth pushing for. Um, and I personally think that it is, but you know, that's just my personal opinion. I think you could also make the case that the um the relative size of a of a given crosschain um if it's just a a transfer as the simplest use case um really plays a big part in what different especially in driven solutions or even like native off solutions you could use um if you have a very large amount if you've got you know 100 million that you want to move between uh

base and arbitrum um in either direction then um there are few solvers um or you know um well capitalized intermediaries that are able to make that happen today via the routes that we're you know most optimistic about that solve most use cases. So I I do like the idea of having something albeit a bit slower that could handle this um in a more um native way. Yeah, I agree. And um I guess personally at at Polymer we use a native route as a fallback for our faster route. Um so you know if our fast route goes down you can still progress using the slower native row. That's the idea.

Yeah. Just wanted to echo Alan and Ian there. My view is that it's an important part of the broader interrupt menu. Um, so yeah, excited to keep pushing on this and and see where it leads. And Marissa and the AA team at EF have been have been doing a lot of great work here as well. Cool. Uh, yeah. Anything else on this topic? If not, we can move on to the final Cool. All right, I will hand it over to M team on base rollups and interrupt.

Cool. Can you guys see my screen? Yes. Perfect. Great. Um yeah, so that was a pretty technical um just conversation from Ann and I'm really appreciate that. But this is a lot more kind of high level. Um I just want to give my my like summarized vision of how base rollups can fit into the interop story of Ethereum which we've we've been talking about in these calls but also how we can do that in like a more pragmatic way. Um like I'm not going to be talking about narrative here or or value growth or anything like that. I want to focus on kind of a more product mindset.

So the the question I asked myself when I was making this presentation is of what is what is interrupt to me? I think we have uh all of us have kind of our own understandings of it. But the way that I look at it personally is that um kind of as a user occasionally I want to move assets from one app to another that counts as as as interop for me. Uh it's not so much a chain. I guess it is like in practice, but for me, if I have my tokens in one area and I want to use them with another app, it's not because I just had them sitting around. It's because I was using them with another application. So, just the other day, I was moving some tokens from a to base uh because there was more yield on base.

And it wasn't because the instance of a onthereum was worse. Um it just wasn't my preference at the time. And so nothing about the chain was important for me. It was literally just uh the application and what each instance of the application could offer there. Um the other part of interop that I think is perhaps like under represented uh in the in the conversation sometimes um and uh and Joseph from INC had a really great presentation on this at ECC is the idea of like composition um of different actions among protocols. So, we all know this as like being DeFi Legos, but just to expand on this, you can think of lots of different actions you might have. Um,

you could have a swap, a deposit, a withdrawal, whatever. You also just have a token. I think a token can be a representation of maybe like a NLP position. Um, and moving that across a protocol and moving the uh these different representations across protocols with minimal friction, of course, uh is really powerful. So I think this is like to me this is what like interrop being solved would mean is that we can I can move my assets from one app to another and I can move my actions across protocols kind of compose across them. So maybe I I do a leverage long using liquidity for multiple domains. Um and the point of kind of where base

drops come in for me is is doing this with like minimal necessary friction. I think there's a certain amount of uh of kind of lock in that we have for having multiple chains that are not necessarily the same. Um but I see this as a a there's a lot we can do before we run into those barriers. And so that's what I want to talk about for the rest of the presentation. But friction to me means like for developers complexity of maybe doing message hing or um integrating intents. It means like backwards compatibility. So like does a on layer 1 work with my lock and mint protocol? Um so on and so forth and I think that at

the end of the day this ends up trickling up and so we see complexity and friction for developers turning into delays for applications oftening and that that's friction for users. Um, and I think we see personally I think I see a lot of this in wallets where a lot of um, complexity has been handed off to the wallets like MetaMask. Um, and thus we've seen some delays and kind of what I'd like to see from from wallets and kind of the user experience on that side. So yeah, let's like get into it. Um, base rollups I think fit in in like three big ways. Uh and there's a few maybe second order effects that I um I want to keep thinking about.

I kind of think of space rollups at the most basic level as multiplying wherever Ethereum. So if Ethereum has fast slot time, base rollups can can use that export that sequencing that that building pipeline into something more. But if Ethereum has a negative um negative aspects like a extractive builder market um then you have a you multiply that as well. So you're just giving that to more block space. There's there's pros and cons. Um the number one thing that I personally think about is this idea of like a composability zone or an an area maybe a set of chains um that's that are synchronously composable between there's of course there's different levels of this. Maybe you have

crossing contract calls maybe you don't. Um, but from like a most basic level, I think people, especially Jos, use the term like universal synchronous composibility where you have Ethereum layer 1 includes all of the layer twos, all the layer 3, so on so forth. They're all synchronously composable. I don't see this vision as being practical. Uh, because I think there's going to be um differences in in how chains can express their preferences. uh but I do think that there are there are certain places where a like synchronically composable zone uh will make a lot of sense. So for example, if you have a layer 2 and you'd like to have synchronously composable layer 3es, then you've built like a

composable zone on top of these or maybe um we just have a composibility zone that doesn't include the layer 1 but does include a wide set of layer twos. I think there's there's a lot of um possibilities there, but for me a base rollup is a is one way uh to to export the sequencing of maybe a centralized sequencer or maybe a layer one and that gets us potential for these these zones to form. Um again like coordinated by that sequencing aspect. I also think the maybe one of the big ones for me is like reducing friction uh in a couple ways. I think this really starts to come out when you compare to asynchronous interop or uh or interop across chains that are very different. Um

so for developers, the biggest one for me is like if I'm attempting to engage with some some protocol in another chain, that's my goal or get my users tokens from another chain into my app. then there's a few different ways that I could I could attempt to do this with the technology that exists right now. Um, but what probably ends up happening is that it looks like uh strange to me. It looks unknown because I haven't seen uh maybe async programming practices in solidity before. Um, and so this kind of complexity is just friction. And maybe I mean for me it's like if I'm working in Forge and I I'm writing a a smart contract um and I

I'm so used to doing synchronous contract calls because everything's usually on the same chain for you at least these tools are built for that mindset that now we have this like disruption if there's some asynchronicity there. And I'm not saying this is like insurmountable. I just think it's friction. Um, I also think backwards compatibility is like a really underrated part of super um super like interrupt focused teams sometimes because we can develop like a great interop protocol, but I think it's um it's really good to look at like what we actually want interop with and for me personally it's like pretty much the like the big DeFi protocols on layer 1 a uh unis swap and if there's you know

these tokens are these contracts already written a lot of times they're non-opgradable and so maintaining backwards compatibility synchronous asynchronous whatever with those is super important and I think that um basic sequencing again does not guarantee this but has the potential to enable greater backwards compatibility with uh with the the contracts and protocols we know and love um I also think base routs are not like front-end thing in all in many cases like there's there still I hope some form of chain abstraction or um intent based routing on top of this. Uh but I do think of of uh of base sequencing as potentially offering a way to do faster settlement of intense for example. Um maybe if you

have a a base rollup settles to Ethereum, so it's a layer 2 and you have a another layer 2 that's not base, then interacting with the liquidity protocols, tokens, whatever on this base layer 2 could be a lot simpler because you already know what to expect when interacting with Ethereum. Maybe you already have like a solver market built up for that. Um and so you know connecting these dots is is going to be a little bit easier for you again especially if this is like a a base that follows the consensus and finality of Ethereum. Um I also want to link to this this uh page right here where we've written a good bit about this aspire just kind of on the idea of singability and how we imagine um it could be could

be done for a base rollup and then kind of what are some of the effects of that. So what are the trade-offs here? I think this is like everyone's mind kind of jumps to this when they hear the word base rob and so I want to just address some of these real quick. Uh I think the first one from from my perspective like the biggest one is just there's been slow development not only of based robs but also of dependencies like pre-MPS um slow development and slow adoption. Uh ZK has not been necessarily slower than expected but it's still um nominally relatively slow process of getting these things production ready. Um, and then moving on, I think number two here is is maybe the hardest one to solve. The layer one and especially the

block building pipeline just isn't ready for um for for DeFi at a lot of levels. I think that uh kind of democratizing maximal me extraction is a calculated trade-off that you know core devs made but unfortunately has the um has some some second order effects and so we've written more about this in this post here but you can imagine that having a an auction on layer 1 that's designed to extract value can make it difficult to run systems that's that uh are perhaps serving users that are that are expecting not to be front run or to be sandwiched like they are in centralized sequencer layer twos.

And so at Spire, we've been doing a lot of layer three like based layer 3es on centralized sequencer layer 2. That's a lot of benefits that we've written about. Um but essentially I just want to kind of expand the idea of a base roll up to there's more composibility zones than the original concept of like universal Ethereum synchronous composibility. Um and maybe these you know sets join eventually but I for now I imagine that there's like these tighter knit uh areas that maybe don't include the layer one right now just because of again that that extractive sequencing mark costs block times etc.

Um I also want to talk about maybe a less obvious thing which is the complex cost and fee structure. Not necessarily, not trying to say that bas are necessarily more expensive than a centralized sequencer roll up. Um, but designed poorly and especially designed naively, you will run into a lot of complexity issues. So, if you're if you're writing anything that interacts with layer 1, of course, you're going to need some um some way to pass the fees on to the layer 2 actor. Um but if you're if you don't have a single sequencer and like a place to conveniently do this uh it can result in it can result in a mess. So uh I believe in most if not all OPAC

rollups the the layer 2 data fee is passed on to users. Um but it's kind of like taken out of their account instead of a uh a fee that they pay directly. And so the um this just additional complexity is the kind of thing you would see on base rollups. Um I think this is not unsolvable and especially when we start to just reduce uh cost gas fees on layer one with like a higher get gas limit. This becomes like a lot more straightforward. But again like whenever you have like a more distributed decentralized sequencer um or or proposer layer you're going to run into these types of complexity issues. So yeah in summary just want to make a few statements here. I think base robs are one option for interop

non-base shared sequencing. Um but they are unique. I think they have some properties that we yeah we aren't going to get anywhere else and we aren't going to be in production. Um they also offer kind of like a moonshot I think like I I wouldn't put it as like a plan A for Ethereum wide interop u but more of like a if this works with things like maybe a native roll up um becomes a part of this then we have a uh we have a a way that could be way better than what we expected before could get it a lot closer to like the execution sharding road map that um has been talking about for a And then I also think that we're going

to see a lot more like isolated experiments like again like based layer 3s on layer twos that can show early value. So I think we'll get to see like the solidity flow of doing a crosschain contract call before it's uh interacting with a layer 1. And so I'm personally really excited about that. That's one of the things we're building aspire that should be coming soon. And then I also think that I said this a couple times. I think base ops are a are a part of a larger picture of interop. They're not the whole story by any means. And really the only thing they get to is this like coordinated sequencing layer like shared sequencing did the same thing. Um and that's enough for starting to work on like an interop protocol on top of that. Um but you

still you still need the interop protocol. You still need all of the infrastructure that we've been talking about in these calls. So you know chain abstraction intense are both things that I would find very valuable for a world that even if everything is based um there is a potential world where a base and native rollup ends up becoming essentially an execution shard of the layer 1 execution zone and we see these kind of like co-processor um EVM environments uh being like the the simple elegant way of um of doing a roll up and I think that's again that's a potential future but that would involve like a pretty major disruption in existing layer 2 and not something

that I'm personally uh personally betting on right now. That's it. Any questions? So Matthew, I think you know this concern of mine, but I wanted still to double down on what your vision is for the long-term world in terms of the number of synchronous composibility zones like would you be like in the Justin Dre camp of saying hey we can aim to have this like academically pleasing single composability zone want to rule them all.

Um, I think it's it's kind of an idealistic perspective, uh, but still one worth like attempting. I mean, that the the big reason to consider Ethereum for like a big priority for your composibility zone is of the network effect that Ethereum has. Um but again we talked about some practical things that make that difficult and I think we will end up seeing you know whether I like it or not we'll we'll start seeing composibility zones like synability zones that don't include Ethereum at first. Um so eventually yeah I'd love to do that. I think that's always going to be a part of our mission at Spire. Um but of course there's practicality things we have to think about. I

I do think that there's a it's kind of like a hub and spoke model that we can imagine here where maybe there's a few large layer 2s that have async interop with a layer 1 but have their own composibility zones with layer 3es on top. Um I think something like base could be you know with our base apps vision could be something like a early prototype of that. Um, but I'm not sure again how this like evolves in in five to 10 year timelines. Great question. I'm worried this is a bullish a bearish take because it means we can't hope to have a million times more transactions.

Right? If we keep this assumption of having a single entity to sequence the entirety of the execution zone like this will be the bottleneck. So like this only works like we will have this ceiling somewhere which is why yeah I think it's a bit uh of a limited view maybe. Do you mean for just like a like a base row up on a layer two kind of being constrained by the layer 1's resources? Well, it doesn't matter. A world where a single entity has the ultimate power over how transactions are sequenced which is a fundamental precondition to

having shared sequencing or base sequencing in particular. Right? So like it feels like from first principles we don't really like my gut feeling is we don't want to build towards a world where we only have a single execution zone. Um I again I think it's kind of a misconception that for a for a base world to exist you need all um sequencing rights and all the bright locks to be given to the same entity for for a slot. Um I wrote this article called base ops can scale actually that that addresses like this exact question

from um from Christopher goes and I think that the maybe the biggest thing here is like understanding that a base is not not guaranteeing that the in the context of Ethereum it's not guaranteeing that the layer one proposer their layer 1 builder has a right lock and is actually sequencing transactions and doing the heavy lifting there but rather that they have coordination with whoever is doing that. And so uh and you know there's another part of this which is like the consensus and finality side but the point is that the the level of coordination that you need is not absolute. So it doesn't have to be you give over your entire block and I think it's it's maybe quite dangerous to imagine a world where we have like a super builder that builds everything. Uh

and I'd be I'd be quite against that. Um but again I think perhaps we see a more distributed model. Uh but again it's hard to know. I think at first probably see there being enough uh enough room in like a centralized sequencer to um to juice more out of it for other chains. At Spire we have a model that can do base sequencing but doesn't uh constrain the layer 2 sequencer at all. That'll be that'll be uh coming out soon. Um, and so I think that yeah, it's kind of like a I mean you're correct that like if if we want a full synchronizability then we need the right lock to be down to one entity. It's just like the same chain at that point. That doesn't mean that the

you can't do anything without that that being set up. That would definition of what based base rollup means, right? Yes. So this is a This is a longer topic. I I don't think that the original definition of um of base from Justin is complete and so I've been at to define it in Spire's docs. I'll just put the link here. Um it has kind of an expansion of the idea. I yeah, there's a few reasons why, but that's the the big one is like the the way that um rec designs have evolved makes even from

Justin have changed like what a what a base rob must mean. So there's kind of some self-conlicting things. Um, that's yeah, I tried to lock it down a little bit more in that article, but I think yeah, you're right that going by that original definition, at least some interpretations of it, you'd have to have the way described earlier with like a full look. So, one thing I'm interested in uh asking Matthew about is the demo that Spire showed about uh uh reading the base uh the base layers uh data or O or

Oracle data on the L3 or uh or on the L2 whatever on the rollup side. Um so what is your current approach from uh to to to do so? Are you like u implementing L1 uh L1 call or L1 uh s load or something like that or what's your current approach? Yeah, good question. Um we'll have a lot more talks about this soon. We have some some stuff that's like just in the review phase. Um and so I can definitely share those when that's out. But for now, like I think it's easiest to understand the uh the architecture as as collapsing all layer three transactions into a single layer 3 block

and then putting that on into a layer 2 transaction. Um and then each layer 2 transaction, it just becomes about a layer 2 block, I should say. Uh and so if you were to expand all of this, you'd have a super block that includes like layer 2 and layer three transactions. Then what we do is we simulate that super block from like top to bottom and every point that crushing call uh is being made and we have some like at least the interface for expressing that um then the we just pretend that it's possible. So we say if you're making a crosschain call let's just implement it um on the uh let's let's run it against the the other chain state I should say.

So we have like a crushing simulator that can handle this. Then once we're done that, we have this like we know all of the all the borders, all the the the places that we're making crushing calls. So we know what to expect from the results and we put those on chain um into the layer 2 with what we call priming transactions, the kind of preload state. And so in the in the model that you mentioned before of doing a um doing a a layer 3 reading from the layer 2, we'd have a special priming transaction. It's like a system transaction for the layer 3 that would load the state of like the expected result from that call um into the layer 3 and then the uh the actual layer 3 transaction when it when it's executed

could just read that state and then we're during the settlement on the layer 2 which happens frequently because it's a base drop we're verifying the that the call was actually correct. So if you're making a oracle read you're going to have to check that the oracle actually reads what you told the layer 3 it would read. Um, so there's some level of prediction here and then we have some alternate models for that eventually. Um, it's not just reading your question from the chat. It's not the same as what goodness is doing. There's no new pre-ompile and we don't change the state transition at all.

We're just using um some some tricks with the like proxying and aliases. Um, but it's not uh it's not dissimilar either. It has some of the some of the same characteristics for sure. Thanks. Anyone else? Any questions for M team?

Thanks for sharing the presentation. Yeah, my quick two cents for what it's worth. Not a particularly, I guess, insightful comment, but yeah, to me, base rollups are a no-brainer in terms of exploration, iteration. I think they've already delivered value on that front and pushed our thinking forward in many ways. Yourself, Tao team, am Netherm team, many others working on this. I think it's already had a yeah, net positive outputs. um like you said, you know, whether we call it a moonshot or something else, there's many things to still figure out around this. And then where does this fit in? It's a, you know, maybe a bit of a more medium to long-term effort. But yeah, I uh despite some of my questions or concerns, I'm I

support and it's it's been great to see Yeah. you and others pushing this forward. Thank you. Yeah, I mean, I really appreciate that. I think there's a there's there's like a maybe a notable thing about base ops that there's uh other than tao there's not a lot of large layer twos or like established layer 2s that are um directly pursuing this model in the short term and so I think um and you know we had our I think sequencing call 17 where a bunch of big teams committed to eventually exploring this um but I think the the general consensus has been let's kind of wait and see how the layer 1 dependencies evolve.

um and kind of if we can do some further research here which I think is is is definitely a pragmatic approach. Yeah, makes sense. Cool. Well, we only have a couple minutes left. Any other quick questions, feedback, anything else for the group? If not, we can end things there. Cool. Thanks everybody for joining and we'll see you next time.

Thanks Josh. Thank you. Bye guys. Thank you. See you. Bye.