Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Brainstorming about validator privacy #5
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:
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.
Great post. Some comments:
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.
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.
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:
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...