How I learned to stop worrying about the DoS and love the chain

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.


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.


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.


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.


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.


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 :slight_smile:

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.



Note that attesting on CLs A and B and proposing via CLs D and E is not currently supported by Vouch: It only has one submitter for everything. The strategies you see are actually selection strategies.

Jim McDonald had this to say about dDoS:
“Regarding DDOS, it isn’t so easy to stop a beacon node from broadcasting a single proposal so it’s more likely that an attack would attempt to overwhelm a node prior to the proposal, either through an eclipse attack or just DDOSing it a slot or two in advance so that the block it produces is ultimately orphaned. The way that Vouch could avoid that would be to have a node that is on the list of nodes from which it obtains proposal data, but not on the list of submitters. So there is always a “listen only” node that should be up-to-date when it comes to Vouch creating the proposal.”

This can be done in Vouch thusly:

Assume I have CL nodes A,B,C.
Use A,B for submitters
And A,B,C for all selection strategies
Even if A and B get attacked, C should still have the proposal ready, and keeping a node from actually submitting the thing is non-trivial


Note that as of Vouch 1.5.0 it is possible to have separate beacon nodes for submission of different types of information (attestations, proposals, sync committee messages etc.), which allows a beacon node to be used purely for broadcasting block proposals if so desired.

It also opens up the opportunity for there to be altruistic “public beacon nodes” that accept block proposals via the REST API from any source and broadcast them (assuming they meet validity requirements, of course), which would make DDoSing a validator very difficulty indeed.

1 Like