client/beefy: persist voter state

[acatangiu]

On each BEEFY block finality, save current voter state to Aux db so that, on client restarts, BEEFY voter can simply resume where it left off.

When there is no available BEEFY voter state in Aux db, the initialization process is:
On first GRANDPA finality of a block where pallet-beefy is available walk back the chain from that block and initialize voter to start at either:

• first encountered ancestor block for which there is a BEEFY justification available in the backend, or,
• actual block where BEEFY pallet was activated if no justifications found along the way.

The above is required to guarantee all mandatory blocks are finalized, even if, for example, a client runs for a while with BEEFY voter disabled (and GRANDPA makes progress, but BEEFY gadget not running). On re-enabling BEEFY gadget/voter, it will "resume" from the last justification or BEEFY Genesis, thus guaranteeing unbroken chain of mandatory justifications.

Fixes #11837

[svyatonik]

I was thinking that the justification for the authorities-change-block is necessary in BEEFY (as in GRANDPA) and we've just checked for justification in previous if. So probably this one is optional, or there is a case when it'll work? Sorry if I've messed something in my head :)

[acatangiu]

If all is running well, then yes, this one is superfluous, but it is required during initial deployment of BEEFY -> no justification in backend, but we want to start from current session beginning -> so we find the session start by walking up the chain;

I would actually prefer a more controlled deployment initialization, and drop this check. Something like adding genesis_auth_set_and_block_num() api to pallet-beefy. That way the voter can make sure that from said block forward, all mandatory blocks have justifications.

I'll code it up and add it on top of this PR to see how it looks 👍

[acatangiu]

@svyatonik done, take a look when you have time

[svyatonik]

Just safety question - VoterOracle::genesis() is using 1 if min_block_delta is 0 (min_block_delta: min_block_delta.max(1)) and here we don't check this (and it is called from the load_persistent where BeefyParams::min_block_delta is directly passed as an argument). Can it break something?

Also it seems that the min_block_delta is not actually persistent, since it is changed when we load state from the db. But it is fine to leave as is - just mumbling :)

[acatangiu]

good catch! I'll make sure it's >=1 here as well 👍

---

Also it seems that the min_block_delta is not actually persistent, since it is changed when we load state from the db. But it is fine to leave as is - just mumbling :)

I know, but it's easier this way 😄 min_block_delta is used in VoterOracle logic to choose next block to vote, and VoterOracle is fully persisted for convenience 😄

[svyatonik]

LGTM

[andresilva]

Logic looks good to me. Only a nit regarding state initialization.

[svyatonik]

Probably return Result<(), String> from this closure && use trace outside to print the error (instead of println)?

[acatangiu]

oh, the println are leftover from some test debug, I need to remove them. good catch!

[acatangiu]

@andresilva I've changed initialization process so it now relaxes original assumptions, and is thus more robust:

When there is no available BEEFY voter state in Aux db, the initialization process is:
On first GRANDPA finality of a block where pallet-beefy is available walk back the chain from that block and initialize voter to start at either:

• first encountered ancestor block for which there is a BEEFY justification available in the backend, or,
• actual block where BEEFY pallet was activated if no justifications found along the way.

The above is required to guarantee all mandatory blocks are finalized, even if, for example, a client runs for a while with BEEFY voter disabled (and GRANDPA makes progress, but BEEFY gadget not running). On re-enabling BEEFY gadget/voter, it will "resume" from the last justification or BEEFY Genesis, thus guaranteeing unbroken chain of mandatory justifications.