p2p: Decouple ChainID from DA networkID

[renaynay]

Make it possible for DA network to run a different ID than the core chain ID (but still use the core chain ID within the DA network ID)

Also another issue found - it's possible to run a bridge node against core with a different chain ID.

[Wondertan]

That sound very wrong. What's motivation behind this?

[renaynay]

@Wondertan @musalbas, @liamsi and I had a conversation about this 2 days ago where @musalbas mentioned that it should be possible to run several DA networks against 1 core consensus network. This would require us decoupling the concept of a ChainID from a DA network ID.

The solution is quite small non-invasive. I will be linking the PR shortly. The chainID will always be contained within the DA network ID.

While it does sound "wrong", it should still be possible for us to upgrade the DA network via changing the network ID without having to do the same for core network.

[Wondertan]

@musalbas mentioned that it should be possible to run several DA networks against 1 core consensus network.

What's the goal though?

To me it seems counter directive when we actively discuss the path towards merging both both networks, but end up decoupling those even more.

What's the problem here? Were other solutions analysed?

[renaynay]

@Wondertan yeah it seems counterintuitive when the goal is to move towards a merged network, but until we have it, it's nice to be able to decouple DA network upgrades from core network upgrades.

The problem here was more theoretical when discussing arabica-9 upgrade to latest RC: we have a breaking change to shrex-nd protocol and I told @musalbas that it's possible to run nodes on the same network with the same networkID (arabica-9) that run an upgraded version of the shrex-nd protocol, and that it would be fine because if a light node makes a request via the upgraded shrex-nd protocol, it would be to a peer that actually supports that upgraded protocol and can serve it, and the light node would not mistakenly be able to make requests to peers running the older version of the protocol.

@musalbas said it's "cleaner" to just upgrade the network ID (which I don't fully agree with because I still don't think we need to partition the network to that degree just for one of the node's protocol upgrades -- headerex, shrex-eds both stay the same).

Regardless, we both agreed on the point that it should be possible to run more than one DA network against a core network (in the case someone wants to spin up a test DA network against the data of a real chain - or in the unlikely case of a catastrophic failure/critical bug in DA network that requires a networkID bump, like an issue with header format maybe or with dependency).

[Wondertan]

@renaynay, appreciate your detailed response❤️