Asynchronous-backing compatible Aura, not plugged in

[rphmeier]

Closes #841

This PR prepares the logic for Aura for asynchronous backing according to #2476 but we will still require some updates to how the Polkadot node receives collations in order to fully activate.

The implementation listens for new relay-chain blocks and finds the best parachain block currently descending from the included block as-of that chain. It also selects the slot and timestamp according to the relay-parent's BABE slot (and modifies the relay-driven variant to do the same).

While I originally thought that we'd introduce new block announcement logic, I've decided to go with a different approach:

• Accept all block announcements
• Perform equivocation detection / sybil-resistance at the block import stage

The main reasons for this are that equivocation detection isn't best done at the block announcement stage, nor is it safe to deny blocks just because they are equivocations (other authors might receive those equivocations in a different order and build on top of them). This is also more congruent to what is done in Substrate Aura/BABE.

The bulk of the diff comes from refactoring - lots of functionality is common to the async-backing logic and the backwards-compatible collation logic.

TODO:

• Logic for recursively searching for the parachain-parent
• Submit collations to the Polkadot side (deferred to after Update collation-generation for asynchronous backing polkadot#5056)
• Rename block announce validator to make it clear it's optional
• Introduce a new block announce validator which ignores old block announcement data
• Introduce new runtime API for unincluded segment + Aura
• Basic sybil/equivocation resistance

[BradleyOlson64]

Perhaps we can get rid of this TODO. Seems that you handled authoring_duration in the collator params of lookahead.rs

[rphmeier]

Unfortunately, that doesn't really work for the 'basic' collator as the time limitations are very strict (and this PR just maintains behavior as this code is becoming obsolete)

[BradleyOlson64]

👍 Only nits and questions from me.

[BradleyOlson64]

You're probably aware, but it seems the changes to Slot derivation in #2658 will require changes here. That is, assuming 2658 gets merged first.

[rphmeier]

This logic works, as it's only meant to be a rough representation of "now". The Aura slot is calculated as the relay-chain slot, converted to a timestamp, converted into the parachain slot. Given that the timestamp->slot conversion rounds down, this implementation gives attackers slightly more lenience in creating blocks in the future, but no more than 1 relay-chain slot's worth.

[BradleyOlson64]

@seunlanlege Implements a slightly more general version of relay-chain-interface::header() here.

Perhaps his could be incorporated.

[slumber]

I know it isn't plugged in, but

1. Are we supposed to check that velocity isn't exceeded? Otherwise, it could cause a panic in the runtime. (I assume it will be part of can_build_upon)
2. Doesn't it affect parachain block times?

[rphmeier]

1. Yes, can_build_upon would be intended to check this. A runtime panic is not really a problem, as it's a panic in an illegal-to-author block (same as if you tried to create a block with the wrong author for the slot). The panic would not happen on legal blocks, so all we have to do is make sure that collators can tell what's legal to author and what's not.
2. The overall mechanism here does affect parachain block times, in that blocks when the unincluded segment is empty will come faster as we build up the segment and slower when the segment is full. Is that what you mean, or something else?

[slumber]

Is that what you mean, or something else?

Yes. Concern is this behavior might not be something parachains would expect.

[rphmeier]

There is really no other option - either you produce blocks at a constant rate, and never build a backlog, or you build an infinite backlog. We do need to communicate these properties, I agree, but based on conversations and other socialization of the concept that it's pretty uncontroversial.