Staking async on Basti blocks

[cirko33]

WIP staking on Basti blocks running at 500ms

[sigurpol]

DQ to understand the context 😅 what we want to achieve here is the integration plumbing that proves staking-async can run on a 500ms chain. But we still aim / need (in a different PR) to increase Page count from 32 to 256 or whatever fits comfortably in mini-blocks. Is it a good summary?

So without the page count increase, the on_initialize trick to register on_poll's weight to be able to occupy full core from on_poll itself, would make it so that we go in FullCore mode for the 1st block of the core, the other 11 mini-blocks of the slot are sacrificed and so we end up in having PAH at 6s during election, correct?

In theory, if we make sure to have pages small enough (256 was a tentative number, to be measured) before we enable 500ms, the trick wouldn't even be required because election would spread around many mini blocks. We could keep it as complementary defense measure but sounds less critical than landing the page increase stuff.
The only thing we must avoid is to enable 500ms BB with current code (so no on_initialize trick and no page increase).

Please challenge everything I have written here - need to have a better look at all the BB machinery.

[Ank4n]

If we're checking for weight here, wouldn't on_poll then behave like on_initialize? This hook runs before all inherents (and transactions), so the remaining weight stays high at this point, right?

[cirko33]

on_poll is changed to on_initialize here, so does this answer your question?

[sigurpol]

can you link to GH's upstream issue here as well?

[cirko33]

So this has come from iterating with Claude
There is no opened issue yet, but things to keep in mind that were happening:

• The chain died ~30s in with --pool-type=fork-aware (the default)
• Switching to --pool-type=single-state fixed it

[kianenigma]

This is not a good solution for the main chains, we need to investigate further.

[sigurpol]

I would suggest as dirty-and-quick test to try to run zombienet on staking testnet with type WeightInfo = () for the multi_block / verifier / signed configs so zero weight and see if things works to end to end. By default, the staking testnet AFAIK points to DOT benchmark so MiB for block_snapshot_msp - which doesn't fit in the mini-block PoV limits and explain why you are seeing the UnexpectedPhaseTransitionHalt ( see https://github.com/paritytech/polkadot-sdk/blob/cirko33-staking-async-on-basti-blocks/substrate/frame/election-provider-multi-block/src/lib.rs#L747-L747 - can_execute in the EPMB on_initialize returns false because you don't have enough weight available). If the ugly hack to set weight to zero, let your test vs BastiBlocks of 500ms/1s work , then we should wire realistic weights in the testnet setup. Even playing with higher number of pages (32 -> 256) doesn't have an effect until you regenerate weights accordingly.
Also keep in mind you could still have a full core block even with 256 pages because of the target not being multi-paged unlike voters (see #10143 (comment))