Staking Async: Tolerant against block time changes

[kianenigma]

Currently, staking-asyncin AH starts the election at a specific session index being reported, based on:

polkadot-sdk/cumulus/parachains/runtimes/assets/asset-hub-westend/src/staking.rs

Lines 296 to 297 in 18f6251

	type PlanningEraOffset =
	pallet_staking_async::PlanningEraOffsetOf<Runtime, RelaySessionDuration, ConstU32<5>>;

Once this election is computed, it is reported to RC.On the next session change in RC, it is queued in the session pallet. On the next session change in RC, it is activate in the session pallet, and reported back to AH.

The limiting part of this is that once RC receives a validator set from AH, it will immediately queue it in the session pallet, without any thinking involved. This limits how we can configure the above PlanningEraOffset:

• It doesn't have to be too early, or else an era ends up being 5 sessions.
• It doesn't have to be too late, or else an era ends up being 7 sessions.

This is rather simplistic, and we can do better.

• StakingAhClient in RC should keep track of when it last reported a validator set to session pallet.
• When a new validator set comes from RC, StakingAhClient will report it to the session pallet exactly 6 session after it last reported it.

Consideration for ForcingEra:

• staking-async in AH might legitimately want to force a new validator set sooner than scheduled, due to Forcing or a slash.
• To mitigate this, the ValidatorSetReport needs to have an extra force: bool field in it.
  • if set to true, StakingAhClient should report it to session immediately
  • if set to false, StakingAhClient should report it to session at the normal cadence.

This will significantly help us with async backing, which can alter the block times of AH, and mess with the scheduling of the election.

Once we have the above implemented, we can start the election safely much much before the desired time, knowing that the relay chain won't queue it in the session pallet sooner than expected. This will also help us be resilient against block time fluctuation.

[kianenigma]

https://github.com/polkadot-fellows/runtimes/blob/7e2d24eced47b35f572f968f3fc7561889c0e28f/system-parachains/asset-hubs/asset-hub-polkadot/src/lib.rs#L1231-L1233

All of these are wrong because this definition of MINUTES in PAH is wrong and probably still assuming 6s blocks

[sigurpol]

https://github.com/polkadot-fellows/runtimes/blob/7e2d24eced47b35f572f968f3fc7561889c0e28f/system-parachains/asset-hubs/asset-hub-polkadot/src/lib.rs#L1231-L1233

All of these are wrong because this definition of MINUTES in PAH is wrong and probably still assuming 6s blocks

https://github.com/sigurpol/runtimes/blob/01d9c3eb80839d98b8b19b7d7cf037f84aa89d97/system-parachains/constants/src/lib.rs#L67-L78

so should be 6s if I read it correctly

[Ank4n]

Once we have the above implemented, we can start the election safely much much before the desired time, knowing that the relay chain won't queue it in the session pallet sooner than expected.

I really like the idea of starting elections at era boundary. It creates much cleaner and more intuitive moment of when the snapshot is taken as well.

This is rather simplistic, and we can do better.

StakingAhClient in RC should keep track of when it last reported a validator set to session pallet.
When a new validator set comes from RC, StakingAhClient will report it to the session pallet exactly 6 session after it last reported it.

My suggestion is still for AH to control when era changes occur. AH can simply include, along with the validator set xcm, an instruction indicating which session this set should be queued at, and StakingAhClient would just follow that.