No gossip validation before block broadcast

[michaelsproul]

Description

While working on the spec for broadcast_validation (ethereum/beacon-APIs#317) I realised that Lighthouse is in violation of the current spec:

Instructs the beacon node to broadcast a newly signed beacon block to the beacon network, to be included in the beacon chain. A success response (20x) indicates that the block passed gossip validation and was successfully broadcast onto the network. [emphasis mine]

Presently we don't do any verification of blocks before broadcast 👀 :

lighthouse/beacon_node/http_api/src/publish_blocks.rs

Lines 50 to 54 in 693886b

	// Send the block, regardless of whether or not it is valid. The API
	// specification is very clear that this is the desired behaviour.
	let message = PubsubMessage::BeaconBlock(block.clone());
	crate::publish_pubsub_message(network_tx, message)?;

Arguably this isn't so bad, as the gossip validation would mostly protect the proposer from publishing junk to the network which would reduce their peer score. Given that the beacon node HTTP API is assumed private, an attacker would need access in order to trick the BN into publishing junk. I don't think this poses a significant risk beyond the risk already posed by unfettered access to a beacon node's API.

Steps to resolve

We could do nothing, or we could add gossip validation in the process of implementing broadcast_validation.

There are potentially interactions with the gossip seen cache which could be beneficial. The handling of duplicates and slashable blocks would require special consideration.

Version

Lighthouse v4.1.0

[eserilev]

would it be enough to check if is_optimistic_or_invalid_block returns false before broadcasting the block to the network?

[michaelsproul]

@eserilev No because that will only return a result for blocks that are already imported, and we need to check the block prior to it being imported

I think we'd need to form a GossipVerifiedBlock for the block before broadcasting it, and then import this after broadcast.

@jmcph4 is working on broadcast_validation currently, so might make sense to handle it in his PR

[michaelsproul]

Closed by #4316