pallet-aura: Allow multiple blocks per slot

[rphmeier]

This amends pallet-aura to optionally allow sequential blocks to be authored within the same slot. This is being done for paritytech/cumulus#2476 , as we often need to create a 'backlog' of blocks to post to the relay chain, and therefore can temporarily require block production to speed up.

This will also be useful for further roadmap items like elastic scaling and parallel block production, where chains need to make multiple blocks per slot for longer periods of time as well.

Update Guide

Set the new AllowMultipleBlocksPerSlot to false to maintain current behavior. Setting this value to true will be necessary for parachains looking to enable asynchronous backing later on, but this will require other changes alongside.

Example:

impl pallet_aura::Config for Runtime {
  // .. snip
  type AllowMultipleBlocksPerSlot = ConstBool<false>;
}

cumulus companion: paritytech/cumulus#2707

[xlc]

Config associated types require a full runtime upgrade

But a full runtime upgrade is required anyway?

The main point between storage vs config is that if we have the needs to toggle this value by governance without runtime upgrade. I can't think much use cases for now.

[bkchr]

The main point between storage vs config is that if we have the needs to toggle this value by governance without runtime upgrade.

Another point is also that a config type is that we don't need to read the storage for checking the value and reading the storage is "expensive". Especially for something probably never changes that often. So, please make this a config type.

[rphmeier]

But a full runtime upgrade is required anyway?

The main point between storage vs config is that if we have the needs to toggle this value by governance without runtime upgrade. I can't think much use cases for now.

What I mean is that we can ship this in Substrate master now without worrying about breaking downstream users' runtimes or behaviors, and then those parachains' governance systems can change the storage item when enabling asynchronous backing.

One of the concerns I hear the most is about breaking changes where alterations to Substrate master cause compiler errors in users' runtimes they have to fix. I am trying to avoid that but getting mixed signals now.

Three options:

• introduce breaking changes now and also later, when Cumulus' parachain-system pallet gets upgraded for asynchronous backing (latter seems unavoidable)
• avoid breaking changes now but have them later, when ...
• introduce a breaking change in this PR but don't merge that into Substrate master yet and do all the breaking changes at once.

[bkchr]

One of the concerns I hear the most is about breaking changes where alterations to Substrate master cause compiler errors in users' runtimes they have to fix. I am trying to avoid that but getting mixed signals now.

I mean that is a fine consideration, but we are doing much more crazy breaking changes. If you write a proper explanation in your pr description on what people should do, it will be a no brainer for them to upgrade. The explanation is also rather trivial.

[bkchr]

You can also do a feature branch, if you feel better with this. I don't care, but the current storage value is a no go.

[davxy]

Codewise obviously LGTM.

About the Config vs Storage. Frankly I would go with the Config as well and introduce the breaking change

[rphmeier]

Comments have been heard re the Config member. I will return to this PR soon and implement that - I have been preparing Cumulus for this change in the meantime

[rphmeier]

I'm not sure if we have Cumulus companions yet, but I opened paritytech/cumulus#2707 to merge as soon as this goes in.

[rphmeier]

bot merge

[paritytech-processbot]

Error: "Check reviews" status is not passing for paritytech/cumulus#2707

[rphmeier]

bot merge

[paritytech-processbot]

Error: "Check reviews" status is not passing for paritytech/cumulus#2707

[rphmeier]

bot merge