Sequencer Support for Cartesi Rollups

Technical Vision Forum Technical Evolution Plan
1

This is also something that has been discussed frequently in the past. Sequencers are a crucial piece of the rollup stacks. I’d say they’re important for two main reasons:

  1. Soft Finalization: This is super useful for UX. When you have a trusted and relieable sequencer, it lets you predict the effects of your transaction before they’re officially added to the base layer – which can take a while. This means much quicker feedback for users on the app’s interface.
  2. Cost-Effective Inputs: By bundling interactions together and sending them to the blockchain in one go, sequencers help dilute the cost of engaging with Layer 1. This is cost-effective, especially when dealing with a high volume of inputs.

There’s also this idea of shared sequencing. It sounds promising for future stuff like better L2<>L2 interactions, atomic transactions, and other cool things.

building our own sequencer might seem like a big leap. It involves setting up and managing a lot of infrastructure. Luckily, there are already some pretty cool solutions out there. Like Espresso (a decentralized shared sequencer), which we tried and had some good results with: Minimalist integration Cartesi Rollups & Espresso Sequencer - #13 by milton-cartesi.

There might be some technical challenges ahead: we’ve got to figure out how to juggle reading from L1 (for things like deposits and sequencer downtime/censorship/malfunctioning) and the sequencer feed part. We might even need to delve into a bit of ‘time traveling’ to get it right. We’d have to think if the input box would be unified or if each dapp will have a different subscription to the sequencer. There’s stuff like sorting out input metadata (to allow fast finalization) and the signing/msg.sender aspects.

But all in all, I believe its an obvious step for the evolution of our rollups stack - it improves UX and makes interactiosns significantly cheaper.

2 Likes
2

I fully support this proposal, this is the way to go!

It should be noted that there is a way of using sequencers right now with the current Cartesi Rollups release: just deploy as an L3 on top of an L2 that does have a sequencer (like Optimism or Arbitrum). While this does give DApps lower latency and and costs, it has some very important drawbacks, like depending on a specific L2 and not being able to jump into the shared sequencer bandwagon - which aside from promising better L2 <> L2 integration, often comes bundled with extended DA capabilities (a must IMO)

Implementation-wise, IMO proper sequencer support should be done by allowing DApps to access base layer state via the Dehashing Device, as described here.

1 Like
3

I changed my mind about this after reading @Augusto’s comment in the Dehashing Device entry. I think we can support sequencers in Cartesi Rollups without needing full base layer state access - we just need to implement an InputBox namespace to allow applications to request L1 inputs.

1 Like
4

I fully support this initiative as a core step into our modularization. Cartesi is a native modular stack and we must move this ahead. @milton-cartesi mentioned all the benefits of that integration and will be the first time that we will see the cone of innovation further unlocked. Computation and Data scaled plus a smoother UX with lower latency.