Brainstorming about validator privacy

[jannikluhn]

Preface: I'd like to apologize in advance for the lack of structure in this post. This pretty much reflects my state of mind on that topic which is one of the reasons why I wrote this down. The main reason though is to get some discussion started. So I'm looking forward to hear some thoughts of yours on this topic!

Validators keep the network alive and safe. Attackers might therefore target them to bring them down, to decrease the quality of their service, or simply to increase upkeep costs, discouraging them and others from staking.

As attacks on individual nodes (in particular DoS attacks) are pretty much impossible to prevent, we have to resort to just ensuring that validators are hard to be identified as such. Ideally, attackers can then only attack a random sample of nodes in the network which hopefully is not cost effective assuming the network is large enough.

However, perfect privacy is probably at least hard to achieve. We should come to an agreement about what level of privacy is acceptable. Here are some ways one might be able to identify validators:

• Depending on the discovery mechanism, validators might advertize themselves explicitly. That would be quite stupid, though.
• If (as part of the discovery mechanism) all nodes announce the shard they are watching, an attacker could keep track of the nodes that jump shards regularly. This would give a pretty accurate list of all validators, and even allow mapping specific addresses to endpoints (I'm not sure how useful this would be, though).
• Attesters can potentially be identified by their unique syncing strategy: When normal nodes join a new shard, they download the complete history, presumably from genesis to the current block. They also might attempt to retrieve the current state as quickly as possible (i.e. via fast or warp sync strategies or by requesting light client proofs until they have completed their sync). Attesters, on the other hand, download only the recent history, starting from the current block going backwards in time. They also don't care about state at all. This distinguishes them, but only towards their direct peers, not the whole network. If we assume that only a small fraction of the nodes in the network is malicious this might be ok (do we agree on this?).
• Even worse, attesters might want to explicitly tell their peers that they are a validator to get preferential treatment. This could reduce the time it takes to connect to a new shard and start windback.
• Proposers act pretty much in the same way as normal full nodes, except for the fact that they publish a new block from time to time. However, this is similar to miners today who do not seem to be attacked very often (I'm lacking data here, though, and as they have pretty expensive setups by nature they probably employ sophisticated defense mechanisms). There's also some degree of plausible deniability here as they can claim that they have received the block from another peer. So I don't think they risk a lot.
• Signature aggregators. This depends on the concrete protocol though, and I'm not up to date on that. Would be great to get some input on that from an expert!

One should also point out, that a validator might be represented by multiple endpoints. First, this improves security, as if one node is brought down a validator could simply switch to a surrogate. It also improves privacy as different actions of a validator can be delegated to different nodes and attackers can't easily connect those. However, if we expect validators to run in such a setup, we increase setup and maintenance costs substantially. Just downloading a docker image and putting it on a VPS would not be an option anymore.

As a security measure, we could also have centralized fallback nodes with good DDoS protection that validators could connect to in case they are attacked individually. Similar to slashing, this is not something that would be used in practice, but rather be something that discourages attacks on few individual, weakly protected validators.

[arnetheduck]

Also in the brain dump category: one potential starting point for attacking this would be ensuring that all messages that travel in the system are idempotent - this would keep the door open for future redundant / HA setups at least

[nkeywal]

Great post. Some comments:
In v2 we have less nodes per shard. If we say that we have 200 nodes + 300 validators for a shard, then if we attack a random node we have 3/5 to be right. So if we want to DoS 30 attesters we just have to DoS 50 nodes. Not that easy (and likely not enough to be useful) but not that impossible.

Proposers. [...] similar to miners today who do not seem to be attacked very often (I'm lacking data here, though, and as they have pretty expensive setups by nature they probably employ sophisticated defense mechanisms).

I think it's a key point: the ~15 miners we have today can spend a lot of money/time on defense; but the thousands of validators we will have on eth v2 will have less rewards and so time to spend on their defense.

One should also point out, that a validator might be represented by multiple endpoints.

If establishing a communication is cheap, then the validator could have a strategy of having a read-only public node to receive the transactions & blocks, and then use different ip address (or addresses) to send attestations & blocks. These ip addresses and servers could be quite ephemeral. Still it's expensive & complex. The ideal solution would be to have enough validators to be sure that a DoS attack is not practical (slashing would still be a problem though...)

A related topic is the possibility to have self-selected committee/block producers: when the attackers learns who is the block producer for this slot it's too late to start the attack, the block is propagating already.

[MihailoBjelic]

A related topic is the possibility to have self-selected committee/block producers: when the attackers learns who is the block producer for this slot it's too late to start the attack, the block is propagating already.

I guess this would be the most elegant solution in a sense that there are no anti-DoS requirements/hustle for validators (VPS + docker image does the job).

"All" that is left is to answer two questions:

1. How sound are these Algorand-like self-selection methods?
2. How hard/challenging are they to implement?

[nkeywal]

1. How sound are these Algorand-like self-selection methods?
   The description I have is here (paper by Micali): https://arxiv.org/pdf/1607.01341v1.pdf
   It's a probabilistic selection. Here is a high level simplification: if you want to select 10% of the validators set, each possible validator signs a given number, then map the signature to a real number between 0 and 1. If this final number is below 0.1, you're selected, and you can prove it by publishing your signature.
   So it's problematic if you want to select just a few validators, not to say exactly 1. In the FAQ algorand says they have 20 block producers, it's not a small number.
   As well the hard part is to chose the "given number" to sign. As I understand the paper, it's leader based, so it could be problematic again (synchronicity assumption to study / leader could choose not to participate / other nodes to pretend they didn't hear about the leader) . For this reason I would answer "it's hard" to your second question :-)

I don't think it's a lost fight however. May be a better solution exists. Or the trade offs are acceptable / better than the rest. More discussion is needed here. I like to have multiple block producers anyway.

I also found a side effect: if you don't participate it's more difficult to slash you because nobody knows you were selected. So if we want to slash non participants we need to add another step to the protocol, a kind of "proof of non selection".

Last point: the paper from Micali mentions several patent applications. I don't know what are the implications. The mechanism is not that complicated and I don't know if the idea itself is that new, but I didn't check and I'm not a lawer...