Protocol Berg v2: Alejandro Ranchal-Pedrosa - Rebased Rollups

Okay. Hello everyone. The the the one the few of you that are here. Very proud of you. Maybe you're not aware Vitalic is in some room nearby or the room is full or something, but that's great.

And I won't do it just for the video then. Um so yeah, I'm going to be talking about rebase rollups. Let me explain that. Explain that. Let me get there with an example and go over um some other solutions that we can find before we get to rebase rollups.

And so in this example, we have Alice and Bob. Um Bob is throwing a party in Bikini Bottom in the city where Spongebob lives. And um Alice, who's from Wonderland, like some smart contract or app or whatever. Bikini Bottom is another app. Uh, so in Wonderland she had she got like an NFT at some point where she got like some free passes to attend some events and Spongebob accepts the passes.

Okay. Uh, but there's one caveat. Bob's party has limited capacity, right? So Alex has to be quick in uh, you know making a transaction to get access to the party. And so how can we do this, right?

So if we do this on L1 then the let me actually go back. So the properties that we want is something that is fast. So Alice wants to Alice and Bob want to communicate fast to do this in a safe way. Obviously they don't want to Alice doesn't want to think that she can go to the party and then show up. And apparently Bob is not aware that Alice is allowed a cheap in a cheap way.

No refunds, right? If Alice spends it, she wants to just do everything at once. if she spends it because there's capacity otherwise she doesn't want to spend her ticket her um incredibly neutral way. So now today is Bob's party but tomorrow will be some other party and it needs to work for NFTs. So the the choice of the example is not deliberate just for one of the solutions that there is.

Um, and so yeah, if we do this just on L1, you know, if all both apps are Ethereum, then great, things are safe, no refunds, you know, we have synchronous composibility. Um, it's credibly neutral, right? We're using Ethereum where all the apps are, and it works with NFTs, but fast, you know, I mean, in this example, it might be fine to wait for uh zero confirmations or like 12 seconds to 12 minutes more or less. Um, but in many examples, it won't be right. you want much faster finality or want much faster uh access to the party and it's definitely not cheap, right?

So that's why rollups came out, right? So imagine now bikini bottom up and wonderland app are both in scroll. So great, now you get pretty much almost all of it with like some cavits on save that is not the purpose of this presentation. Um but the problem is this works now because Wonderland and Bikini Bottom are in scroll but this is not a given, right? Why scroll?

Why not optimism for example? And now we don't we cannot just solve this this way. You could say okay well op can still communicate through L1. Fine. But we go back to the same problem before when we were using L1.

It's not fast. It's not cheap. And actually now you have to deal with partial state transitions. So it might happen that Alice says, "Oh, I want to spend my ticket to get a my pass to get a ticket for Bob's party." And so she kind of like partially spends it, notifies Bob, but then by the time that happens, Bob comes back and says, "Hey, actually I don't have capacity anymore and she needs to get back her pass, which didn't happen before."

And she has spent already some money to like lock her pass. Something else OP scroll can do to facilitate this to just say, "Hey, let's just, you know, let's just not wait for a one, you know, I'm just going to read your state and kind of like believe it and just integrate it on my state." But that changes the uh safety assumptions of both rollups because now they need to basically if a scroll starts doing things based on what scroll sees OP is doing and then op breaks now scroll might not be able to settle anymore and it might need to also revert some of the state that it assumed final from optimism before it was actually final on so you lose the safety bit and I mean it doesn't even make sense to mention the refund bit because there's no safety. Um, something else they can do is they can say, "Hey, let's just choose someone and that we're both going to like give up some of our um, autonomy in the just for the benefit of having faster interrupts and like common safety assumptions, you know, that scale well. Um, and an example could be espresso um, as a common hub to do interrupts."

And we go back to a little bit of what was happening when things were at scroll only. You get a lot of the benefits, but now you still have the problem of what if you know this might work with op scroll, but now you have a third party on an app that is running on arbitum and arbitum is not part of espresso and now we're back to the same issue, right? Why why espresso and why not some other solution like op super chain or something like that. Now the third thing and this is why I put the NFTs is you can just use some third party like liquidity provider and this works when things are funible obviously but in this case where we have an NFT being used they cannot just mint it on the destination chain. So you will and also I mean the safe assumptions are kind of different and of course you lose credible neutrality again.

So you apart from doing some things the most important one of the third party liquidity providers is it wouldn't work for general state it only works for funible um tokens and uh now it's getting closer to what I want to present um but I mean part big part of this presentation is to like put differences of like the different solutions for this kind of problem. So base rollups was what has been proposed to address some of the issues of credible neutrality for these interrupts between chains and basically the idea is to share the sequencer with the L1 proposer uh which probably not sure if all of you have realized of this but it's actually not needed to share the sequencer with the L1 proposer for this particular um problem. Um but definitely is if we if we all share the sequencing with the one proposer, it does solve the problem. Um but the problem is you still with if you if this is just base rollups without precoms, right? I'm going to get into that in a minute.

But if you're just doing base rollups, then you're following this uh latency of L1. So you're again not really that fast. and uh it creates some weird incentives in the rollups that they need to be uh committing quite regularly that also affects how cheap a roller can be. Um in order to kind of solve these issues, precoms have been proposed and so precoms is basically instead of waiting for the regular path to finality that the one follows, let's just ask the next proposer to kind of like promise like a pinky promise with some stake that the one proposer has that he will propose include or like that the execution will result in some result after executing a particular transaction that we're interested in before he has even proposed the the block and if he doesn't honor that then he gets slashed some amount. So that now gives you back the low latency requirement.

Now you're fast. You can be like as fast as the sequencer can provide the pre-MP which is basically like in the order of hundreds of milliseconds. Um we still have some of the issues with dealing with L1 that are definitely more expensive than just dealing with L2s or like let's say non-base rollups. And in terms of safety, you cannot abuse too much these precoms. Um and let me explain that with the economic with the problem of uh how economic security is scaled from where you when we are all using precom uh which I think is is quite important uh point of this presentation.

Um let's explain that in a minute. So okay so now here we have Ethereum and this is an example where nobody's based right we have wonderland that's running on some rollup it own rollup and then bikini bottom and a different rollup and then we have Ethereum with like a rotating sequencer right a rotating proposers uh but in the case of wonderland and Spongebob we have the same sequencer all the time so if we want an amount of economic security equal to whatever this vault is imagine this vault is 10 E right each of these vault and then we have four users with 10 E and one of them is a bit more he has like 30 E. Um so if we need one ETH all of them can be proposal right they have enough economic security to propose to sequence if we put them together and now there's one proposer proposing for the three in order for each of the of the uh state partitions for the L1 and for Wonderland and for Spongebob to get each 10 E of economic security. Now only the rich one can be a proposer because we need the economic security to divide by the by the number of by the number of uh different rollups that this proposer is sequencing otherwise basically the economic security dilutes over how many rollups the sequencer is sequencer at once. Um so there's some interest in not sharing the sequencer together all the time and not being based all the time.

So the question is can we just not be based on demand and the answer is yes. Oh yeah as I was saying there's like something called gateways that kind of like tries to solve this problem for L1 which is basically kind of like proposers can um sell block space to others to actually propose. So it basically brings more centralization to L1 proposing uh dynamics and and in a way based rollups with precons with gateways kind of like touch what I'm calling rebased rollups from the perspective of being based first whereas based rollups are the perspective of being non-based first but I'll get back to that in a minute. Um and this is this is one so yeah so this these gateways kind of like bring that problem to like a halt. So eventually you could even have something like uh just a bunch of gateways that are constantly buying block space but they can provide the economic security needed for this kind of like situation where there's one proposer proposing for many one sequencer share sequencer for many rollups but there's one thing that you lose if you become based even with gateways which is out of protocol incentives.

So gateways um so if a scroll for example becomes based a scroll is running its own sequencer at the moment. So there's a lot of auto protocol incentives like the company you know loses a lot of reputation if the sequencer misbehaves and we're running the sequencer. So it's not just about the stake that gets slashed it's about the reputation that's lost and how the company like recovers from something like that. Whereas if you're based this gateway has no out of protocol incentives involved in the companies that sequencing for you know so if it can like do something bad and get slashed some amount the only thing that it really loses is that slashed amount it doesn't lose any reputation involved kind of like out of protocol incentives but anyway as I was saying so there's like some reasons not to want to be based all the time and so the question is can we just not be based all the time can we just be based on demand and uh this is actually something that was proposed by uh scroll first publicly and uh so basically the idea is exactly that like whenever a rollup that is not based that has his own sequencer that is the one who decides what to do uh decides to be based basically kind of saying oh the next block will be built by the L1 proposer but just this is still a bit un underdefined in the sense that um if the rollup is if the block time of the rollup is one second. So if there's a block every one second and then you become base for one period in in L1 there's a block every 12 seconds.

So how do you deal with that right in a in a way that is safe? Um but at least you'd solve the problem of economic security only when there's demand only when it's needed and the rest of the time we all go our own way. And so we're now getting closer with this adoc based rollups. Um, now the problem is bad UX, right? Users are expecting a block every second and every once in a while they get a block every 12 seconds.

And so this is exactly what I'm trying to solve with uh rebase rollups. So rebase roll-ups are basically a very similar idea to it's kind of like a one step further than adult based roll-ups. It's basically less become base for the next block. But maybe we don't need to wait for the actual proposal. Maybe we can use some uristics to integrate that state in a way that it should be fine most of the time and in the bad cases we need to rebase onto some other block but there's economic security involved.

Um and so let's look closer at what happens in this case. So in this example we're seeing like two rollups that for the purpose of the presentation to make it easier to show they have a block time of 3 seconds let's say. So for for every block you know one there's three blocks. Oh it should be four seconds. Anyways, there's like three to four blocks or whatever.

There's many more blocks on on these roll-ups. And then there's at some point there's this transaction that comes in both me pools that requires this share sequencing. And so both rollups coordinate and say, "Hey, in our next block, we're just going to notify the other one proposer for him to build just the next block." And um and then he get they get it back immediately and they start building on it. But let's zoom in into what happens here.

So suppose at time t the next ethereum slot is going to start. So imagine they have direct communication with this uh L1 proposer through some RPC endpoint or whatever and uh 200 millconds before the beginning of the slot they directly tell the L1 proposer you are going to build the next block for us. Um and so at the time of the beginning of the slot the one proposer has enough information to start building on it. He builds it as soon as he can and which you can imagine is as fast let's say more or less as the se as each of the sequencers when they're running autonomously nonbase and then as soon as he builds at least the top of the block I'm assuming he put he puts this um share sequencing bit at the top of the block he immediately notifies the sequencers of each of the rollups and then the sequencers can build the next block on top of it optimistically of course so imagine I set the block time in this rollup is 3 seconds. So 3 seconds at the beginning of the slot.

No UX disruption like users get the usual block time of 3 seconds. But the pre the that block in the middle with a bit of a less bright color has been built actually by the one proposer and it does share sequence. Now um what happens is the more you build on this blog without it being confirmed the more you are optimistically building in a way that it you might have to rebase because the one proposer might in the end not propose that and now you have to like revert all that state but then you realize as more time passes and I rely more on it I can also keep tracking what's going on on one I can see what's being propagated over the network I can see if there's anything uh if if the things that I'm expecting to see are happening and the more I rely on it, the also the more confidence I have that this is actually what's going to be part of the final chain and then 200 millconds uh before the beginning of the next lot we go back to the same thing. Is there demand for beam based? Let's do it again.

Is there not we don't be comin base and um 3 seconds is an example you know it could be even smaller block time probably if you start wanting much smaller block time then you need this to rely on precoms and the economic security that is lashable on a on an L1 proposer but I argue that it's much more fine to rely on very big gateways in this case because it won't happen like always it will only happen when there's demand so it doesn't need to be every slot that you have a massive gateway um with a lot of slashable stake uh basically promising these precoms but for 3 seconds actually you might not even need precoms. You just can track uh how quickly the block is propagated over the network like in L1 and here we have um this light and at the bottom you can see the source for it from the previous DevCon. Um and uh yeah, you can see that after 4 seconds most like blocks propagating in the first four seconds of a slot with a with a big m uh degree of confidence will actually make it as part of the uh like everybody will see them and it will be part of the L1 chain. And so in this case we finally have what we want. We have a fast protocol that is say that cheap or put differently that people only pay for what they need.

So they they may have to pay a bit more for synchronous composability when there's demand for it, but if there's not the rest of the time they're still having the cheap UX and the cheap transactions that they expect. Um they can achieve synchronous composibility. There's no need for refunds. Like if Alice spends her ticket is because she gets her pass is because she gets a ticket at the party. It's credibly neutral because it's synchronous composibility with L1.

Um it works for NFTs. we don't have to rely on any liquidity provider and you have a UX that is a standardized and it doesn't change when you become based or not and uh so yeah that's that was most of the presentation as conclusion so I already explained yeah rebased rollups explore this trade-off between not being based and synchronous composability this trade-off of non-based rollouts being cheap and fast and synchronous composability allowing some applications in incredibly neutral way that independent roll-ups don't allow I believe. So there's this argument that that has been lingering in the community that rollups are like you know the Ethereum protocol is like proposing this native these base rollups and it's getting hard like if in a future where that is happening non-based rollups lose a bit of their uh selling strategy but I argue there will always be a space for faster than Ethereum latency for block time for example because Ethereum just has to deal with an amount of decentralization and safety but there will be space to exploit this trade-off of you know and always provide faster block time at perhaps a bit less safety and at a bit less decentralization and like you know play with it a bit more uh when you are exploiting this rollup space so I think something like rebase rollups whatever changes happen on Ethereum will always be there um and and yeah so yeah I think I already said all these things um so yeah Now you don't need to choose between fast cheap non-based rollups or a slow expensive synchronous composibility. You can just have both any question. Uh thank you Alejandro.

And uh again in the top right corner there's a QR code if you want to ask questions. Uh there are some questions already. Uh first question um what kind of transactions might uh need this basess and how would they be identified? Can users request this? Yeah, I mean this is like very very researchy right now.

The the so the kind of transactions I mean the the the I chose the example on purpose right like there. So basically if you saw the slide like the title said DEX ideal case right I mean the point is uh if you want to exploit an arbitrage opportunity you need to yes there's the liquidity provider solution that's why I chose NFTs but if you put aside if you want to like your actual ETH to move to somewhere where you can like exchange in some decks in a different state part of the state then if you are not fast enough then you you might just lose the opportunity right and by the time you're going to do the swap, you're already paying much more or you're just not exploiting the market. So that's that's one example, but that one can be uh that one right now is being solvented by LPS. Uh but in this case, put an example like this one using FTS or any kind of app because with general state, you cannot rely on LPS. So um I mean yeah there like there's an argument like you know there's some people in the space that say that synchronous composibility is not even that needed.

But that's the beauty of rebase rollups, right? Like let's not even worry about that, right? Let's not even try to predict what the demand is going to be like. Let's just let's just like enable both and based on how the market dynamics change. We go base more or base less and we don't lose anything really.

Okay. And another question here upvoted. Have you explored how this might affect L2ME? So I mean I have not looked that much into it to be honest. Again this is very researchy but off the top of my head definitely if you're worried about me you'll be you should be more worried.

Uh yeah, I mean this this is kind of like a religion, right? because you could say on the like nonbase pace like there's like one sequencer so me is like much more exploitable there arably um in a reser scenario but in the base case you know base is going to like probably going to come like with gateways and you know gateways also kind of like give the same problem that the the the like basically a gateway can um buy like block space over multiple slots and also theoretically exploit me um so I don't think there's like big change happening from rebase rollups in terms of me. I might be missing something though. Gotcha. And then there's a question here.

Might need some clarification, but I'll try anyway. You mentioned that your initial example doesn't need the L1. Yes. Sequencer. Why?

I didn't understand exactly what you meant by that. Yeah, it doesn't need the L1 because both rollups, both uh like Bikini Bottom exist in a rollup and Wonderland exist in a rollup. They need Wonderland and Bikini Button to share the sequencer, but they don't need to share the sequencer with L1. Like if you need to share the sequencer with L1 is because you want to synchronously compose with something that lives on L1. But you don't need that in this case.

So actually I put the example with espresso, right? This would be enough. They just communicate through they both um become like rollups part that are part of espresso and they just like synchronously compose with it and they don't need to synchronously compose with L1. It's kind of like but you will also do this on a one with inclusion pre right instead of execution preconomy you only need execution pre to synchronously compose with L1 state. Okay.

And then a final question. Somebody was kind of querying uh you're you're at scroll currently. Is scroll working around based rollups? Um uh yeah, there has been some I mean yeah we're looking at it closely but uh we don't have it's not part of our current road map near near term to like switch to base right now. Gotcha.

Okay. Thank you for your time. Uh thanks everyone for attending and uh enjoy the upcoming lunch. Thank Let's give a round of applause.