Broadcast blobs early with broadcast_validation=consensus

[michaelsproul]

Description

I was chatting to one of the relay devs and they noted that Prysm now has an endpoint for just publishing blobs:

https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/rpc/prysm/beacon/handlers.go#L189

The idea behind the endpoint is that it allows relays to start broadcasting blobs to the network in advance of the block being fully validated and broadcast. This hopefully makes blocks available earlier and less subject to reorgs/missed attestations.

The relay devs asked if we could add the same API to Lighthouse, but I would prefer not to add another non-standard API if we can use an existing one.

One way to do it might be to modify the publish_block endpoint to broadcast blobs immediately after gossip verification even if the broadcast_validation mode is set to consensus or consensus_and_equivocation.

I think we just need to carefully consider the security implications of broadcasting blobs for an unverified block. If we don't consider blob data to be subject to unbundling attacks (i.e. blob data is public, and contains no MEV), then I think we're OK. If blob data is considered private or could contain MEV, then broadcasting blobs early can lead to an attacker unbundling the blobs:

1. Attacking proposer requests a header from the relay and receives a header for exec_block_1 with KZG commitments for blobs blobs_1.
2. Attacker builds an invalid beacon block containing the header for exec_block_1 and returns it to the relay for publication. The beacon block can be made invalid through inclusion of invalid attestations.
3. The relay's beacon node validates the blobs blobs_1, which are gossip valid, and broadcasts them to the network.
4. The relay's beacon node validates the beacon block, and finding it to be invalid, aborts publication (due to broadcast_validation=consensus).
5. The attacker receives the full blobs on gossip (broadcast in step 3) and builds a second block block_2 containing these blobs and a different execution payload (they can't steal exec_block_1 because it was never revealed).
6. The attacker's block is accepted by the network because: its blobs are available, it is the first valid block received for the slot.
7. The attacker gets slashed because they signed equivocating headers.

If the cost of getting slashed exceeds the profit from unbundling blobs, then this attack isn't worth doing. I suspect this is the case at the moment, but may not be true forever.

Rather than modifying the behaviour of the existing broadcast_validation modes we could add a flag or another mode to opt in to the early broadcast behaviour.

Alternatives

Alternatively, we can do nothing and hope that the optimisations involving getBlobs are sufficient to improve blob propagation across the network. The only case where this optimisation would offer benefit over the mempool approach is in the case of private blob transactions, and arguably this is also the case where it is least secure (subject to unbundling).

The engine_getBlobsV1 changes are implemented in this PR and should be in v6.0.0:

• Improving blob propagation post-PeerDAS with Decentralized Blob Building #6268