Sharing a Sequencer Set by Separating Execution from Aggregation

[evan]

@colludingnode

What is the shared sequencer set’s fork choice rule? Do you envision a BFT-style consensus for this shared aggregation layer?

It could be arbitrary, and I’m hopeful that people get creative with them. For the MVP, I just used tendermint, which is pretty overkill. Something lighter, faster, and less secure would likely be desired.

@colludingnode

Optimistic roll-ups will still presumably need an “executor” role for the participants who compute state roots, and I imagine they’ll need to be staked, right?

As briefly described in the post, yeah there needs to be some fraud proof spam prevention mechanism. While this could end up looking similar to aggregation logic, I also think it could it could also be simpler and more flexible. One could imagine using a simple unbounded committee, anyone with enough stake delegated to them could sign headers, and there’s no need to take turns either. Everyone can sign each header individually, and light clients could collect multiple gossipped headers should they want to.

@colludingnode

Validity roll-ups don’t run into this problem and can simply reward provers who permissionlessly race to post roots + valid proofs.

Yes!! Anyone can produce proofs, and can be rewarded arbitrarily for doing so.

@colludingnode

If you’re a full node of a roll-up, you must now be a node of the shared sequencer chain in addition to a node of Celestia. This is because you must be able to validate the signatures of the aggregation layer’s validator set when you scrape and process blobs out of the DA layer. Light clients of roll-ups need to be able to verify this as well, right?

so the light clients of roll-ups would need to sync the headers of celestia, the roll-up, and the aggregation layer

Yeah, as briefly mentioned in the post, using soft finality or inheriting the fork choice rule requires being a light clients. However, without soft finality, it is not required.