Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue

TL;DR

The paper reveals a privacy flaw in Ethereum's P2P gossip network, showing that validators can be deanonymized by observing attestation propagation. It introduces a low-cost heuristic-based method to link validators to hosting peers, validates it with measurements from multiple Rainbow nodes over several days, and links roughly a fifth to a quarter of validators to hosting nodes after filtering out service providers. The study underscores significant decentralization and resilience implications, including clustering of validators on cloud providers and cross-pool dependencies, which may threaten liveness and safety if large nodes fail. It further discusses mitigations, such as expanded subnetting, private peering, and advanced DVT/privacy techniques, to curb the deanonymization risk and improve network privacy and robustness.

Abstract

Many blockchain networks aim to preserve the anonymity of validators in the peer-to-peer (P2P) network, ensuring that no adversary can link a validator's identifier to the IP address of a peer due to associated privacy and security concerns. This work demonstrates that the Ethereum P2P network does not offer this anonymity. We present a methodology that enables any node in the network to identify validators hosted on connected peers and empirically verify the feasibility of our proposed method. Using data collected from four nodes over three days, we locate more than 15% of Ethereum validators in the P2P network. The insights gained from our deanonymization technique provide valuable information on the distribution of validators across peers, their geographic locations, and hosting organizations. We further discuss the implications and risks associated with the lack of anonymity in the P2P network and propose methods to help validators protect their privacy. The Ethereum Foundation has awarded us a bug bounty, acknowledging the impact of our results.

Figures (12)

• Figure 1: The graph $\Pi$ depicts the peering connections maintained by nodes. $Agg$ depicts the subgraph along which aggregations and blocks are propagated. It contains the same vertices as $\Pi$ with fewer edges. $S_0$ to $S_{63}$ depict the subnets and their associated subgraphs where attestations are propagated. By default, nodes randomly select two subnets to participate in.
• Figure 2: Attestations received from a peer over a four hour window, where the vertical axis corresponds to the 64 subnets. We identified four validators hosted on the machine, represented in red, blue, yellow, and green. The attestations by the remaining validators are shown in pink. Note that we have anonymized the full IDs of the identified validators, but emphasize that the IDs of these four validators are sequential. For the identified validators, we receive attestations from a wide variety of subnets. In contrast, the attestations from the remaining validators primarily come from the two subnets the peer predominantly serves (i.e., subnets 12 and 13), evidenced by the repeated flow of attestations for these subnets (see the long pink strip), as well as from short dynamic subscriptions (see the smaller pink horizontal strips).
• Figure 3: Reachable Beacon network nodes discovered in our crawls over our measurement period.
• Figure 4: Number of peers each of our Rainbow nodes is connected to over time. On average, the VA node is connected to 645 peers, ZH is connected to 537 peers, FR is connected to 369 peers, and SO is connected to 338 peers.
• Figure 5: The cumulative number of peers each of our Rainbow nodes connected to over time, as well as the cumulative count across all.