Slashable message propagation post-deneb

[realbigsean]

The existing gossip rules mean we can propagate two (or more) slashable messages so long as they are not both blocks, or both sidecars of the same index. I don't think this is necessarily a bad thing in itself but I do think it makes things unnecessarily more complicated in implementation.

This has implications in the block production endpoint for example:

https://ethereum.github.io/beacon-APIs/#/Beacon/publishBlockV2

According to existing rules, clients should return 202 and publish (if broadcast_validation = gossip) when receiving a message consisting of a block and a blob sidecar containing a slashable block header, even though this is immediately identifiable as slashable.

Related to this, the existing rules force clients to build caches tracking slashability not just across all block components (which clients must in slasher implementations and also to support broadcast_validation = consensus_and_equivocation), but also at lower levels of granularity (blob index and message type). For example we have to differentiate between the following scenarios when signed_header_a and signed_header_b are slashable:

Scenario 1

Message 1: (signed_header_a, blob_index_1)
Message 2, not propagated: (signed_header_b, blob_index_1)

Scenario 2

Message 1: (signed_header_a, blob_index_1)
Message 2, propagated: (signed_header_b, blob_index_2)

The suggestion here is to split the blob gossip rule related to slashability into two rules, one that's just about de-duplication, and one that's related to slashability more generally. And to add a general slashability rule to block gossip.

[djrtwo]

I would only do this if you have sent or have seen a slashing message on gossip related to this. Otherwise, this could artificially prevent slashers from getting it!

I think we've talked about things directionally like this in the past but not integrated. One reason might be the implication of having to track "slashable" which not all clients have that notion beyond the external slasher. Obviously with blocks, it's a bit of an easier map than getting surrounds for attestation. But moving the condition to be "seeing or sending a slashing related to this" makes it less important that each client is a baseline double-block slasher

[realbigsean]

I would only do this if you have sent or have seen a slashing message on gossip related to this. Otherwise, this could artificially prevent slashers from getting it!

Do you mean with regard to the publish in the beacon API? I guess still publishing even if its slashable is reasonable, but I don't see how it'd be beneficial to the network. Maybe punishing one bad actor, but on the other hand if the block was never published they didn't do any damage.

But moving the condition to be "seeing or sending a slashing related to this" makes it less important that each client is a baseline double-block slasher

To try to keep it in this direction we could do something like this:

- _[IGNORE]_ The sidecar is the first sidecar for the tuple (`hash_tree_root(block_header)`, blob_sidecar.index) with valid header signature, sidecar inclusion proof, and kzg proof.
- _[IGNORE]_ The sidecar's block header is the first with valid signature received for the proposer for the slot block_header.slot.

This gets rid of the quirky scenario in the PR description. But we do still need to separately track slashing with blocks and blobs. I think tracking a single idea of a "slashable block" is still very simple. But I guess technically you could get away with fewer caches if you didn't care about slashability anywhere else.

[terencechain]

Side note: The second condition constrains the client to perform a slashing check at the gossip layer, which some implementations may not support today

[arnetheduck]

I've been thinking about this in the opposite direction: that we should propagate slashable messages - this enables them to reach a slasher, which makes the mechanism more fair (and potent) and removes a cache rule that otherwise clients have had problems with.

[djrtwo]

that we should propagate slashable messages - this enables them to reach a slasher, which makes the mechanism more fair (and potent) and removes a cache rule that otherwise clients have had problems with.

so my suggestion tries to find the best of both world -- you don't drop/IGNORE on slashable, you ignore if you seen or created a slashing for that validator (or maybe honed in on slot) on gossip. Thus you get to anti-dos as long as you or someone else has raised the alarm to the network -- trading N potential DoS messages for a 1 slashing message

[ppopth]

I also would like the slashable messages to reach the slasher.

I guess still publishing even if its slashable is reasonable, but I don't see how it'd be beneficial to the network. Maybe punishing one bad actor, but on the other hand if the block was never published they didn't do any damage.

They actually do some damage. If you don't forward the slashable blocks, the views can be split across the network.

Let's say the proposer proposes two slashable blocks: block1 and block2. If the nodes don't forward a block when they have already seen the other one, half of the nodes in the network will have only block1 in their view and the other half have only block2 and the network is now split. I think it's better to have all the nodes have both blocks in their views since both of the blocks are already published.

Please let me know if there is anything I misunderstood.

[ppopth]

I don't quite understand this one. How can the block be slashable while it's the first block with valid signature received for the slot.

[ppopth]

Adding #3257 for reference

[djrtwo]

If the nodes don't forward a block when they have already seen the other one, half of the nodes in the network will have only block1 in their view and the other half have only block2 and the network is now split.

Just because messages don't make it there on the gossip, does not mean messages don't make it to all peers eventually due to message-dependency lookup filled by req/resp.

E.g. if you didn't get a block on gossip, but get attestations about that block, you'll look up the dependency from your neighbors

There is a trade-off between preventing short-term view splits and hardening the gossip to an adversary that is willing to be slashed.