Where to sequence transactions?

[kelemeno]

After Mustafa’s latest post, a discussion has been opened to add state to the DA to enable more efficient RU operations. In light of this, I would like to look at the question of sequencing, and X-RU atomicity.

The DA layer can be used for sequencing txs. As I understand this is the traditional Celestia vision.

However this is not really an efficient or flexible method.

• A lot of Rollups will not use the DA layer for tx sequencing, they will have more efficient external sequencers, even if those sequencers post the txs as batches to the DA layer (scroll, polygon zkevm).
• Volitions, ZkPorters, and Validiums will also not use the DA layer for sequecning, as the off-chain component means they will store state diffs and not calldata onchain.
• Finally a lot RUs will want their users to pay for tx fees in the RUs own tokens, so they will use external sequencers.

However, external sequencers are also not ideal. We will also need to use the DA layer for forced txs to a RU, this is how CR is guaranteed. This is not possible with external sequencers.

Finally, for X-RU atomicity, using the DA layer for txs will also be needed. This is similar to the CR case, but there is a major difference, as X-RU txs are different from normal txs. They are already the outputs of a RU, this means they can already have requirements that are enforced in the RU’s proof (fees, format, etc), and so they cannot be used for spamming/dos attacks.

So we have 3 requirements that our sequencing mechanism needs to satisfy: efficiency/flexibility, CR, and X-RU atomicity.

I think the simplest compromise between these options is the following:

• We will need external sequencers. As they are external, it makes the system modular, so it makes the whole design simpler. They can even scan the DA layer for txs, if that is what they want to do.
• We will need X-RU atomicity, so we should build that into the protocol. This is easier than users directly submitting txs to the DA layer, as X-RU txs are submitted along with proofs, so we can have them satisfy some requirements.
• Once we have external sequencers, and X-RU atomicity, CR is solved, as a user will be able to submit a tx to rollup A via rollup B, even if the external sequencers of A are censoring.

So we only need external sequencers and X-RU atomicity. The X-RU txs are submitted to the DA layer along with the proof of the RU. For atomicity we will need the RUs to keep track of the X-RU txs. There are two ways to do this, scanning the DA layer, or we can keep track of the X-RU txs in the DA layer itself as some form of additional state.

This is where this ties into Mustafa’s post. I am not exactly sure how to exactly keep track of the state of the X-RU txs in the DA layer, but I’m pretty sure a shared proof will be necessary. (Maybe in a 2D KZG commitment scheme, as that would enable the senders and receivers to open up the commitment from the different dimensions, so it could be efficient.)

[musalbas]

I assume you’re talking about cases where you might want to do cross-contract calls between rollups, rather than simply minting and locking operations, right? What would be required on the DA layers’ side to enable X-RU atomicity?

Can you still have have X-RU atomicity implemented on the L2s/settlement rollups (eg between to L3s) or shared sequencers? The idea of the zk settlement proposal is that if you achieve L1 base layer functionality escape velocity, you can do anything you want on the layers above.

[kelemeno]

@musalbas

Can you still have have X-RU atomicity implemented on the L2s/settlement rollups (eg between to L3s) or shared sequencers?

I think between L3s it is possible using the L2, but not using the ShS (or at least, not the strongest form of atomicity).

@musalbas

The idea of the zk settlement proposal is that if you achieve L1 base layer functionality escape velocity, you can do anything you want on the layers above.

Doing things on the layers above i.e. on L3s etc, will not be enough, as a single L2 will not be able to handle all of the throughput, only the DA layer can do that. So the DA layer should handle the requirements of the RUs directly, proof verification is one of these as per your post. And I also think X-RU txs are another. If we do this correctly, we don’t even need L3s.

@musalbas

I assume you’re talking about cases where you might want to do cross-contract calls between rollups, rather than simply minting and locking operations, right? What would be required on the DA layers’ side to enable X-RU atomicity?

Even for lock&mint (or burn&mint) txs, if we want the tx from RU A to B to be atomic, then we need to guarantee that B can receive the tx, and check its validity. This means that we need to post the tx and the proof to the DA layer.

After the tx is on the DA layer, we need to enforce that B consumes the tx. This can be done in multiple ways.

1. Originally in the Lazyledger paper, you mention applications and dependant applications, where the nodes have to handle the state of both of the apps (this was before proofs).

2. The Sovereign Labs way. B scans the DA layer for all txs, so it can also scan it for X-RU txs. If they find such a tx, they also have to have A’s current proof, which they can atomically receive from the DA layer. Alternatively, they can search for the shared proof of the RUs.

3. We can add state to the DA layer that checks the proofs of A. If we do this B doesn’t have to scan for A’s proofs, they can just read it off the DA layer. Similarly, we can add state corresponding to the txs. This would mean that each time a RU updates their proof, they would have to consume the txs that they have received. Similarly, when a RU sends txs, the receiver gets it in their inbox.

At this point we have to talk about the state and tokens of the DA layer itself. I think it should be zk proven. The DA layer is itself also a VM, even if it does not support smart contracts. And to manage its scale, it will have to be proven in an aggregate/shared proof, containing all the txs on the DA layer, including the proofs for the rollups.

This shared proof can prove the validity of a commitment to the DA state, the State Commitment. This DA state commitment will contain a commitment to RU A’s current state. When updating this state commitment SC_1, RU A will have to open SC_1, prove that their previous state has commitment A_1, and prove the transition to A_2. This proof can be posted on the DA layer. After it is posted, the shared proof can be created, which aggregates the A_2 to become SC_2.

If this shared proof is created, it further makes sense to exclude the DA layer from sequencing, as this would only bloat the state that has to be managed in the Shared Proof.

Similarly to this State Commitment, the shared proof should also handle X-RU txs. This can be done in a X-TX Commitment, XC. This is bit more complicated, as it is two dimensional, each rollup might send txs to any other rollup. This makes opening and closing this commitment more complicated, but I think a 2D KZG commitment would probably work (it might not be zk efficient though).

[musalbas]

I see, you mean for bridging tokens other than TIA, i.e. for tokens minted natively within rollups. Yes, those rollups will need to form some sort of (direct) bridge with each other within their state machines.