XCMP vs PoW

[burdges]

We've chosen this XCMP message transport of requesting your incoming messages from the approval checkers for the sending block, which provides relative simplicity, performance, and reasonable security without nasty never-used-buggy fallback pathways.

A priori, it creates a DoS vector if all parachain nodes could demand message from validators all day, which we'll eventually plug by requests containing a proof that they've an upcoming block. As you can imagine this makes sense for Aura, Babe, and Sassafras by adding a second entry point into the PVF that checks a block creation credential early. It makes little sense for PoW however.

We'd eventually support XCMP for PoW chains, either via

• some layer-two-ish payment tricks that satisfy this second PVF entry point with money, or else
• via attaching the messages outside fully formed blocks so that the next block producer processes them, so the second PVF entry point is satisfied by the block existing and then gives you stuff to append.

It's kinda overly complex to add either right now, so..

@rphmeier Can we just ban PoW parachains from XCMP until we've more time to work out how we want this done, i.e. think about layer-two-ish options?

[AlistairStewart]

Even for Sassafras/BABE, it's not ideal to reveal your credential early, because then you can be DOSed.

[burdges]

It's trouble for praos/babe yes but you request anonymously in sassafras. We could explore attaching messages outside these other schemes too I guess.

[rphmeier]

Can we just ban PoW parachains from XCMP until we've more time to work out how we want this done, i.e. think about layer-two-ish options?

I don't know how to do that :(

[burdges]

An approach goes:

Initially, we permit requests from validators freely, but support rate limiting by validators. At this stage, any parachain could be captured, censored, or locked by adversaries hoarding XCMP requests.

We then later provide some recognition for the babe, aura, and sassafras block production capabilities as cumulus provides them. At this state, we warn PoW parachains that we corrected the XCMP problem only for babe, aura, and sassafras, and suggest they change block production mechanisms.

[burdges]

We should ensure validators only check one collation per collation authorization, meaning they should mostly ignore collators who equivocate in parachain block production.

[rphmeier]

@burdges So the pre-validation function should output some opaque but unique identifier which the relay chain validators can keep a cache of?

[burdges]

I think opaque works, but so does (relay_parent_height,collator_id), no?

I suppose relay_parent_height assumes sassafras or babe align their slots with relay_parent_height, which constrains design choices, probably fine though.

[rphmeier]

outdated