This post is about validator privacy in the Ethereum proof-of-stake world. Our aim is to protect the identity of block proposers against denial-of-service (DoS) attackers.
With this post, we hope to inform Ethereum validators about the threat of DoS attacks and help them gain resilience against them. We also hope to inform Ethereum consensus client engineers about the solution space around this problem.
What?
After we move to proof-of-stake, future block proposers will be known ahead of time. This allows attackers to DoS those proposers before they get the chance to propose.
A proposer that gets attacked before proposing does not gain block or fee rewards: Given that those rewards represent a big chunk of a validator’s total gains, such attacks can force validators to centralize by joining big validator pools and providers.
Why?
While DoS attacks against validators might initially seem pointless from an attacker’s perspective, there are actually ways to flip such attacks into monetary gain:
- An attacker opens a short position against ETH and then attacks block proposers while loudly claiming that Ethereum is broken, in an attempt to gain quick profit from the short position.
- An attacker who controls the next proposer in the list is incentivized to attack previous proposers to steal their transaction fees and MEV.
- An attacker can bias Ethereum’s randomness subsystem by DDoSing the right proposer at the right time.
Fortunately, there are ways to defend against such attacks.
How?
In an attack scenario, the adversary learns the IP address of a validator by crawling the P2P network while following that validator’s attestations. After the attacker learns the IP address of a validator, the attacker can start attacking the validator right before it proposes a block.
We present two approaches to solving this problem – a short-term approach that requires manual configuration by the validator’s operator, and a long-term approach that works without any configuration.
Sentry nodes (short-term)
The most basic practical solution to this problem is to employ a classic frontend/backend design; the Validator Client stays in the backend, whereas the frontend uses two separate Beacon Nodes (BN): one for publishing attestations and the other for publishing block proposals. By keeping those two Beacon Nodes independent and disconnected, the valuable proposing BN is kept hidden and well protected.
The obvious drawback of this approach is that the validator’s operator needs to configure this multi-beacon-node setup. They need to maintain separate machines for the beacon nodes and rotate the IP address of the block proposing BN periodically. While this might seem like minimal overhead to a tech-savvy person, it can be troublesome for less technical operators. Furthermore, even for technical operators, it can be hard to create a non-centralized version of this setup that does not rely on popular VPN/VPS providers.
The above setup has to be built into validator clients and exposed as part of their configuration interface. Since The Merge hasn’t happened yet, the attacker incentives are much lower, and hence clients don’t yet support this functionality. As the Merge comes closer, we encourage client teams to support this sentry-node feature to not only protect individual validators but the network as a whole.
Vouch
Alternatively, even if a client does not support this functionality, we can build a dummy BN proxy, which acts as a regular BN as far as the VC is concerned, but instead transparently routes the requests from the VC to frontend BNs depending on whether they are attestations or proposals. Such an architecture is fully supported by the current beacon API.
This is actually close to how the vouch project works and it’s currently possible to configure it to support various types of sentry-node architectures.
Single Secret Leader Election protocols (long-term)
While the sentry node approach is a decent and pragmatic solution to the DoS problem, it also increases the infrastructure complexity and maintenance costs of validators.
For this reason, we plan to eventually enshrine validator privacy into the core Ethereum protocol.
At the moment we are exploring protocols based on verifiable shuffling, on VRFs, and on other networking approaches.
However, most of these approaches involve modifying Ethereum’s consensus layer and that’s a procedure that requires careful security analysis and significant engineering efforts.
Keep checking our research portal for the latest updates in this line of work.
Conclusion
We hope this post was informative to you; especially if you happen to be a home staker or plan to become one. In preparation for The Merge, we would suggest you keep in mind the DoS resilience of your validator so that you can keep the Ethereum network safe and sound 
If you are already protecting your validator from DoS attacks using vouch or any other approach, we would love to learn more in the comments section.
Cheers!