Allow slashable messages to propagate via gossip until slashing

[arnetheduck]

When a validator signs multiple blocks / attestations, they may get slashed. However, current gossip rules actually prevent such messages from propagating through the gossip network due to "first message" validity conditions:

[IGNORE] The block is the first block with valid signature received
for the proposer for the slot, signed_beacon_block.message.slot.

https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beacon_block

Using block as example, this enables the proposer to send one block to some participants, the other block to the other participants and potentially create a temporarily split network where only "border" nodes see both: the IGNORE rule will prevent the propagation of either of the two blocks throughout the network and thus potentially prevent them from reaching slashers.

Further, the block will also be dropped at the libp2p gossipsub level - IGNORE messages are added to the gossipsub "seen" list which keeps track of hashes of messages seen (so they are dropped if seen more than once), but they are not added to the message cache which enables the secondary IHAVE/IWANT distribution mechanism of gossipsub.

Thus, the only way to observe the duplicate of a block is to observe a follow-up (such as an attestation, aggregate or child) and try to download it via ByRoot, hoping that a neighbour has seen it which is unlikely - this slow recovery mechanism may cause short-term disruptions in the network as peers strive to recover while more blocks get built on top of either of the two blocks or their parents.

It's important to note that the seen_ttl setting of gossipsub already ensures that we don't propagate the same message more than once - ie it's already not possible to spam the network by repeating an identical message over and over.

This change only covers slashable conditions - the "first-message" condition still applies to messages that don't carry slashing conditions (ie aggregates, sync committee messages etc) - for those, we hope that validators are honest in signing only one but should they choose to sign more than one, they cannot be used to DoS the network.

This rule also allows nodes to replace a block / attestation with a slashing message and propagate the slashing message instead of the offender and thus effectively represents a very similar IGNORE condition, albeit with more teeth.

[potuz]

My first initial thought is that this PR makes sense. Care must be taken to not process those messages that are now not ignored, perhaps this PR should include a message to that effect

[nisdas]

Allowing the message to be processed and propagated to other peers may cause issues. If instead of ignoring these messages, we now accept them and propagate them, it could lead to some weird cases with regards to forkchoice as we now process this double block from the malicious proposer. At least for us, accepting such a message would also necessitate us processing it and inserting it into our fork-tree.

This rule also allows nodes to replace a block / attestation with a slashing message and propagate the slashing message instead of the offender and thus effectively represents a very similar IGNORE condition, albeit with more teeth.

I think this might be preferable for us, if we detect that there has been a double proposal from the same proposer index and slot, we could drop the message and construct the slashing object and broadcast it.

[djrtwo]

This is a clever modification but I default to doing nothing unless we have evidence to show otherwise. This heightens the dependency on online and altruistic slashers while solving for a problem that does not yet have enough demonstrated evidence to surface is critical to solve

Thus, the only way to observe the duplicate of a block is to observe a follow-up (such as an attestation, aggregate or child) and try to download it via ByRoot, hoping that a neighbour has seen it which is unlikely

This is not the case for attestations and blocks, if a neighbor sends you a message with a dependency, they have the dependency or were not honest. Thus you have a very clear target on who to ask for.

By removing this condition we open ourselves entirely up to arbitrary dos unless we have not only an online but altruistic (and well functioning) set of slashers. We have no evidence that this condition as-sis can lead to persistent partitions and have a clear mechanism for subsequent messages to signal the value of messages (block and attestation dependencies).

I'm a on this unless we demonstrate via simulations that worrying network splits (beyond a slot, maybe two) can be easily performed in current method and show that this new method is reliably more resilient. Or if we show the new method reliably reduces the load significantly when under a block or attestation (slashable) DoS.

[arnetheduck]

We can also keep both conditions: IGNORE if either of "seen previous message" or "seen slashing" is true - this opens no new dos vectors but affords clients the option to slash-instead-of-propagate - ironically, the detection logic for dropping a non-first message is the same: the difference is you generate a slashing instead of ignoring it.