paritytech
EPMB: Prepare for BastiBlocks (updating `Pages` config)
See: https://github.com/paritytech/polkadot-sdk/issues/6495
A BastiBlock splitting the 2s + 10MiB POV into smaller subsets. From the runtime perspective, it thinks it is producing multiple small blocks, while the relay chain receives the same 1 block to validate.
BastiBlocks might be able to allow us to configure some parachain blocks to be full blocks, and not splitted (for example in a runtime upgrade or MBM block). But since we know the election can take up to 1h in Polkadot, it is pretty bad UX if PAH has 6s block times for 1h per day, and, e.g. 500ms for the rest.
The ultimate solution is to add the ability to EPMB to increase its Page configuration. This value is currently 32. Increasing it to, probably 256 will be enough such that:
- Without basti blocks we do the same thing, just in a longer time
- With basti-blocks, each chunk of our work is small enough to fit in a 1/12th of a block.
This also hinges on https://github.com/paritytech/polkadot-sdk/issues/10142
TODO
- [ ] Increase
pageconfiguration - [ ] Register on_poll weight in on_init: See https://github.com/paritytech/polkadot-sdk/issues/10143#issuecomment-3616918585
So increasing number of pages would be just a mean to avoid to rely on @bkchr 's dynamic block interval (see here) and just play safe? And if we don't do it from day one (day one where BastiBlocks are released :) ) and e.g. we have 3 cores on AH, we would end up just in a small amount of time per day where AH behaves like it has done before BastiBlocks? Did I get it right?
So increasing number of pages would be just a mean to avoid to rely on @bkchr 's dynamic block interval (see here) and just play safe?
Yes. But also we have around 4 sessions to run election (assuming we start election as soon as an era starts), so we can safely spread the election work into smaller chunks per block.
And if we don't do it from day one (day one where BastiBlocks are released :) ) and e.g. we have 3 cores on AH, we would end up just in a small amount of time per day where AH behaves like it has done before BastiBlocks?
Yeah elections would run 3 times faster with 3 cores on AH.
Would actually add to this that validator reward payout and slashing might be problematic with smaller blocks and we will need to increase page size for validator exposures as well.
I am totally fine in increasing page size (maybe on Kusama we should account for some other changes since there election cycle is much shorter but it's a detail).
But ok for me to understand better (sorry for the silly questions, @Ank4n , @bkchr !): let's assume instead as hypothesis that we have 3 cores on AH + BastiBlocks enabled, and that we keep 32 pages as of today for EPMB. During election time once a day, the block interval would increase dynamically in response to the temporary PoV "spike" due to EPMB . How does it map with the number of cores we actually are going to use though? A "fat" block would just occupy a single core in the worst case scenario, is it correct? So in principle, it is still true that the election will potentially run 3x faster.
But even if it happen, is it a problem? Even if the election completes immediately, what is critical is when AH decides to export its new set of validators to RC. The effect of a fast election is just to have the new set of validator ready much faster, but they will just stay dormient until it's a good time to enact them and that can still be done at the proper time in order to respect the 1d cadence we have today or am I missing something? I am pretty sure it's the latter!
During election time once a day, the block interval would increase dynamically in response to the temporary PoV "spike" due to EPMB . How does it map with the number of cores we actually are going to use though? A "fat" block would just occupy a single core in the worst case scenario, is it correct? So in principle, it is still true that the election will potentially run 3x faster.
BTW, when you want to support occupying the full core (aka a "fat" block) from on_poll, you will need to register the weight in on_initialize. I did not found any better way right now to support on_poll.
During election time once a day, the block interval would increase dynamically in response to the temporary PoV "spike" due to EPMB . How does it map with the number of cores we actually are going to use though? A "fat" block would just occupy a single core in the worst case scenario, is it correct? So in principle, it is still true that the election will potentially run 3x faster.
Yeah, that’s my understanding as well. And we don’t necessarily have all blocks within that 1-hour window being fat blocks, right? The expensive ones should just be: the snapshot blocks, the validation blocks, and maybe the export blocks.
Also, with multiple cores, we’ll be producing multiple fat blocks within each 6-second slot, which still effectively reduces the average block time.
But even if it happen, is it a problem?
I think the only concern is potentially having a 1-hour window of fat blocks every day on AH. And since this work can be spread out (we already pagify the election blcoks), with just configuration updates, we can ensure even the election blcoks are basti blocks. But I think you are right that it’s not a major issue, more of a "nice to have". The dynamic block-time increase stuff is super neat and saves the day.
Even if the election completes immediately, what is critical is when AH decides to export its new set of validators to RC. The effect of a fast election is just to have the new set of validator ready much faster, but they will just stay dormient until it's a good time to enact them and that can still be done at the proper time in order to respect the 1d cadence we have today or am I missing something? I am pretty sure it's the latter!
I don't think you are missing anything. 🐱