Slow availability

[sandreim]

Currently on Polkadot RC we see that frequently availability doesn't finish in a single block. The metrics indicate that it happens for all parachains that have blocks pending availability, rather than on a few cores. This means that the block producer has not yet seen 2/3 bitfields when the parachains inherent is provided.

This is impacting block times primarly, but also block confidence. Because the age of the relay parent of the off-chain backed candidates is reduced and they can potentially be dropped before being backed on-chain.

[sandreim]

See block #30601066 and #30615352 . It has an empty parachains inherent

Block author is low quality validator, misses backing statements and bitfields: https://apps.turboflakes.io/?chain=polkadot#/validator/1ngMQVEqj9Dm1RNUxAQTNeBwePyKq8rXcM5x3bT2KqgFZ5n

[sandreim]

• #30614476 #30611754 , same issue. Author: https://apps.turboflakes.io/?chain=polkadot#/validator/157wUw3289QR7E2bMnVUxzwMYQX69S14kuYWARVYs4d8YEdt
• #30612056 . Author: 141FXbEYs6vTwjN82h8zD8JGDNZW1qqgTt8KphUB1FqWG3BQ

[burdges]

Imho our first question: Can we handle this better when one or many validators behave this way?

We'll have more situations like this even from previously good validators, like when some BGP routes become disrupts by conflicts or whatever.

[sandreim]

Yes, I am thinking we could chill them if they make more than X such blocks, but up to some limit.

[burdges]

I wasn't even addressing how to solve this problem, but asking: What does this problem expose as weak elsewhere?

An RC block producer cannot really be rescheduled easily, but we could exclude them in future epochs of course.