Ethereum

We often hear that “L2s fragment UX and liquidity”, while this might be case today, it won't be in the future

In this thread we will explore Based Booster Rollups (BBRs) and how they solve fragmentation

🧵👇

1/ First, what is a booster rollup?

Well, you can think of them as an extension of the L1 itself, the boosted rollup can interface with apps on the L1

Any rollup can add a booster functionality but it makes the most sense to add it to based rollups like @taikoxyz

A Based Contestable Rollup that will go bbrrrr | Ethereum-equivalent ZK-EVM | Join the community: https://discord.gg/taikoxyz.

researcher // based rollup maxi // intern @taikoxyz

2/ To simplify a bit: Using a booster rollup for your app is kind of like adding extra SSDs/CPUs to your computer

3/ I see two main use cases for them:

1. Allowing multiple rollups to access an app, without fragmentation
2. Scaling apps by adding more and more BBRs while having the frontend act as a load balancer between rollups

4/ Let's see an example for the first one:

Imagine you see a flourishing ecosystem on rollup A and B, but you're not sure where to deploy your app.

Well, you can deploy your app on the L1 layer. By doing so, users on both rollups will be able to interact with your app

5/ The BBRs essentially act as the execution environment for your app

Additionally, other apps on these L2s can seamlessly integrate with yours

TL;DR: You can interact with all your favorite apps, regardless of the rollup you're using

6/ Now, let's explore the second use case:

Imagine you're building a DEX, you know that relying on a single rollup won't give you enough scalability

Additionally, you want to be able to meet user demand and keep gas fees as low as possible

7/ In this case, you can deploy your app on the L1 and use the BBRs as your execution environment

Meanwhile, your frontend can route people through the most cost-effective rollup

Plus, you can easily add more rollups to handle the influx of new users

8/ It's funny to me that we already use systems like this in the traditional Web2 world

Users are routed through load balancers that distribute traffic to servers with the lowest usage, we just haven't implemented this in rollups yet

9/ To wrap up:

Both approaches are quite similar, apps need to decide which one is better suited for them

Ultimately, the chains will be abstracted away, so users won't need to worry about them