EthStaker

Idea: Protecting Your Validator from Attacks During Block Proposal to Prevent MEV Theft

Recently, I read a paper on validator deanonymization (linked in the last comment).
TL;DR: An attacker could find the IP address used by your validator. Then, when you're about to propose a block with significant MEV (Miner Extractable Value), the attacker can launch a cheap DoS (Denial of Service) attack on your internet connection. You would miss the opportunity to propose a block. The attacker would then DoS the next validator and repeat this until their validator is selected. This would allow them to propose a block, essentially stealing your winning lottery ticket and grabbing all the MEV.

Privacy, security, cryptography.
Here is my blog:
https://blog.pawelpokrywka.com/

You'll be protected against DoS during block proposal.
You'll still be vulnerable to DoS during normal attestation, but this is acceptable. There are no economic incentives to attack you under normal circumstances.

I'd like to implement a tool to do this, but I probably won't have enough time, so I'm just posting the idea publicly.
If someone would like to implement it, there's one thing that needs research:
What happens to established connections when you close VPN ports? If they remain alive, then everything would work.
Otherwise, the node connectivity will be crippled, causing:
- Temporary problems for connected nodes
- Potentially prohibiting your node from proposing a block

Here's the mentioned paper:
https://www.arxiv.org/abs/2409.04366

Solo stakers are most vulnerable to these DoS attacks. My idea is to use a public VPN to combat this.
If you use a VPN, an attacker targeting your IP performs a DoS attack that stops at the VPN provider's infrastructure (which should be fairly resistant). Your internet connection should remain safe.

So far, so good. You're protected - unless you open your ports for incoming connections (which is encouraged because it helps the Ethereum network).
If you have your ports forwarded (some VPNs, especially torrent-friendly ones, allow this), the attacker could easily saturate your bandwidth by directing a DoS attack at those ports. The VPN won't protect you in this case.
Unless you implement this trick: The moment you know you're going to propose a block, close the VPN ports and re-open them right after the proposal.

Software developer and support. @ethStaker contributor. Ξthereum enthusiast. ⟠

Even though this attack has been theorized, we haven't seen it happen in the real world. You also have to include a potential loss of reputation for the attacker in this equation because this would be visible on the network.   Even though the severity of this is potentially big, the difficulty is high and it comes with a few other risks.

Regarding standarization of port forwarding, I found a nice project called Gluetun. It's a docker image allowing you to connect to any supported public VPN. It updates list of servers and abstracts away all provider-specific details. It allows to setup port forwarding - currently only for 2 providers - but I believe more providers could be added.

I believe the DoS issue will vanish with introducing of Secret Leader Election. However, we I'm not aware of any plans to introduce it in Pectra or Fusaka, so it may take some time.
https://ethereum.org/en/roadmap/secret-leader-election/

You mentioned Tor, so you may be interested in Nym mixnet. I follow this project for some time. There were some efforts to integrate it with libp2p. I don't know how it helps prevent DoS, probably have the same latency issues you mentioned, but from the privacy perspective seems very cool.

Regarding standarization of port forwarding, I found a nice project called Gluetun. It's a docker image allowing you to connect to any supported public VPN. It updates list of servers and abstracts away all provider-specific details. It allows to setup port forwarding - currently only for 2 providers - but I believe more providers could be added.

I believe the DoS issue will vanish with introducing of Secret Leader Election. However, we I'm not aware of any plans to introduce it in Pectra or Fusaka, so it may take some time.
https://ethereum.org/en/roadmap/secret-leader-election/

You mentioned Tor, so you may be interested in Nym mixnet. I follow this project for some time. There were some efforts to integrate it with libp2p. I don't know how it helps prevent DoS, probably have the same latency issues you mentioned, but from the privacy perspective seems very cool. https://github.com/ChainSafe/rust-libp2p-nym

Cool idea, but difficult because there is no standardization around APIs for port forwarding by VPN providers.
I think the endgame is to run validators over Tor and use a different Tor circuit for attestations vs block proposals. But with the trend of stakers' latency reqs, seems like swimming against the current.