Validator Deanonymization on Ethereum’s P2P Network

Ethereum validators can be linked to specific IP addresses using only passive network observation of attestation subnet subscriptions. Research from ETH Zurich (Lioba Heimbach et al.) demonstrated deanonymizing ~16% of the observed validator set with three days of data from four nodes. This has direct implications for targeted MEV attacks, censorship resistance, and geographic concentration risk. (→ NoConsensus.wtf 2025 — Overview)

The Attack Setup

P2P node vs. validator: a P2P node (identified by IP:port) is distinct from a validator (identified by BLS key / validator index). A single node can run thousands of validators.

Attack surface — subnet subscriptions: at the Merge, Ethereum divided attestation propagation into 64 subnets to reduce message complexity. Each node subscribes to 2 randomly assigned subnets (rotating periodically). Validators with active aggregation duties generate additional subnet activity. Subnet subscription patterns are observable by any connected peer.

Attack: by tracking which nodes subscribe to which subnets when validators have specific duties, an attacker can correlate validator identities to node IPs. This requires no exploits — only passive observation of public P2P traffic.

Results (3 Days of Data, 4 Observer Nodes)

  • 160 validators deanonymized — approximately 16% of the observed validator set.
  • Conservative heuristics used; actual exposure is likely higher with more nodes or more time.

Structural Findings

Validator consolidation per node:

  • Most nodes run a handful of validators.
  • ~30% of nodes run >100 validators.
  • Maximum observed: 19,000 validators on a single machine — a single DDOS target can knock out 19,000 validators.

Staking pool consolidation:

  • Large staking pools (Lido, Rocket Pool, etc.) hire node operators.
  • Node operators run validators from multiple staking pools on the same machine.
  • This creates hidden cross-pool dependencies: a single machine compromise affects multiple nominally independent protocols.
  • Characteristic signature: “ladder effect” in CDFs — e.g., many nodes running exactly 1,000 validators (a configuration threshold).

Geographic concentration:

  • ~80% of deanonymized validators in US or Europe.
  • ~90% of nodes running via cloud providers.
  • Amazon (AWS) hosts ~20% of all validators identified.
  • Geographic clustering is predictable: observer nodes in Frankfurt and Zurich are best at deanonymizing European validators; Virginia-based observers are best for US.

Attack Implications

MEV-motivated targeting: Ethereum’s block proposal schedule is public and known slots in advance. An attacker who knows validator X’s IP and that validator X proposes the next block can:

  1. Execute a DDoS attack on validator X’s IP.
  2. Force validator X to miss its proposal.
  3. The attacker’s validator takes the slot and captures the MEV opportunity.

Coercion and legal attack: known validator IPs make legal coercion by state actors practical. This is the concrete version of Phil Daian’s “Ethereum go dark” concern (see Censorship Resistance in Consensus Protocols).

Mitigations

  • Split nodes by role: run one node for attestations (persistent), a separate unlinkable node for proposals (rarely active, harder to deanonymize). The proposal node generates insufficient traffic for the attack to succeed.
  • Private peering agreements: bypass public discovery, reducing observable subnet subscriptions.
  • Subscribe to all subnets: eliminates the distinguishing signal, but increases bandwidth load.
  • Accept non-anonymity + invest in DDoS defenses: if geographic distribution and uptime SLAs are strong enough, targeted attacks may not succeed.

Connections

Open Questions

  • Can Ethereum adopt subnet subscription randomization or anonymization without breaking the load-reduction benefits that motivated the 64-subnet design?
  • Does the MEV-motivated deanonymization attack need to be in the formal threat model for Ethereum’s P2P specification?
  • Would ePBS (removing trusted relays) reduce or increase validator IP exposure?
  • How quickly does deanonymization coverage grow with more observer nodes and longer observation windows?