Validator security discovery requirements

[FrankSzendzielarz]

I am collating requirements for the new Discovery spec, and adapting the spec to those requirements. The current link to the requirements is here , though that will be obsolete soon as I want to find that a GitHub repo home and open it to further stakeholders.

Right now the newest requirements I am addressing are related to validator security and validator transitions between shard subnets.

I am trying to understand a couple of things and need some help with the following:

a) What new requirements outside of those listed above do we need to consider for Eth 2.0
b )Is it a hard requirement that Discovery maintain Validator anonymity ?
c) Particularly attesters?
d) If so , during shard discovery what can prevent the following scenario:

Attack(?)

The following assumes that shards are discovered using discovery topics (currently unrelated to libp2p pubsub topics):

• A collective of malicious nodes occupy positions across all shards or many shards. The nodes need not be full nodes, merely implementations of parts of the networking stack.
• they wait for incoming connections
• and/or they wait for incoming discovery searches
• they collect IP endpoints from that incoming network traffic (set A)
• they are also searching all shard topics continuously for shard participants (set B)
• the complement of set B contains validators
• a single validator is identified and DoS'd until their Eth is slashed
• process repeats

Is this a valid scenario? If so, it does not require an attack on all identified nodes, merely one likely validator, repeatedly. This is enough to cause uncertainty and doubt about staking any further, limiting the pool of new validators joining.

What % of set A will be validators? Some, most, all? Will LES nodes always/usually join shards that they are interested in (eg: where a particular contract lives) or will they 'wander' across shards like attesters? What other types of activity will be included in set A that can mask the validators?

[jannikluhn]

a single validator is identified and DoS'd until their Eth is slashed

If I remember correctly, there were plans to make the leakage (which is a different mechanism than slashing) a function of the total number of offline validators, such that a single offline validator is punished only very little and only in case of a coordinated attack validators are punished hard. I don't remember any details about the timescales involved, but I suppose validators should have enough time to detect the attack and start a replacement node before the leakage hurts. Can you confirm this @djrtwo ?

What % of set A will be validators? Some, most, all?

I guess that depends on the number of non-validator nodes and the time a node is typically running. I don't think we know this.

Will LES nodes always/usually join shards that they are interested in (eg: where a particular contract lives) or will they 'wander' across shards like attesters?

I assume that they will typically stay on a single/few shards for long periods of time, so no wandering.

What other types of activity will be included in set A that can mask the validators?

Maybe already connected nodes could regularly change their peers, or at least ask for some. Then we would get some masking traffic in both set A and set B. Would consume some bandwidth though...

[fjl]

Repeating my answer from previous discussions: this attack works only if you assume that validators (more specifically: attester nodes) are the only ones not registering for a shard topic. This is is equivalent to the assumption that the discovery DHT will only be used by eth2.0 in the specific ways discussed so far. IMHO this assumption doesn't hold because discovery will be used for more than one purpose, so your complement of set B will be too large to meaningfully identify a particular node to attack.

[FrankSzendzielarz]

"because discovery will be used for more than one purpose" - yes that is the question ("What other types of activity will be included in set A that can mask the validators?") . Is this comprehensive enough:

1. Eth 1.X clients
2. Whisper
3. Swarm
4. Other networks, eg ETC

If this is the case long term it needs to be noted that as a security requirement the types of traffic and client need to be indistinguishable. It does feel still that a determined enough attacker could still make the effort and identify validators.

I suppose, as Jannik points out, the real mitigation is in making the 'leakage' slow enough that the DDoS effort would be too hard to have an impact even if the attacker did get the attester IPs.