backing-performance: Evaluate only doing work on best block

[eskimor]

Currently we start work on every imported block. This is really bad for performance as the work being done is significant, e.g. a collation for each fork, availability, full gossip, .... With each fork we significantly reduce the load we can potentially handle. Ideally we would only start work on the current best fork, as exposed in substrate.

This would need to be thought through though, as it might open attack vectors, as mentioned here.

[burdges]

It's tricky.. @AlistairStewart can tell you fun stories of chain splitting, but..

Almost all work done by polkadot validators should be approvals checks, including related gossip, but available candidates forks a couple blocks behind assignments and other work. We've trouble abandoning work once we've assigned ourselves, but we could delay work on BABE secondary blocks when a primary block appears. That's pretty BABE specific though and Sassafras obsoletes that, so I'm tempted to ignore that problem.

We should be prepared for workload increases when forks become longer than a couple blocks anyways since then we've somewhat different candidates, but..

Availability distribution happens immediately after backing, but similarly gets bounded by backer rules, although availability bitfield votes depend upon the chain. Approval checks and reconstruction benefit from the same backer rules, which limits damage when forks grow longer than a coupe blocks.

In brief, we should've already caught the bigger fish within this problem space, but..

Approval votes already create a mapping from grandpa votes possibly on future blocks back to best finalizable chain. We could explore grandpa informing our notion, not just of best chain, but of "the chain everyone wants to work on" somehow. It's tricky though..

[eskimor]

Thanks @burdges !

[eskimor]

The currently best fork as exposed by Substrate is unfortunately not really the best fork, but just the longest. Only BABE knows about the real best fork, so we would need to expose that information in order to implement anything in this regard.

[bkchr]

@eskimor Babe does already exposes this information on import:
https://github.com/paritytech/substrate/blob/master/client/consensus/babe/src/lib.rs#L1613-L1637

Aka, the "best fork" should be set as best block.

[eskimor]

Prioritize according to results of #4302

[eskimor]

Does not seem to be a major issue and will be resolved with SASSAFRAS anyway.