[English][Pop-x HK] Embedded Rollups: A New Paradigm for Cross L2 State Sharing

Transcript

Hello guys. So, next talk is from Lyn. Uh it's Lynn from Okay. Um hello everyone. Um yeah, I guess everyone's pretty tired and it's going to be slightly more technical than probably the other talks. So, but I'll try my best to yeah and feel free to ask any questions anytime. So yeah today I'm going to talk about embedded bullets a new par paradigm for cross stage thei from mind research and this is going with corner also from mind

research okay before talking about embedded rollups let's talk about rollups what are rollups before that like what did we have before we had roles what we had is that we had like users they will submit their transaction to the L1 and the L1 will like upgrade the state and that's it. Very very simple lines and like the L1 is great like you get synchronous composibility like out of the box. So if you think of the those seeds those are all smart contracts they can all call into each other they can read into each other they can write and all like within a single call seamlessly.

However, like upgrading L1 state is expensive. So like this upgrading the L1 state part based on the sub transaction this part is very expensive and expensive because like every single validator in this network they have to do this like update of the state. So every single valuator like even the valators in like top Africa they all have to like do this exact same computation so it doesn't scale okay so like due to this limitation like rollups were given so what rollups do is that they introduce a separate

L2C so like in the And then what happens is that like sequencers or in some cases users you can submit the transactions to the L1 to what's called an inbox contract. This is where you store like you submit your L2 transactions to and then the L2 can like read the transaction from the inbox contract and then the execution happens in the L2 side. So what's happening here is that transaction data is posted to the L1 but not executed in L1. It's only executed in the L2. And this is where the scalability comes from. And another way to see this is

that rollups are like constructions where like you derive their state from the L1. So just by reading the L1 all the data in L1, you can actually derive the L2 state. So what this is exactly what leads up a roll up and rollups are nice. They give us they give us horizontal scaling. Why? Because like here you have ro A and have ro B. Both of them have different inboxes in L1. And the sequencers can post matches to ro A inbox B inbox. Ro A will execute these transactions. Ro B will execute these transaction. The critical thing here is that roll up a roll up B that

independent state. So they're independent. So like you can have like hundreds of rollup each of them doing their own execution but they're doing their independent execution. So it can run in parallel. Okay. So ropes are nice. They can scale. But there's one problem and one the big problem here is that they cannot read or write to each other. So like in A have a smart contract in that smart contract you can't call into or read or write to the smart contract in roll up B. In other words, like there's no shared state in the L2. Like they're

just completely independent state. And this is what's called a fragmentation because like before you had the L1, everyone was compos everything was composable. You can call into rewrite whatever smart contract you wanted to. But once it's in the L2, you have this like boundary between them and this leads to fragmentation. And well like although in L2 you don't have shared stage if you see like actually in L1 you do have shared state because like remember all the L2s the rollups you derive the state from L1 by default they all read the L1. What we can do is you can have like the smart contract on the L1 and this

can act as a shar state between A and R E what they're like reading the inbox contract. They can also read the smart contract and the smart contract can act like basically a read only shared state between the rers. So you can get shared state but however the problem is that L1 is expensive to update. So whenever you want to like overay this like shared view of this smart contract you have to submit an L1 transaction when L1 execution and that's very expensive.

Okay, so we got so far like rollups scale blocking and roll can share stage via one but it's expensive to upgrade and now the big question here is how can we enable share stage cheaply and here is where embedded So what are embedded roll-ups or ERS? So embedded roll-ups are rollups that are embedded within and shared among other rollups. And when embedding an ER, the rollup stores and updates a local view of the ER state alongside it

own. And if multiple rollups embed the same ER, they can share this read only state without relying on one execution. I think this is all very like complex. So I'll show some graphs. Yes. Right. Okay. So case rollups is about um well like an embedded rollup can be a case rollup. So embedded like base rollup is about sequencing like who actually does this work like who are the sequences. This is like the core question of these follow-ups and embeddings um like as I'll explain it's more about how you compose these together with each other. So they can

compose like base follow-ups you can compose like on base follow-ups. So it's like a separate layer of any other questions. Okay. So yes, what are embedded roles? And here like you have ro A and let's say you have ER an embedded role. But so far it's just two independent roles, right? Like you have a inbox and er inbox. Well, A reads from the inbox. The ER rollup reads from the ER inbox. Okay. So let's say that rollup A wants to embed ER.

So what does this mean to embed? So what happens here is that when roll of a invest er it like yields a separate roll a bracket er and this means that a embeds er and what happens internally is that like a will embed the state of er within it like local state. So within the state of AR that you have this whole state of ER embedded within it in other words it maintains a local view of ER. Now what happens is that okay like

let's see how role A er will execute. So first what happens is that the ER state like this local view of ER the world a ER's execution will first like read the ER transactions from the ER inbox. So again like rollups they are construction where like they derive the execution from the L1. So like they have full access over not only a inbox but also ER inbox. So they can like first read from the ER in box updates a local view of the ER by executing all the like red ER transactions and then it can proceed to read the A's transactions from the A box

and update the AER state. Now what's possible here is that actually like from the state of AER you can read directly into the state of ER. So contracts in ER can directly read state of ER and this is like exactly the same as like reading any other smart contract in like this part of the state. It's completely seamless and completely synchronous.

Okay. And now like that was for a and actually you can do the exact same thing for another ruler r. So what happens here is you have a ber and you can do the exact same thing like the er can read from the bots update this local view and read from the bots update this like all view and now what's like possible now is that now like because role A and role B they both embed the same ER roll. What's possible now is that ER can act as a

read only shared state between A and B. So both AER and BR they reach from the exact same er box here. And so all the inputs to the like local view is completely the same which mean that [Applause] the ER execution is because the ER is execution deterministic and the inputs are the same. It yields exactly the same like local view of the ER. So now when role A reads from ER and role B reads from ER they read the exact same state. So now what you got is like read only shares

state and you get read only share state without involving one execution. Okay. Uh any questions about like what do you think is the like the pros and cons of like embedded roll up? like what's the trade-off I guess between like an embedded rollup and like yeah reading it that way versus like having like an op roll up basically like compressed dependency instead of like

another roll which sounds a bit like would be the embedded role. Yes. So like in my view I think like the difference is like I would say the sovereignty of the whole system because like if you have like op style like dependencies like how this works is like you have to settle well my understanding how this works is you have to like you have a dependency against settlement of both of the chains. So like when you settle like you see that I'm settling under the condition that has this state visible and like now what you have is that you have like this dependency graph in the settlement like my settlement will fail if this other team doesn't settle in this way then like that can fail you know got a huge difference is that

instead of you actually like making the settlement of the like depend the parent roll up. You just have the child roll up just like uh I guess have it own transition fun so to speak over like I roll up transactions and somebody else can have a totally different function over that very same transaction. Yes. Gotcha. But if they if two different rollups that use embedded roll have different ways of uh deriving the same transition at the state from function would they not have the same view of the state? Yes. So that is possible and um but the thing is that even if another ruler like has a different view of the

shared state doesn't affect you and it's it's kind of therefore right like you have like you should have a shared state to this function and someone like deviates from it then like their view might be broken but for me I'm okay. So like this you have you can you do keep this independence between and maybe in some cases that you do want to keep but yeah uh questions. Okay. So yes, so like how is this useful? And the first use case, the very most simple use case I would say is like

a key value store. And what the key value store is, it's basically like a mapping from a key to a value. And how this works is that you have a KPS in the middle. This is the B that's going to be embedded. And then you can have A and R B both embed the same KBS. And whenever the user wants to upgrade this like view of the KTS, what they do is they can like write a key value pair to the KBS inbox and the KDS inbox will be by both of A and B of B and both of them will share the same view of the value store. Now in what cases is this like useful?

It's yeah one example would be ENS. So like in the ENS case it's going to be like the mapping from the ENS domain to the address for example or maybe yeah so like the mapping the keys do and the nice thing here is that like if you do one write to the KBS impulse all the roles that are embedded this K like KBS ro they will have exactly same you can do like a single right and like propagate to all another good example would be key store key stores. So key stores are like basically like for smart contract accounts and you want to map your smart contract account to like a set of keys

for example and this too like you would want access to this to all the rollups in within all the rollups and you don't want to do like rights to each of the rollups. So if you do a single right keys class you can like probably do all the rollups. Okay. Um and the next more complex but interesting use case would be a shared bridge. Okay. So like at the high level we can implement a shared bridge rollup to track tok balances across rollups and this rollups enables first the slow L2 to L2 transfer without requiring C1

instructions. Additionally, it supports fast and efficient solver transfers by concentrating solver liquidity within a single shared bridge layer. And note that liquidity fragmentation of solvers is like a huge pain point of any software based solution like um and example like if you have a 100 bulbs if you want to like put EB solution like you need to have all the 100 like pair wise solvers in like each of the pairs and even for like the very low liquidity like not very used like go up.

And the solvers have to be have like wood in each of the bullets. So they can't have shared okay so and how the shared bridge would work on an embedded bullet setting is this. So first like let's think about deposits. So deposits are like kind of simple like you have a user let's say he wants to deposit into roll. So instead of like depositing into like a ro specific bridge they go to a shared bridge and deposit attendees and say that hey this is in need to go to A. Now what happens is that this the shared bridge roll up it will read from shared bridge inbox and say that hey

like a is has like 10 e added to their like balance basically and then in roll up a it can have like a local bridge contract that reads from the steering bridge and that image then ease to the user. Okay, now that's how deposits work and let's see how transfer. Now suppose that user A in role A SB wants to send three E to user B in ro SB. Okay, how this would happen is that

okay there's going to be like two paths and the slow path and the fast path. And first let me like explain the scope. So what would happen here is that the user will send like three east to the bridge their local bridge in here and then eventually this will overload ASB. it will settle to the one and when they settle like you can have the shared bridge or you can push the stage route of ASB to the shared bridge. Now when the shared bridge reads from the like shared bridging box it can read in the state of the whole row of A

and based on this it can know that hey there was like a three to the bridge and that's intended to go to B. So we can like do the counting say that hey a minus 3 b + 3 and then the local bridge can like read from this shared bridge and emit the threes to the user. Now at this point it's already pretty nice because it can transfer from a sb to espal execution. So no e transfer into one. This is the nice thing about like bridge.

Yes. So the second uh this it will be done by uh the proofer of L. So this is like in same as in any traditional like rule and in like for example it's like optimism the optimism foundation actually does they post one but if you can have like other constructions where like anyone can post or yeah like yes so yes like in any any rollup like

you have first you submit the transactions you execute L2 then you settle down to one and you post like one someone has to post it but like who post it it's different maybe like construction say okay so like step four is like so when you have r a b and you have send three e to the shared bridge and then you settle this whole state to like l1 that will in for within that statement it will contain the information of the bridge right like and the fact that there's this pending transfer in the

shared bridge the non non-shared bridge contract and then and then like if you push this to the shared like inbox and have it read by the shared bridge contract the shared bridge roll up what would happen is you can like import this state into the shared bridge through little one because like every everything in middle one is basically shared state. So now like once you have the state root of a you know the fact from the state root that like this thing happened. So from the fact you can update this like shared bridge table and say that hey like a is bridging out to

be 3D. So like I can upgrade this table. So like the the A entry is kind of the like the bridge contract balance on the shared bridge. Yes. Got it. Yes. This is just like a random idea, but couldn't you just have user A submit transaction on the shared bridge roll up? Um basically similar like basically submit both on roll up A and shared A.

So that's actually a great point and that's actually where we're heading towards. So yes yes yes that's exactly exactly. So there is a shortcut that you can do um any other questions. Okay. So yeah like the implementation is also an interesting question like I think your question is like how do you actually embed this SP sync right and um there's multiple ways but I think the most simple way would be that like in bullet a is let's say there's an EVM so EVM you have contracts and you can have

like a special contract within that EVM execution allocated to the shared bridge so you can see that this special contract it's like from my rollups view it's read I cannot like write to it and how that shared like contract state progresses. It's based off solely on the inputs from here. So now you can have like minimal modifications to the EVM itself for ro A. you just have like a special contract allocated where like the input is restricted like inputs from here and you can't like provide inputs from the rope itself and then that way like you can just have like a read only contract in your state that's embedded without like much modification with execution

about the server distri Yes. Yes. Yeah. Exactly. So the thing is that like they already have that like infrastructure of listening to the one because they already have to listen to the a box, right? So they already have like an open execution that's running loc they and instead of just listening to the events in their own inbox, they also listen to the events of the other like embedded in. And that's not much added infrastructure. It's just like you're already running one.

can be scaled to. Yes, exactly. You can like scan anything you want. And this is like a pretty interesting thing about rollups that I think are kind of underexplored because like all roles they have full access to the whole one and they can be whatever from the one if they want to and yeah like for example like typo's bin project they project and those are like trying to utilize this to the max they're going to explore you okay thank you go ahead so low A need and then roll up B need each other. Uh the role so the thing is like roll up a and roll up b

they don't have to necessarily close to each other because like a kind of relies on the execution of b relies on the execution as b but a does not depend on b and b does not depend on a and this is kind of another like actually difference between the super chain vision where like you have directly the super gene or airplane those designs you have to have a directly depend on the execution of b and b depend on the execution of a tight but Here you have this like everyone depends on the shared bridge but A doesn't directly depend on B and B goes like completely broken like fault or like have some proof like A is indirectly affected because like everyone's just like depending on the SP part of this whole thing.

Yes. Yes. Yes. Exactly. Yes. Yes. So yes, you do have a dependency on the SD part and I think that's why like I think SP would be a good candidate to be based because like you don't want to have like this dependencies on some how you calculate the gas for the set no trans um actually I'm not sure like it is expensive like but you can like for example if you have a 100 transactions out from the 80 you can like batch it and like have a single transaction in one that will give you some saving but I'm not sure how that like the rob A and B they give the same

shared bridge so they know each other. Yeah. Yes. Yes. So both of them are making the exact same share bridge. Yes. So actually their data is uh actually they shared by the share bridge right? Yes. Yes. Like share bridge is where you put the shared database. Okay. Okay. So moving on. Um okay. So this is the slow path and what would be the fast path. And here's where those solvers come in like and because like one observation here is that as soon as user A sends three ease to the

bridge like now like eventually what's going to happen is through the pass is like the transfer is going to happen but that's like eventually so what you can have like to make that faster is you can have a solver. So solver can live inside the shared bridge layer. So like here they have their own account and they have the ability to like transfer tokens from their account to another role. Now what this solver does is that they will like observe the send three e transfer from user A to the bridge. they will observe it and then they will like immediately update the shared bridge layer and this solver can like so enable like fast transfer basically like saying

that hey instead of waiting for A to send to B I'm just going to like send to B through my own account and then the ro B can like directly reach from the share bridge and give it the three E without waiting for the east settlement Okay. And um this I'm going to kind of omit in this presentation but for your information like so can also condition their solutions on the observation. So they can see that hey send three this transaction happened in this world. I'm going to only emit my update if this actually happens. And what you mean by

this exact actually happens is that you can condition it on the batch sub. So not the proof but yeah this kind of a mix here but interesting optimization. Okay. And now now you have the fast path running and then what happens later is that like you refund the solver so path. So eventually like well a will settle to the one and you can do the exact same thing that the soul path like the sher can be the state root of a and a but here like you'll know that solver like have fronted the capital before.

So they can just say that hey instead of like u sending the minus3 to b because b already received it through the solver I'll just send it to like the solver and you can add some tips here from user. Okay. And now the nice thing about this construction is that all solver liquidity liquidity can be in the stable. So no fragmentation of the solver. So as long as you as a solver like if you have all your in this SP roll up no matter how many rollups are embedded you like SP roll up you can just stay in SP and like do the transfer

like locally. So you don't have to like reach out or like have assets in B or A or C or B. You can just keep it all in SP and like do all the asset transfer like within SP itself. Okay. So conclusion uh is embedded rollups enable read only shared seat between rollups read only shared stage can be used for shared TVs shared bridge etc and in general like diver state from one so interesting things may be possible by playing around with this derivation.

Okay, thank you.