conductor block verification; to gossip or not to gossip?

[noot]

Problem

Conductor needs to be able to validate that the data it receives was actually validly proposed and/or committed by the sequencer. To do this, it needs to be able to track the validator set of the sequencer chain.

Currently, the conductor requires an RPC endpoint of a sequencer node, which is how it obtains this data. However this requires all conductor/rollup nodes to also run a sequencer node, or trust a remote node (not ideal).

This also ties into whether we want to keep the gossipnet at all - right now it is redundant since conductor must be run alongisde a sequencer node.

Solutions

1. Conductor must have an RPC endpoint of a sequencer node from which it can obtain validator info. This means all rollup nodes must then also run a sequencer node or use a trusted node. If we go with this option we can remove the gossipnet. This is arguably the simplest.
2. Remove the need for conductor to have an RPC endpoint of a sequencer node. Instead, we can implement a "validator set sync protocol" using the p2p layer. The conductor will come bundled with the genesis state of the sequencer chain. Conductor/relayer nodes will implement a p2p request-response protocol used by conductor nodes to sync the validator set from genesis in a trust-minimized way (basically a light client protocol, but just following the sequencer chain's validator set).
3. Remove the need for conductor to have an RPC endpoint of a sequencer node. Instead, we regularly post the set of validator set changes to DA. As above, conductor nodes will come bundled with the sequencer genesis state, and can sync to the current validator set using this data. Note: we need to post the set of validator set changes since genesis regularly, since DA does not guarantee storage. This means we will be posting more and more data every time the validator set changes.

Tradeoffs

Option 1 is the simplest to implement engineering-wise, we basically already have it. However, it puts burden on the end-user of a rollup on Astria to run or otherwise obtain a sequencer node. This might be less painful if cometbft light clients exist, but it seems there are none used in production currently?

Option 2 requires us to keep the p2p layer and also add more protocols to it. Sync protocols are non-trivial to implement (cometbft's fast finality makes it easier though). Also keeping the p2p layer will add a lot of engineering work/debugging time down the line - we will need to implement connecting gating, peer scoring, debugging sync, making sure our infra works with another p2p network, etc.

Option 3 is nice in that it allows us to not require rollup users to run sequencer nodes. However, it puts extra burden on validators (relayers) to post data to DA, incurring financial costs. Would need to design incentivization for this. We would need to keep the p2p layer for receiving newly proposed blocks, so would still have the p2p complexity. Also it might delay block verification by Celestia block time, since we need to know the current validator set to verify a block received from gossip, so this is probably not ideal.

Recommendations

Option 1 is easiest by far. Unless we feel strongly about keeping and maintaining another p2p layer (which is somewhat fine, should consider if there would ever be other use cases for it down the line) or not having rollup users run sequencer nodes, we should probably go with that.

Tasks

Preview Give feedback

1. remove gossipnet from conductor #332
   conductor gossipnet needs-scope production-quality +4
   
2. remove gossipnet from relayer #333
   gossipnet sequencer-relayer +2
   
3. (cleanup): remove gossipnet crate #334
   conductor sequencer sequencer-relayer +3

[joroshiba]

I think we use option 1 for now. Rollup nodes will always at a minimum need to be light clients of the sequencing chain, for now we say they must run a full node.

We can at a later date design how we would want to make it a light node.

[emhane]

related #332 and #333

[emhane]

Option 2: as long as the conductor is only interested in finalised blocks, being connected to the cometbft block gossip overlay isn't better than rpc. cometbft gossip allows a node to learn about a block at all stages in cometbft consensus (pre-vote, pre-commit, commit), whereas rpc only gives access to finalised blocks. on the p2p side, the relevant protocol to implement is the peer discovery protocol which cometbft named PEX. (composer may also be interested in implementing the mempool gossip protocol).

Option 1: cometbft rpc provides endpoints /p2p/filter/addr/{port} and /p2p/filter/id/{id} which can be used to retrieve the addresses to more cometbft nodes. (the cometbft node on) the trusted sequencer, would then only need to serve as bootstrap node into the p2p network. the conductor can then decide which peer(s) to request blocks from out of the peers returned over rpc. this implies, without putting conductor directly on the cometbft p2p layer with PEX in option 2, the relationship between conductor and sequencer can be decentralised.

[noot]

closed by #384