BEEFY: Support protocol live-update

[acatangiu]

P<>E Bridge Context

BEEFY protocol on Polkadot side is followed by on-chain BEEFY-light client on Ethereum.
Ethereum side of the bridge is supposed to be only controlled by Polkadot governance. As such, BEEFY liveness is required to make any changes/upgrades on Ethereum side.

This means we need to pay special considerations to the on-chain Ethereum BEEFY-light-client update scenarios.

Backwards compatible protocol updates are naturally supported by BEEFY worker, and should easily be supported by BEEFY light client too.
In such a case, the Ethereum BEEFY light client could be updated while still running the old version of the protocol, then the workers and the protocol version can be updated on Polkadot.

Problem

We should also support protocol updates that are not backwards compatible - this is not easily possible right now. Let's explore the scenario:

Let's say we find that we need a critical fix which would change the BEEFY protocol in a non-backwards-compatible way, let's say v1 needs to be upgraded to v2, but v2 data structures are incompatible with v1 ones. This means:

• if we update the Polkadot side first the bridge is broken with the light-client unable to follow anymore,
• if we update the Eth side first, the bridge is temporarily frozen with the new light client unable to follow until Polkadot side is also updated.
  But updating the Polkadot side means deploying the new BEEFY worker versions to validators (validators need to upgrade polkadot binary) -> meaning we need to do a lot of offchain coordination with validators which is not desirable.

Solution

1. Add support to BEEFY client for being able to run two protocol versions at once in parallel

• first level of support is being able to generate justifications of different versions,
• might also need support for being able to completely run two protocols in parallel for cases where there's protocol changes at the votes/signatures primitives levels and justifications can't simply be migrated from v1 to v2.
• Complex solution but allows "seamless" update -> no bridge downtime whatsoever:
  1. update workers (validator clients) -> both v1 and v2 justifications are available - bridge still uses v1
  2. governance updates light client through blocks still bridged over using v1 -> bridge starts using v2

2. Add support to pallet-beefy to specify which version is live in current block so runtime can decide when clients (validators) switch from v1 to v2

• way simpler, but could lead to temporary downtime:
  1. update workers (validator clients) -> they are v2-capable but still use v1 - bridge still uses v1
  2. governance updates light client + sets block number where v2 should be activated - delta of blocks between the two is "bridge downtime" - but this delta can even be just 1 block, so in the happy case it's practically no downtime 👍

I would go with second option. Thoughts?