Store equivocating blocks on disk

[paulhauner]

Issue Addressed

NA

Proposed Changes

Stores RepeatProposal blocks on disk if the --invalid-gossip-verified-blocks-path flag is provided.

We only store these blocks when they're received on gossip or are the result of a block lookup via RPC. Duplicates received via a batch sync won't be stored on disk. This is primarily for simplicity; we should see the blocks via gossip or on an RPC lookup if we're following the head. This feature is a debugging assistance tool, rather than a surefire way to catch slashings (use a slasher for that).

Additional Info

NA

[paulhauner]

I'm tempted to gate this feature behind another flag. There's a DoS opportunity here since we'll determine a RepeatProposal based on the block.proposer_index without checking the signature (i.e., any old fool can make us think there's been an equivocation).

Peer scoring should eventually ban peers sending us RepeatProposal blocks, but that's an imperfect safeguard.

[jmcph4]

Just noticed this while going through the queued 4.3.1 changes; a few things to note after #4316:

Peer scoring should eventually ban peers sending us RepeatProposal blocks, but that's an imperfect safeguard.

• BlockError::RepeatProposal is now BlockError::Slashable

lighthouse/beacon_node/beacon_chain/src/block_verification.rs

Lines 280 to 286 in 8e65419

	/// The block is a slashable equivocation from the proposer.
	///
	/// ## Peer scoring
	///
	/// Honest peers shouldn't forward more than 1 equivocating block from the same proposer, so
	/// we penalise them with a mid-tolerance error.
	Slashable,

• Peers are downscored with a MidToleranceError for submitting equivocating blocks

lighthouse/beacon_node/network/src/beacon_processor/worker/gossip_methods.rs

Lines 794 to 799 in 8e65419

	/* punish peer for submitting an equivocation, but not too harshly as honest peers may conceivably forward equivocating blocks to us from time to time */
	self.gossip_penalize_peer(
	peer_id,
	PeerAction::MidToleranceError,
	"gossip_block_mid",
	);

[michaelsproul]

To add to what Jack said, this statement is no longer true since the changes we made in #4316:

There's a DoS opportunity here since we'll determine a RepeatProposal based on the block.proposer_index without checking the signature (i.e., any old fool can make us think there's been an equivocation).

We removed the early/read-only equivocation check, because it caused the BN to forget about equivocations it had seen. Now it only returns an equivocation error (Slashable) after checking the sig

[paulhauner]

I'm pushing this to the next release since there doesn't seem to be much demand and I don't have much bandwidth.

[pawanjay176]

Pushed this to 5.2.0 as it doesn't seem urgent, feel free to revert if needed