Many Smart Rollups - Interopability

Question

I read about SCORU and listented to last Teztalk with Yann about rollups but I am still unsure about one thing:

Lets say I have a rollup and I see an influx of users and need to scale up. I can simply create more rollups right? But the point I am missing here is - the new rollups I add to scale up, each has its own sr1 address right? So thas means that they are kind of its "own system". What I mean is are they all interoperable between each other? Or do the user need to do additional steps to bridge between rollups? Even if all rollups I deploy are meant for one single dApp still each rollup is different and has its own sr1 address? So for my understanding its not a "single" system.

If someone could elaborate and explain please as this still is not clear to me.. thanks

---

Followup Question to Arthur B response:

As far as I know deploying a rollup will cost 10k Tez as security deposit.

Lets say dApp XYZ runs on a rollup. XYZ gets popular and need to scale up horizontally -> need to deploy more rollups for XYZ

Users can move assets from one rollup to the other without needing a trusted bridge without additional user friction. The user does not even recognize that he is moving assets from one rollup to another - correct?

Now the limitations - slow inter roll-up synchronisation would be user friction -> can lead to bad UX due to waiting time?

When I interact with dApp XYZ that runs on several rollups, can it happen that I would wait for a longer time than the usual tx confirmations because of the roll-up synchronization?

And when it comes to the 10k security bond for running a rollup. If a dApp XYZ needs to deploy more rollups, does it need to put the 10k bond for every rollup? If this is the case isnt that a hefty "cost" and big barrier to achieve scalability on a high level?

Answer 1

I'll take a stab at the follow up questions.

You cannot scale a single rollup app horizontally, not at present anyway.

Think of a rollup as a program that implements the logic of a particular application by 1) taking inputs from L1, 2) doing some computation, and 3) perhaps producing some outputs on the L1. L1 provides consensus on 1. What we want is consensus on 2 and 3, and that's what the refutation mechanism embedded in the Tezos protocol provides.

In the case of e.g. Arbitrum, the "app" run by the rollup program is a full smart contract platform. Various teams are working on smart contract platforms built on SORU.

But you can also build "single purpose" rollups. E.g., a program that runs a single thing, like an order-book exchange, or a game.

So when we talk about horizontal scalability for Tezos via SORU, we mean that you can run many rollups at the same time for different purposes, and they won't compete for bandwidth or compute.

The protocol supports rollup-to-L1 communication after a 2 week delay. This can be used for Rollup-to-rollup communication, but whether or not that makes senses is highly depend on the apps you're trying to connect.

In practice, I expect it to look like this:

• Many orgs launch many rollups, and don't compete with each other for bandwidth or compute.
• When you need to scale your app's rollup, you buy a bigger computer and try to optimize for performance.

Additionally, folks might implement cross-rollup bridges for fast transfer of assets, just like people build cross-chain bridges. But these are inherently sensitive protocols, and users should be very circumspect of anything that involves trusted oracles. Hopefully, as a rollup ecosystem on Tezos emerges, we can discover protocols and interfaces that make sense and standardize them in TZIP's.

Answer 2

One way you can scale up is by increasing the computing requirements on the roll-up, that is vertically. Another way is horizontally, as you mention, by launching new roll-ups. In the latter case, you can move assets from one rollup to the other without needing a trusted bridge. There are limitations, inter roll-up synchronisation is slow, on the order of weeks, but possible without trusted third parties.