Start PVF prechecking on finalized blocks not on active heads

[eskimor]

This issue made me think: We currently use a current relay chain head to fetch the PVF on disputes for example. Unfortunately this could fail if the code upgrade was signaled in a block that has been reverted. It is very unlikely that this can happen as we are delaying code upgrades for at least a session, but it is not impossible.

By only starting the pre-checking on finalized blocks instead of on active heads, we can do away with that possibility entirely.

It also solves handling of multiple forks, where one contains the upgrade and another one does not in a very elegant way and thus reduces code complexity.

@rphmeier any reasons, why this might be a bad idea?

[burdges]

We do not currently throw an similar to unexpected epoch change in this situation?

[eskimor]

The worst that could happen is that the runtime upgrade times out, if I am not mistaken.

[pepyakin]

It also solves handling of multiple forks, where one contains the upgrade and another one does not in a very elegant way and thus reduces code complexity.

I spoke too soon here, it was only on glance. So actually it's the other way around.

[eskimor]

Actually the issue is different than I was describing it. We need runtime enactment to be delayed significantly or wait for the code including block to be finalized because we keep track of the most recent head for fetching runtime code when needed.

On chain reversion, we won't update that head (because the new heads have a lower block number) - so we would still have access to any runtime upgrade containing block that just has been reverted, but we would not have access to any runtime upgrade that happened on the new chain currently being built. That is, until it's block number surpassed the number of the most recent head we had previously, only then will we use the new chain for fetching the code. If the runtime upgrade would have been enacted earlier, approval checking and disputes would break.

[rphmeier]

@eskimor We already have defenses against that:

Announced upgrades are applied only after a delay. I think in practice this is around 1 hour. So any reversion less than 1 hour will still have the code available as long as pending code is accessible by hash, which I believe it is. Framed another way: if there's a block that's disputed it must have some ancestor B that is at least 1 hour old where the code was initially posted on-chain. Whatever our 'best block' in the disputes subsystem is, it's exceedingly likely to have B as an ancestor as well. Furthermore, old code is kept on-chain for a long time as well which would help prevent this issue.

[eskimor]

Thanks @rphmeier ! @pepyakin and I already discussed and we agreed that probabilistic finality is good enough. Let's close this - it kind of asks for food (attention) @pepyakin ;-)