BEEFY: add support for slashing validators signing forking commitments

[Lederstrumpf]

Description

Builds on #1329 - integrates ancestry proofs (https://github.com/Lederstrumpf/merkle-mountain-range/tree/ancestry-proof-rebase-v0.6.0) - see #1441 for details. A presentation held for W3F research describing the slashing protocol can also be found here: https://drive.google.com/file/d/17vJnGhOWw0G0_e3xEXvycYYu3q5Y-_PU/view?usp=drive_link

Includes both header & ancestry proofs for proving a fork equivocation.

For reviewing, I recommend first reviewing the changes in #1329 (excludes ancestry proofs & future block equivocations), and then reviewing the diff of the PRs (Lederstrumpf/polkadot-sdk@rhmb/beefy-slashing-fisherman...Lederstrumpf:polkadot-sdk:rhmb/beefy-slashing-fisherman-ancestry-proofs).

Closes #1120

Below are design choices made and the two routes for implementing them, where A. is currently implemented:

design choices

keeping header proofs

As described in #1441, header proofs are only sufficient for proving equivocations up to 4096 blocks ago, whereas this PR adds ancestry proofs and slashing for future blocks.
While ancestry proofs could replace header proofs entirely, my reasons for keeping header proofs are the following:

• A reporter may not be running offchain indexing, hence would be unable to generate an ancestry proof. Having both proofs available increases the number of viable fishers.
• In case there's a bug generating the ancestry proof, the header proof would still be valid

slashing equivocations on future block heights

If the equivocating payload is for a future block, by necessity, we cannot prove the equivocation with a header or ancestry proof, by obvious necessity.
As suggested by @acatangiu, we could wait for equivocation.height to be reached on the canonical chain and only report and slash then. This is sensible since the equivocator's funds would remain locked at least for the following 28 eras, and therefore it would be safe to delay reporting & slashing within that timeframe.

We can also slash eagerly by just checking that the equivocating commitment has been duly signed. My reasons for slashing eagerly instead of waiting for equivocation.height are the following:

• We'd have to add logic for withholding equivocation reports until equivocation.height is reached, which I expect to be more complex than the logic for slashing eagerly.
• In snowfork's solidity implementation, it is not checked whether equivocation.height (local name: commitment.blockNumber) is for the current/next era, hence whether the current/next validator set even has the authority to author blocks. As such, without slashing for future blocks, the current/next validators could create an equivocation with equivocation.height > best_block.height + 28 * blocks_per_era, which could only be reported & slashed on Polkadot/Kusama after the equivocators could already unbond. We may want to add a is_block_within_current_era(commitment.height) check on the ETH side regardless to avoid bricking the bridge forever in case of an attack with equivocation.height >> best_block.height, but other BEEFY clients may not perform such a check, so I prefer slashing eagerly to discourage the attack even if the ETH bridge's light client may be unaffected.

A. current implementation

The following cases are handled:

1. equivocation.height < best_block.height - 4096 => ancestry proof
2. best_block.height - 4096 <= equivocation.height => header proof (+ optionally ancestry proof, in case the proof is only processed once header proof goes out of scope)
3. best_block.height < equivocation.height => just check that commitment is signed

As such, a ForkEquivocationProof has both the ancestry proof and the header proof optional:

pub struct ForkEquivocationProof<Number, Id, Signature, Header, Hash> {
	pub commitment: Commitment<Number>,
	pub signatories: Vec<(Id, Signature)>,
	pub correct_header: Option<Header>,
	pub ancestry_proof: Option<AncestryProof<Hash>>,
}

B. alternative implementation

I am considering changing the handling to

1. equivocation.height < best_block.height - 2048 => ancestry proof + header proof of ancestry proof's mmr root
2. best_block.height - 2048 <= equivocation.height => header proof for mmr root of equivocation (2048 is equal margin)
3. best_block.height < equivocation.height => just check that commitment is signed

Which would result in the following proof struct

pub struct ForkEquivocationProof<Number, Id, Signature, Header, Hash> {
	pub commitment: Commitment<Number>,
	pub signatories: Vec<(Id, Signature)>,
	pub correct_header: Header,
	pub ancestry_proof: Option<AncestryProof<Hash>>,
}

where the correct_header serves different purposes depending on route B.1. or B.2.

The advantage of B against A is that in route B.1., ancestry proofs would remain valid if they are only processed in a block later than the one they were generated for, whereas in A.1. they are only in scope for the current block. The disadvantage is a more complicated proof structure, and it's not crystal clear to me that the advantage of B is important: it's irrelevant if the fisher is also the block producer, but would account for networking delays of other fishers.
Hence, I appreciate feedback on my reasoning here before implementing B.

[serban300]

We should check all the incoming justifications. Right now from what I understand we are missing the ones that come from the OnDemandJustificationsEngine.

See: #1903 (comment)

[acatangiu]

We should check all the incoming justifications. Right now from what I understand we are missing the ones that come from the OnDemandJustificationsEngine.

See: #1903 (comment)

Let's first focus on the runtime side, how equivocations are submitted, processed and punished - it is the most important piece.

We can continue the fisherman work subsequently.

[serban300]

We should check all the incoming justifications. Right now from what I understand we are missing the ones that come from the OnDemandJustificationsEngine.
See: #1903 (comment)

Let's first focus on the runtime side, how equivocations are submitted, processed and punished - it is the most important piece.

We can continue the fisherman work subsequently.

Ok. I just want to finish a PR related to the comment which shouldn't take long (today or Monday) and then will continue with the runtime side.

[serban300]

We should check all the incoming justifications. Right now from what I understand we are missing the ones that come from the OnDemandJustificationsEngine.
See: #1903 (comment)

Let's first focus on the runtime side, how equivocations are submitted, processed and punished - it is the most important piece.
We can continue the fisherman work subsequently.

Ok. I just want to finish a PR related to the comment which shouldn't take long (today or Monday) and then will continue with the runtime side.

It's not going as fast as I planned. Leaving here the branch where I started working on this:
https://github.com/serban300/polkadot-sdk/tree/beefy-equivocation-client
And I'll continue it later.

Prioritizing the runtime side for the moment.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6220033

[serban300]

Opened a separate PR for the runtime part. It starts from the high-level approach here, but it introduces some significant changes: #4522

[acatangiu]

Closed in favor of:

• Add generate and verify logic for AncestryProof #4430
• [BEEFY] Add runtime support for reporting fork voting #4522
• Beefy equivocation: add runtime API methods #4993
• Relayers to implement bridge BEEFY fork equivocation detection Snowfork/snowbridge#1260