Transactions are still submitted to L1 before reaching the sequencer for L2/ a rollup?

Question

All transactions are still submitted to L1 before reaching the sequencer for L2. If this is the case then I still need to wait 15s for every operation to be submitted?

So my understanding is that latency is the block time here? Our rollups have 15s blocks without a centralized sequencer? Because every transaction comes from the L1, so they are not directly submitted to the sequencer? Because to interact with a dapp on the rollup you have to get your tx through the L1?

If we want to keep the rollups decentralized, then we will have 15s latency because they don't have blocks of their own, it's just the latency from L1 blocks. BUT if rollups don't have blocks, how do they keep track of their internal state? how do you index a rollup?

But then again I ask myself - Rollups will have blocks right? Block times can be faster than the L1. They can't post commitments faster than 15 seconds, but this doesn't matter for the rollup user.

How rollup node and L1 node interacts is not exposed to you. Dapp users don't touch the inbox. As a dapp user you talk to the rollup node rpc?

So following this logic "no centralized squencer" means that if you don't like how a rollup node sequences operations, you can set up your own which orders operations in the way you like and send your own inbox messages and no one can refute your messages as long as they are compliant with the kernel?

Can someone please elaborate the process? And correct me if I am wrong?

Answer 1

The key selling point of SORU is its versatility. It's fully decentralized by default, but nothing stops application developers from making tradeoffs that make sense for their DApp to deliver the user experience they're after.

When we talk about latency, there's several things we might mean:

• Time until data is finalized on the L1 (2 blocks).
• Time until user is reasonably sure their operation is included in the final history, and sure of the result.

For most vanilla L1 DApps, these two are roughly the same, modulo indexing time. You submit an operation, you wait for it to be included in a block and then confirmed by another block, and then query an indexer for the result. The result is that every interactions involves 30 seconds of watching a spinner go round until things finalize.

But we could imagine more subtle setups. Suppose that instead of users submitting operations directly, they sign the payload and give it to a centralized sequencer, which batches them and submits them to the L1. This saves on gas overall when the scale is large enough, but you have to write more plumbing yourself.

Once you constrain things to go through a sequencer, then the sequencer is in general safe to pre-apply the operation and respond immediately to the user with the result. In this scheme, you can have the lowest latency possible, with the user receiving the result in a single round trip.

The drawback to this approach is you lose censorship resistance. This can be recovered by adding a "delayed inbox" that anyone can post to, and which is executed after transactions from the sequencer.

Now, like I said, this can all be implemented for smart contracts on L1. But it's cumbersome to do so. There are constraints on compute and bandwidth available. Rollups alleviates the compute constraint by doing compute off-chain with the fast-execution engine, and rollups alleviate the bandwidth constraint via the data reveal channel. No more gas golf, no more exorbitant fees for posting lots of data - just write the user experience you want, in the language you want (if it compiles to WASM). This comes at a cost of course - someone has to run the rollup infrastructure, which requires 10K xtz staked and resources to run and maintain.

As to L2 blocks, the kernel does all its IO on raw bytes. It's up to kernel developers to impose whatever semantic meaning to those bytes they choose. If you're implementing a sequencer, it likely makes sense to batch operations for efficiency reasons, and that's essentially a block. Perhaps standards around the encoding of those blocks will emerge to help prevent reinventing the wheel for every rollup indexer. But that's all opt-in, and stuff we'll have to discover as a community by trying stuff.