-
Notifications
You must be signed in to change notification settings - Fork 0
Description
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.