Bump async backing parameters

[eskimor]

For elastic scaling we will very likely need more relaxed parameters:

max depth 9 and also unincluded segment size for the para to 9 ... was needed in testing for a perfect 2s block time.

• Check potential spam impact - can we safely go to such high numbers?
• Enable on Kusama
• Enable on Polkadot

[sandreim]

Not sure we need 9, this seems to just be a workaround for a potential off by 1 bug, as the len of the segment never goes above 6 and at the same time we can't technically ever reach a segment of that size given block production runs every 2s.

[rphmeier]

There is a trade off between supporting high-depth elastic scaling and dealing with potentially large numbers of candidates.

With fast block building and high demand, we could see chains taking on 10+ cores at a time. Practically speaking they will have a single leader to achieve this, so they'll be far off from the worst case. Supporting that level of throughput could be pretty impactful for Polkadot!

How about a solution like this: we can accept max-depth=n_cores but start ignoring candidates from levels beyond some low number, like 4, as soon as n_pending_candidates > worst_case(4) as a way of detecting parachains that are going haywire with large amounts of potential blocks.

[burdges]

Is worst_case some historical information?

[rphmeier]

I just mean worst_case(n) as being "the largest possible tree of pending candidates of depth n under the async backing rules"

[bkchr]

With fast block building and high demand, we could see chains taking on 10+ cores at a time

I also already said in element that the change proposed here in this issue is a hack. We should instead fix the spam protection to handle this properly. Basically everything should track number of candidates per core and not per parachain. Backing group spam protection can just stay at using max_candidate_depth as the maximum number of candidates per group. In prospective parachains we need to support something like max_candidate_depth * num_cores per parachain as candidates (which doesn't change the number of candidates, as you could also have num_cores different parachains).

[burdges]

Yes, the relay chain knows which core each backing group works on, and coretime sales should tell the relay chain which parachain can submit to which core, so the relay chain could enforce this limit in backing, and that sounds cleanest.

We've considered other more dynamic models where the relay chain assigns backed candidates to core after backing occurs, which supports variable sized parablocks better. Afaik that's off the table right now anyways, but even if this returns then backing group number could likely replace core there.

[sandreim]

I agree this is not really optimal, but before we implement #5079 we should consider setting these params to support elastic scaling with 3 cores:

asyncBackingParams: {
    maxCandidateDepth: 6
    allowedAncestryLen: 2
  }

With #4937 maximum number of candidates we need to deal with is backing_groups_size x max_candidate_depth x allowedAncestryLen = 5 * 6 * 2 .

[eskimor]

I would much rather go with #4937 directly as it is safer. 562 is excessive.

[sandreim]

Not sure what you mean exactly, #4937 is supposed to fix #4800. Are you suggesting we should enable elastic scaling on kusama/polkadot only after we deprecate async backing params (#5079) instead of just changing them as above ?

[alindima]

This was done for kusama. max_candidate_depth was bumped to 6. We won't do this for polkadot. Instead, we'll prioritise #5079