Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow slashable messages to propagate via gossip until slashing #3257

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

arnetheduck
Copy link
Contributor

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.

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.
@arnetheduck arnetheduck mentioned this pull request Feb 17, 2023
3 tasks
@potuz
Copy link
Contributor

potuz commented Feb 17, 2023

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
Copy link
Contributor

nisdas commented Feb 17, 2023

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.

@ethereum ethereum deleted a comment Feb 17, 2023
@djrtwo
Copy link
Contributor

djrtwo commented Feb 17, 2023

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants