URL Inspection Tasks: Helping Users Detect Phishing Links in Emails

Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue

Speakers: Lioba Heimbach (ETH Zurich), Yann Vonlanthen (ETH Zurich), Juan Villacis (University of Bern), Lucianna Kiffer (IMDEA Networks), Roger Wattenhofer (ETH Zurich)

Conference: USENIX Security

Paper page: https://www.usenix.org/conference/usenixsecurity25/presentation/heimbach

Overview

This research paper, presented at USENIX Security, unveils a critical privacy vulnerability within the Ethereum peer-to-peer (P2P) network. Authored by a team of researchers from ETH Zurich, University of Bern, and IMDEA Networks, the work demonstrates that the Ethereum P2P network, despite aims for anonymity, fails to adequately protect the identity of its validators. The core finding is a novel methodology that allows any node in the network to link a validator's unique identifier to the specific IP address of the machine hosting it.

The significance of this discovery is profound, exposing the Ethereum network to a range of potential security and privacy risks. By deanonymizing validators, an adversary can identify nodes responsible for critical consensus duties, particularly those assigned to propose new blocks. This knowledge opens avenues for targeted attacks such as Denial-of-Service (DoS) or Border Gateway Protocol (BGP) hijacking, which could disrupt block finalization, compromise network liveness, or even threaten the safety of the blockchain by enabling sophisticated time-bandit attacks. The Ethereum Foundation acknowledged the impact of these results by awarding the researchers a bug bounty, underscoring the severity of the identified privacy flaw.

Background

Ethereum operates as a Proof-of-Stake (PoS) blockchain, consisting of a consensus layer (Beacon chain) and an execution layer. Participants can become validators by staking 32 ETH, taking on duties such as proposing new blocks, attesting to block correctness, and aggregating attestations. Validators are identified by an ID linked to a public/private key pair, with their logical entity hosted on a validator client. This client then interacts with the rest of the network through a consensus node, which manages its own identity (public/private key pair, IP address, port number) shared via Ethereum Node Records (ENR). Crucially, a single node can host multiple validators, or none at all, maintaining a separation for security reasons.

The Ethereum P2P network facilitates the exchange of essential messages like blocks, attestations, and attestation aggregations. Given over one million active validators, it's impractical for every validator to broadcast every attestation to all nodes. To scale, Ethereum employs several optimizations. Validators attest only once per epoch (32 slots), reducing the frequency of votes. Attestations are further divided into 64 committees, each assigned to a specific attestation subnet (or topic). Aggregators within each committee collect and combine attestations into a single aggregated BLS signature. Message sharing uses GossipSub, a probabilistic broadcast protocol. Nodes typically subscribe to two subnets as "backbones" for static duties, and can dynamically subscribe to others as needed. When a validator signs an attestation, its connected consensus node publishes it to the corresponding subnet by sending it to a subset of its peers (its fanout). The sending node doesn't necessarily need to be subscribed to that subnet itself, as committee assignments change frequently. This intricate system, designed for efficiency and scalability, inadvertently creates the privacy vulnerability explored in this paper.

Key Findings

The research presents several critical findings that collectively expose and quantify the privacy issues within the Ethereum P2P network:

• Simple and Low-Cost Deanonymization Technique: The paper introduces a methodology that allows any node in the network to infer which validators are hosted on its connected peers. This technique solely relies on observing attestation messages received from peers, specifically identifying when a peer broadcasts an attestation from a validator that falls outside its declared subnet broadcasting responsibilities.
• Empirical Verification and Scale of Deanonymization: Through a measurement study using four observation nodes (RAINBOW nodes) over just three days, the researchers successfully located more than 15% of all active Ethereum validators in the P2P network. This translates to identifying 161,057 unique validators out of approximately one million.
• Concentration of Validators: The study revealed significant concentration of validators on specific peers. For instance, the researchers located over 19,000 validators on a single peer, highlighting a potential centralisation point. The cumulative distribution function showed that while 27% of peers host a single validator, 11% host more than 100, often in "round numbers" (e.g., 100, 250, 500, 1000), suggesting deliberate deployment strategies by large operators.
• Insights into Geographical and Organizational Distribution: The deanonymization technique provided valuable data on how validators are distributed globally and across hosting organizations. While roughly half of the deanonymized peers run on residential ISPs, approximately 90% of the located validators are hosted through cloud providers, with Amazon data centers alone hosting 19.07% of the validators. Europe hosts 70.90% of located validators, and the Netherlands 12.71%, despite the US having the largest number of deanonymized peers.
• Inter-Staking Pool Dependencies: The research uncovered that operators for different staking pools often run validators from multiple pools on the same physical machine. This creates undesirable dependencies and challenges the claimed independence and decentralization of these staking pools, especially given that the largest staking pool already controls nearly a third of the staking power.
• Bug Bounty Acknowledgment: The Ethereum Foundation awarded the research team a bug bounty, formally acknowledging the impact and validity of their results and the critical nature of the privacy vulnerability.

Technical Deep Dive

The core of the deanonymization methodology lies in exploiting a nuanced aspect of Ethereum's GossipSub attestation broadcasting mechanism. The fundamental principle is that nodes are only responsible for propagating a pre-determined subset of all attestations, corresponding to the two subnets they are statically subscribed to (their "backbones").

The key observation is as follows: if a peer p sends an attestation created by validator v that falls outside p's declared broadcasting responsibility (i.e., p is not a backbone for v's assigned subnet), then it can be inferred with high confidence that the attestation was produced by p itself. This is because p would typically only forward attestations from other nodes within its subscribed subnets. If p is sending an attestation from an unsubscribed subnet, and it's the first time the observing node hears about it from p, it strongly suggests p is the original source. Observing this behavior repeatedly for a specific validator v from a peer p allows the researchers to confidently link v to p.

To handle the imperfections of real-world network data (e.g., disconnections, dropped packets, dynamic subscriptions, nodes running non-default parameters), the researchers developed a heuristic deanonymization approach based on four conditions to filter peers and identify validator IDs:

• C1: Proportion of Non-Backbone Attestations: This condition requires that the proportion of non-backbone attestations received for a validator v from a peer p must exceed 0.9 * (64 - nsub(p)) / 64. Here, nsub(p) is the average number of subnets p is subscribed to over the connection's duration. This conservative threshold (90%) ensures that only peers providing a significant amount of "out-of-subnet" attestations are considered, reducing false positives.
• C2: Not Subscribed to All 64 Subnets: The peer p must not be subscribed to all 64 attestation subnets. If a peer is subscribed to all subnets, it would be responsible for propagating all attestations, rendering the "non-backbone" distinction meaningless for deanonymization.
• C3: Minimum Expected Attestations: The observing node must receive at least one-tenth of the expected attestations for validator v from peer p. This ensures that the connection to p is stable and provides sufficient data for analysis, filtering out noisy or fleeting connections.
• C4: Attestation Count Exceeds Mean + Standard Deviation: The number of attestations received for validator v from peer p must exceed the mean number of attestations per validator from p by one standard deviation. This condition helps to disregard peers exhibiting rare, non-default broadcasting behavior that might otherwise be misinterpreted.

By participating in all subnets, the observing node (their RAINBOW node) increases its chances of being added to a peer's fanout for various subnets, thus maximizing the data received for analysis. The assumption underlying this approach is that a peer will be the first to report its own attestations to its connected nodes, especially those in its fanout. This methodology allows for the robust identification of validators hosted on specific IP addresses, even in a dynamic and often imperfect network environment.

Demo / Proof of Concept

While there was no live "demo" in the traditional sense of a conference talk, the research paper rigorously validated its deanonymization methodology through a comprehensive measurement study and data collection process, effectively serving as a proof of concept.

The researchers developed a custom listening node implementation, dubbed RAINBOW, based on the widely used Prysm client (the most prevalent Ethereum consensus layer client). RAINBOW was modified to connect to up to 1,000 peers and statically subscribe to all 64 attestation subnets. This allowed it to maximize its view of network traffic and attestation origins. Three instances of RAINBOW were deployed on AWS r5a.4xlarge machines in different data centers (us-east-1/VA, eu-central-1/FR, ap-northeast-2/SO), and one on a bare-bones server in Zurich (ZH).

Over a three-day period (May 7-10, 2024), these four RAINBOW nodes collected approximately 700 GB of compressed network-layer message data, logging all attestations, their origins, and subnets. They also recorded advertised static subscriptions of peers and precise connection data. The nodes successfully established long-term connections (over 32 epochs, or ~3.4 hours) with 4,372 unique peers, representing roughly half of the reachable Ethereum network. The VA node maintained the highest average peer count (645), followed by ZH (537), with FR and SO having lower counts (369 and 339, respectively).

Applying their heuristic approach, the researchers categorized the connected peers:

• Deanonymized: 52.35% of peers overall had validators successfully located on them.
• No Validators: 37.52% of peers were confidently identified as hosting no validators.
• 64 Subnets: Only 0.69% of peers subscribed to all 64 subnets, making deanonymization impossible via this method.
• Rest: 9.46% of peers fell into a "grey area" where some non-backbone attestations were observed, but not enough to meet the conservative deanonymization criteria.

Over the three days, the RAINBOW nodes cumulatively deanonymized 252,895 validators. After excluding 17 identified P2P service providers (e.g., bloXroute), which disseminate messages for many validators but don't host them, the total number of unique validators definitively located was 161,057 – over 15% of the entire Ethereum validator set. The ZH node alone deanonymized 132,443 of these.

To verify the accuracy of their deanonymization, the researchers performed several checks:

1. Consistency of Validator Sets: 93.75% of the deanonymized peers hosted validator sets that were consistent with attributes like belonging to the same staking pool, funded by the same deposit address, using the same fee recipient address, or having consecutive validator IDs. This strongly suggests that the linked validators indeed belong to the same entity.
2. Uniqueness of Validator-IP Mappings: While 16,172 validators had non-unique IP mappings (meaning they appeared to be associated with multiple IP addresses), nearly three-fourths of these overlaps involved peers in the same city, indicating large entities using multiple machines for redundancy or privacy. Less than 1% of overlaps were minimal and potentially due to other factors.
3. Cross-RAINBOW Node Consistency: For 794 peers that were connected to by multiple RAINBOW nodes, 95.96% had the exact same set of validators identified by all connected RAINBOW nodes. The average overlap was 99.20%. This robust consistency across geographically distributed observation points provides strong evidence for the accuracy and reliability of the deanonymization technique.

Defensive Implications

The deanonymization of Ethereum validators in the P2P network presents significant security and privacy risks, necessitating robust defensive strategies. The paper outlines several threats and discusses existing and proposed mitigations.

Threats:

• Targeted (D)DoS Attacks: An attacker can identify the IP address of the node hosting the upcoming block proposer at least one epoch (6 minutes 24 seconds) in advance. A targeted DoS attack or BGP hijacking could temporarily sever the proposer's connection, preventing block submission within the critical four-second window. This could lead to the attacker, as the proposer of the subsequent slot, claiming higher Maximal Extractable Value (MEV) rewards by including transactions from the skipped slot.
• Compromised Liveness: Repeatedly preventing block proposers from submitting blocks could stall the blockchain. Even disrupting one in ten proposers would cause significant delays and instability. More severely, disrupting block propagation to over one-third of the network could prevent the finality gadget from gathering the required quorum, halting chain finalization.
• Safety Violations: By breaking synchrony assumptions through targeted DoS or BGP hijacking, an attacker could exploit optimistic light clients, causing conflicting blocks to appear finalized in different parts of the network, undermining chain integrity.
• Undermining Danksharding and Censorship Resistance: The lack of privacy could also undermine assumptions critical for future Ethereum upgrades like Danksharding and compromise the network's censorship resistance.

Proposed Mitigations:

1. Additional Subnets: Validators could be configured to take over backbone duties for more than the default two subnets. Subscribing to all 64 subnets would completely defeat the current deanonymization method. While this increases message complexity, the upcoming Pectra hardfork, which will increase the maximum effective balance to 2048 ETH, is expected to reduce the total number of attestations, potentially making a slight increase in P2P messages tolerable.
2. Additional Nodes: Validator clients could connect to multiple consensus nodes. For instance, one node could handle attestations and aggregations, while a separate, more protected node broadcasts block proposals. Alternatively, an entity could propagate attestations through multiple nodes to distribute the attack surface or cap attestation volume per node. However, this doesn't address the root cause, increases operational costs, and might be prohibitive for solo stakers.
3. Private Peering Agreements: Ethereum clients like Lighthouse and Prysm offer private peering, allowing trusted peers to act as additional relays. This could provide k-anonymity, making it harder to pinpoint a specific validator among k peers. However, k must be large enough, and finding trustworthy peers can be a challenge, potentially contributing to centralization.
4. Anonymous Gossiping: Protocols like Dandelion or Tor have been considered for anonymous message propagation. Dandelion, which propagates messages along a single-node path before broadcasting, incurs significant latency costs, making it incompatible with the need for rapid message publication in Ethereum's incentive structure.
5. Network Layer Defenses: Traditional DoS defenses like IP-based filtering, cloud-based protection, overprovisioning, and VPNs are generally insufficient for blockchain consensus algorithms, especially given Ethereum's size and the modest hardware requirements for solo stakers. While libp2p offers mitigations like rate-limiting, they are not expected to fully prevent targeted attacks. Source authentication and rate limiting, as proposed by Giuliari et et al., could be promising but require significant protocol changes.
6. Secret Leader Election (SLE): This is considered one of the most promising approaches. SLE protocols aim to keep block producers anonymous until they perform their duties, directly combating pre-emptive DoS attacks. While proposals exist, none have moved beyond the design stage for Ethereum.
7. Distributed Validator Technology (DVT): DVT splits a validator's private key across multiple clients, allowing the validator to remain operational even if some clients are unavailable. This resilience could help validators withstand DoS attacks and continue to create blocks, thus improving liveness.

The paper emphasizes that while some mitigations exist, many come with tradeoffs in cost, complexity, or network performance. The fundamental issue remains that the current GossipSub implementation, with its subnet overlay, inherently leaks information about validator locations.

Key Takeaways

• Ethereum P2P network leaks validator IP addresses: The current GossipSub protocol, specifically its attestation broadcasting mechanism and subnet division, allows an observer to link validator IDs to the IP addresses of their hosting nodes.
• Significant portion of validators deanonymized: A simple, low-cost technique successfully deanonymized over 15% of all active Ethereum validators (161,057 unique validators) using four observation nodes in just three days.
• Deanonymization poses serious security risks: Identified threats include targeted DoS attacks, BGP hijacking, and time-bandit attacks, which can compromise network liveness, safety, and extract MEV, potentially leading to significant financial losses or chain instability.
• Centralization risks highlighted: The study revealed high concentrations of validators on single peers (e.g., over 19,000 validators on one machine) and a heavy reliance on cloud providers (90% of validators). It also exposed inter-staking pool dependencies due to shared node operators on the same machines.
• Mitigations are complex and have tradeoffs: While several mitigations exist (e.g., additional subnets, multiple nodes, private peering, DVT, secret leader election), they often involve increased costs, complexity, or potential impacts on network performance, with no single easy fix.
• Urgent need for privacy-preserving solutions: The findings underscore the critical need for developing and implementing robust privacy-preserving mechanisms for the Ethereum P2P network to protect validator anonymity and enhance the network's overall security and decentralization.

About the Speaker(s)

The research paper "Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue" was authored by a collaborative team of researchers:

• Lioba Heimbach: ETH Zurich
• Yann Vonlanthen: ETH Zurich
• Juan Villacis: University of Bern
• Lucianna Kiffer: IMDEA Networks
• Roger Wattenhofer: ETH Zurich

These researchers contributed to identifying, analyzing, and proposing mitigations for the critical privacy vulnerability within the Ethereum P2P network. Their work has been recognized with a bug bounty from the Ethereum Foundation for its significant impact on blockchain security and privacy.