1. Bibliographic Information

1.1. Title

Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue

1.2. Authors

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

1.3. Journal/Conference

The paper is listed as a preprint on arXiv (arxiv.org). While it is not explicitly stated as published in a journal or conference, the acknowledgments thank "anonymous USENIX Security 2025 reviewers," indicating it has been submitted or accepted for publication at the USENIX Security Symposium, a highly reputable and influential conference in the field of computer security.

1.4. Publication Year

The paper was published on arXiv on September 6, 2024.

1.5. Abstract

This research demonstrates a significant privacy vulnerability in the Ethereum Peer-to-Peer (P2P) network, specifically the inability to preserve the anonymity of validators. The authors introduce a methodology that allows any node in the network to identify validators hosted on connected peers by analyzing attestation messages. Through an empirical study using data collected from four nodes over three days, they successfully located over 15% of all Ethereum validators. The deanonymization technique provides insights into the distribution, geographical locations, and hosting organizations of these validators. The paper discusses the security implications and risks, such as Denial-of-Service (DoS) attacks, potential liveness/safety compromises, and concentration of power, and proposes mitigation strategies for validators. The Ethereum Foundation acknowledged the impact of these findings by awarding the authors a bug bounty.

1.6. Original Source Link

https://arxiv.org/abs/2409.04366v2 (Preprint) PDF Link: https://arxiv.org/pdf/2409.04366v2.pdf

2. Executive Summary

2.1. Background & Motivation

The Ethereum blockchain, a Proof-of-Stake (PoS) network, aims for decentralization and accessibility for many participants. A core tenet of many blockchain networks, including Ethereum, is to preserve the anonymity of validators within their peer-to-peer (P2P) network. This means preventing adversaries from linking a validator's unique identifier (a validator ID) to the specific IP address of the machine (the peer) hosting it. This anonymity is crucial for both privacy and security, as exposing validator IP addresses can lead to targeted attacks.

The core problem the paper addresses is the failure of the Ethereum P2P network to offer this desired anonymity. This is particularly important because recent scaling solutions implemented in Ethereum, designed to manage the large number of validators and extensive message exchanges, have inadvertently created a vulnerability. These solutions, while improving network efficiency, have made it possible to deanonymize validators.

This problem is highly significant because the lack of anonymity introduces major security risks. An adversary who can link validator IDs to IP addresses could:

1. Target specific validators: Launch Denial-of-Service (DoS) attacks against validators set to propose new blocks, potentially halting chain progress or enabling malicious actors to "scoop" high-value block rewards (a form of Maximal Extractable Value, or MEV).

2. Compromise network liveness and safety: Repeatedly disrupting block proposers could stall the blockchain, and if over one-third of the network is affected, it could prevent finalization of blocks, threatening the blockchain's liveness. More severe attacks, breaking synchrony assumptions, could even lead to safety violations where conflicting blocks appear finalized.

3. Undermine decentralization: The ability to observe validator distribution and concentration reveals vulnerabilities in the network's decentralization, especially concerning large staking pools and their node operators.

   The paper's entry point is to demonstrate how current broadcast implementations, specifically those related to attestation messages, create a side-channel for deanonymization. Nodes are only responsible for propagating a subset of attestations. If a peer sends an attestation that falls outside its normal broadcasting responsibility, it strongly suggests that the peer itself produced that attestation, thereby linking the validator to the peer's IP address.

2.2. Main Contributions / Findings

The paper makes several significant contributions:

1. Novel Deanonymization Technique: It proposes a simple, low-cost methodology that allows any node to infer which validators are hosted on its connected peers. This technique relies primarily on observing attestation messages and their distribution patterns.
2. Empirical Verification: Through a measurement study using four nodes over three days, the authors empirically demonstrated the feasibility and effectiveness of their deanonymization method, successfully locating over 15% of all Ethereum validators in the P2P network.
3. Implications and Mitigations: The work thoroughly outlines the implications of this lack of anonymity, including fairness, liveness, and safety concerns. It also discusses various potential mitigation strategies to help validators protect their privacy, ranging from protocol-level changes (e.g., additional subnets, secret leader election) to operational practices (e.g., additional nodes, private peering agreements, Distributed Validator Technology).
4. Novel Security Insights: The deanonymization technique yielded valuable information about validator distribution. Key findings include:
   • High concentration of validators on certain peers (e.g., over 19,000 validators on a single peer).
   • Detailed geographical distribution and organizational breakdown (cloud services vs. residential ISPs), revealing that about 90% of validators are run through cloud providers.
   • Discovery that operators for different staking pools run validators for multiple pools on the same machines, creating undesirable dependencies and raising concerns about the true independence and decentralization of these pools. These results were acknowledged by the Ethereum Foundation with a bug bounty, underscoring their impact.

3. Prerequisite Knowledge & Related Work

3.1. Foundational Concepts

To understand this paper, a foundational understanding of blockchain technology, particularly Ethereum's architecture and its P2P network, is essential.

• Blockchain and Proof-of-Stake (PoS): A blockchain is a decentralized, distributed ledger that records transactions across many computers. Ethereum operates as a Proof-of-Stake (PoS) blockchain, where participants (validators) stake a certain amount of cryptocurrency (32 ETH for Ethereum) to be eligible to validate transactions and create new blocks. This is in contrast to Proof-of-Work (PoW) systems (like older Bitcoin or Ethereum), where validators (miners) use computational power to solve cryptographic puzzles.

• Ethereum's Dual Layer Architecture:

  • Consensus Layer (Beacon Chain): This layer is responsible for the core PoS consensus mechanism, managing validators, their stakes, and the process of agreeing on the state of the blockchain. It orchestrates the creation and finalization of blocks. The paper primarily focuses on the P2P network of this layer.
  • Execution Layer: This layer (e.g., Geth client) processes transactions, executes smart contracts, and manages the state of the Ethereum Virtual Machine (EVM).

• Validators:

  • An individual can become a validator by depositing 32 ETH. Validators perform three main duties:
    1. Proposing Blocks: During each 12-second slot, one validator is randomly selected to propose a new block.
    2. Attesting: In each epoch (32 slots, ~6.4 minutes), every validator is assigned to a committee in one slot to attest (vote) on the correctness of a proposed block. An attestation is essentially a vote that a block is valid and should be included in the chain.
    3. Aggregating Attestations: With some probability, a validator is chosen as an aggregator within its committee. Aggregators collect and combine individual attestations into a single aggregated BLS signature, which reduces network overhead.
  • Validators are identified by a validator ID, linked to a public/private key pair. A validator client is a software component that manages one or more validator keys and performs their duties.
  • Staking Pools: Allow participants to pool resources to meet the 32 ETH requirement, enabling smaller holders to participate in staking.

• Nodes: A consensus node (or simply node) is a client software (e.g., Prysm, Lighthouse) that connects to the Ethereum P2P network. It manages its own identity (node ID, public/private key pair, IP address, port), which is shared via Ethereum Node Records (ENR). A single node can host multiple validator clients, or it might not host any validators at all (e.g., for researchers monitoring the network).

• Epochs and Slots:

  • Slot: A 12-second time period during which a new block can be proposed.
  • Epoch: A collection of 32 slots (approximately 6 minutes and 24 seconds). Validator duties are scheduled per epoch. Block finalization (irreversible commitment) occurs at the epoch level.

• Attestation Subnets (Topics) and Committees:

  • To scale message dispersal, validators' attestations are divided among 64 committees.
  • This committee division is mirrored in the network layer, which is partitioned into 64 attestation subnets (also called topics). Each committee is assigned to a specific subnet, and its attestations are broadcast only within that subnet. There's also an additional subnet for attestation aggregates.

• GossipSub Protocol: Ethereum uses GossipSub, a probabilistic broadcast protocol, for message exchange in its P2P network.

  • When a validator client signs an attestation, its connected consensus node publishes it to the corresponding subnet by sending it to a subset of its peers subscribed to that subnet. This subset is called the node's fanout.
  • Nodes statically subscribe to two topics by default, acting as "backbones" for those subnets. They can also dynamically subscribe to other subnets if they have an upcoming duty (e.g., aggregation).
  • Nodes forward messages they hear about within a subscribed subnet to their best-performing peers in that subnet (based on peer scoring).

• Threat Model: The paper assumes a weak, passive attacker who has access to a few nodes (without validators) and a limited budget. The attacker only observes exchanged network-level messages. Deanonymization is successful if the probability of linking a validator to an IP is significantly higher than random.

  • DoS (Denial-of-Service) attacks: Overwhelming a target with traffic to disrupt its service.
  • BGP Hijacking: Maliciously redirecting internet traffic by falsifying BGP routing information.
  • MEV (Maximal Extractable Value): Profit that can be extracted by block producers by including, excluding, or reordering transactions within a block.
  • Time-bandit attacks: An attacker attempts to rewrite past blocks to claim MEV or other rewards.
  • Liveness: The property that a blockchain continues to produce new blocks and progress.
  • Safety: The property that once a block is finalized, it remains irreversible and cannot be changed or reverted.
  • Finality Gadget: The mechanism in PoS that ensures blocks are irreversibly committed to the chain once enough attestations are gathered.

3.2. Previous Works

The paper contextualizes its work within several areas of prior research:

• Network Measurements and Attacks:
  • Early works focused on gossip properties and miner centralization in Bitcoin and Ethereum [21, 36, 47, 54].
  • Previous Ethereum protocol versions allowed for estimating validator counts on nodes by observing uniform random attestation backbones [14, 34]. This paper expands on this by leveraging more intricate protocol details.
• Deanonymization in Anonymity-Preserving Systems:
  • Research on Crowds and Tor systems demonstrated how repeated path observations (e.g., predecessor attacks [31, 79]), traffic correlation [59], timing attacks [71], and learning-based attacks [60] can degrade anonymity. The current paper highlights that its method exploits performance improvements in GossipSub, making it more effective in this specific context.
• Cryptocurrency-Specific Deanonymization:
  • Prior deanonymization attacks in cryptocurrencies (Bitcoin, Lightning Network, Ethereum) primarily used network timing information to track the source of transactions [8, 9, 17, 30, 69, 72].
  • Dandelion protocols [12, 29] were proposed to prevent such timing-based attacks.
  • The paper notes that while the danger of validator deanonymization has been discussed [44, 68], concrete methodologies were previously limited to metadata analysis.
• Network-Layer Attacks:
  • Broader network-layer attacks include Eclipsing [40, 42, 55], network-partitioning [73, 74], and routing manipulations like BGP-Hijacking [3, 75].
  • Protocol-level details have been used to infer peering relationships in Bitcoin [22, 58, 61], Ethereum [51], and Monero [18].
• Gossip Networks:
  • The GossipSub protocol [76] and its improved version (v1.1) [77] have been analyzed for weaknesses. Kumar et al. [50, 49] showed GossipSub's score function is exploitable and synthesized attacks.
  • Guerraoui et al. [39] studied source anonymity limits in gossip on general graphs. This paper differentiates itself by focusing on the anonymity impact of splitting a single gossip network into multiple components (subnets).

3.3. Technological Evolution

Ethereum's transition from Proof-of-Work to Proof-of-Stake ("The Merge") and subsequent scaling efforts (like Danksharding which is mentioned as a future upgrade [63]) have driven significant changes in its P2P network architecture. The sheer number of validators (over one million) makes it impractical for every validator to broadcast every attestation to every node. This necessity led to the adoption of attestation subnets and the GossipSub protocol. These solutions were designed to reduce message complexity and enable solo stakers to run nodes with low hardware and network requirements. However, this paper demonstrates that these very scaling solutions, by partitioning message dissemination responsibilities, inadvertently create a side-channel that allows for deanonymization. The fine-grained control over which messages are propagated by which nodes, intended for efficiency, can be exploited to reveal validator locations.

3.4. Differentiation Analysis

Compared to previous work, this paper's core innovation and differentiation lie in:

• Exploiting Protocol-Level Details for Deanonymization: Unlike prior deanonymization attacks that primarily relied on network timing information or required connecting to a large portion of the network, this method leverages specific details of the GossipSub protocol's attestation broadcast mechanism. It identifies validators by observing "out-of-responsibility" attestations from peers.
• Low Cost and Localized Attack: The proposed attack is "simple and low-cost," executable from a single node connected to a subset of peers. This contrasts with timing-based attacks that often require global network visibility to accurately pinpoint message originators.
• Focus on Validator Anonymity: While the general concept of deanonymization in P2P networks is not new, this paper specifically targets the anonymity of validators in Ethereum's PoS context, an area previously discussed but without concrete, empirically verified methodologies.
• Quantification of Impact: The paper provides a quantitative assessment of the privacy issue, successfully locating a significant portion (>15%) of all Ethereum validators and analyzing their geographical and organizational distribution.
• Implications for Decentralization: The findings go beyond just identifying IP addresses, revealing insights into the concentration of validators, the interdependencies between staking pools, and the heavy reliance on cloud providers, which have direct implications for Ethereum's stated goal of decentralization.

4. Methodology

4.1. Principles

The core principle behind the deanonymization method is to exploit the specific message propagation rules of Ethereum's GossipSub protocol for attestations. In Ethereum, nodes are not responsible for broadcasting all attestations to all their peers. Instead, attestations are propagated within specific subnets (topics), and nodes typically subscribe to only a few (two by default) of these subnets, acting as "backbones."

The key insight is this: if a peer $p$ sends an attestation created by a validator $ν$, and this attestation belongs to a subnet that $p$ is not subscribed to (i.e., not one of its backbone subnets), then it is highly probable that $p$ is the original source of that attestation. This implies that the validator $ν$ is hosted on the same machine as peer $p$. If this behavior is observed repeatedly and consistently for a specific validator and peer, it provides strong confidence in linking $ν$ to $p$'s IP address.

This principle leverages the fact that a node will only forward an attestation it "hears" about on a subscribed subnet. If it forwards an attestation for an unsubscribed subnet, it must have originated it.

4.2. Core Methodology In-depth (Layer by Layer)

The methodology begins with an "ideal" scenario and then refines it with a heuristic approach to handle the complexities and imperfections of a real-world P2P network.

4.2.1. Ideal Approach

Let's consider an ideal peer—a peer that provides perfect information. Imagine we are connected to a peer $p$ that hosts $V$ validators and acts as a backbone in two specific subnets.

• Validator Attestations: The $V$ validators on $p$ will attest $V$ times per epoch.

• Perfect Information Assumption: If we are in $p$'s fanout for all subnets (meaning $p$ forwards all relevant messages to us), and $p$ forwards all attestations it hears about in its two backbone subnets to us.

• Observation: In this ideal scenario, we would receive $V$ attestations from $p$ that originated from its own validators. Crucially, these $V$ attestations would appear across a wide variety of subnets, not just $p$'s two backbone subnets. For all other $N$ validators in the network, we would only receive their attestations from $p$ if those attestations came via $p$'s two backbone subnets.

  The core observation for the ideal case is: An ideal peer will only send us an attestation in a subnet they are not a backbone of if they are the signer of the attestation, and we are in their fanout for the corresponding subnet of the attestation.

This means that if we receive an attestation from peer $p$ for $validator ν$ on subnet S, and $S$ is not one of $p$'s announced backbone subnets, then $ν$ must be hosted on $p$. This makes deanonymization trivial in a perfect world.

The paper provides an illustrative example in Figure 2 (reproduced below) of this observation in practice. It shows attestations received from a peer over a four-hour window. The majority of pink attestations (from other validators) come from subnets 12 and 13 (the peer's backbone subnets). In contrast, attestations from the four identified validators (red, blue, yellow, green) are distributed across many subnets, confirming they originate from this peer.

该图像是一个图表，展示了2024年5月6日从17:30到21:00的不同时段内，各个委员会的参与情况。每个点代表不同的委员会，其中红色、蓝色、黄色和绿色的点分别对应不同的委员会，长条形粉色区域表示其他委员会的汇总数据。

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).

4.2.2. Imperfect Information in Practice

In the real world, network conditions introduce imperfections:

1. Non-default parameters: Nodes might run with more than two backbone subnets.

2. Network issues: We might not receive all attestations due to disconnections, dropped packets, or dynamic fanout membership (a peer chooses its fanout peers).

3. Dynamic subscriptions: A peer might temporarily subscribe to a subnet for an aggregation duty, making an attestation appear to be from a non-backbone subnet when it's actually just a temporary backbone.

4. Multiple nodes for validators: A validator client might use multiple nodes to propagate messages or perform different tasks, complicating the mapping.

5. Peer scoring: Our node needs to contribute to attestation propagation (e.g., by announcing attestations first) to maintain a good peer score and stay in a peer's fanout, which can affect the quantity of attestations received from that peer.

   To guide the development of heuristics, the authors make a simplifying Assumption: A peer will be the first to tell us about their attestation most of the time.

4.2.3. Heuristic Approach

To handle imperfect information, a heuristic deanonymization approach is developed. A validator $\nu$ is considered to be hosted on a peer $p$ if all of the following conditions are met:

• Condition C1: Proportion of Non-Backbone Attestations This condition ensures that a sufficiently high proportion of attestations received from peer $p$ for validator $ν$ originate from subnets where $p$ is not a backbone. This directly implements the core principle of detecting "out-of-responsibility" attestations.

  C1: The proportion of non-backbone attestations for validator $\nu$ exceed $ 0.9 \cdot \left( \frac{64 - n_{\mathrm{sub}}(p)}{64} \right) $ where $n_{\mathrm{sub}}(p)$ is the average number of subnets the peer $p$ is subscribed to (i.e., acts as a backbone for) over the connection's duration.

  • Explanation:
    • 64: Total number of attestation subnets.
    • $n_{\mathrm{sub}}(p)$: The number of subnets peer $p$ is actively subscribed to (its backbones). This value is determined by observing the peer's advertised static subscriptions.
    • $64 - n_{\mathrm{sub}}(p)$: The number of subnets for which peer $p$ is not a backbone.
    • $$\frac{64 - n_{\mathrm{sub}}(p)}{64}$$: This represents the expected proportion of attestations from $p$'s own validators that would come from non-backbone subnets, assuming random assignment of validators to subnets.
    • 0.9: A conservative threshold. The observed proportion must be at least 90% of this expected value. This ensures that the heuristic focuses on peers from which the deanonymizing node receives most attestations across all subnets, minimizing false positives from incidental messages.

• Condition C2: Not Subscribed to All Subnets This condition explicitly excludes peers that are subscribed to all 64 subnets.

  C2: The peer is not subscribed to all 64 subnets.

  • Explanation: If a peer is subscribed to all 64 subnets, then all attestations it sends would be considered "backbone" attestations from its perspective, as it is responsible for all subnets. In this case, Condition C1 would always yield a proportion of 0 non-backbone attestations, making deanonymization impossible with this method. This condition ensures the method is applied only where it can yield meaningful results.

• Condition C3: Sufficient Attestation Receipt This condition ensures that the deanonymizing node receives a substantial portion of the expected attestations from the peer for the target validator.

  C3: We receive at least every tenth attestation we expect for the validator $\nu$ from the peer.

  • Explanation: This acts as a quality filter for the connection. If the deanonymizing node is not receiving a significant fraction of a validator's attestations from a peer, it suggests a poor or unstable connection, or that the peer is not including the deanonymizing node in its fanout consistently. Without sufficient data, the confidence in the deanonymization would be low. By participating in all subnets itself, the deanonymizing node increases its chances of being added to a peer's fanout, making this condition more likely to be met for legitimate cases.

• Condition C4: Statistical Significance of Attestations This condition provides a statistical measure to distinguish between a peer's own validator attestations and general network traffic it might be forwarding.

  C4: The number of attestations we receive for the validator $\nu$ from the peer $p$ exceeds the mean number of attestations per validator from peer $p$ by one standard deviation.

  • Explanation: This acts as an additional confidence booster. It requires that the candidate validator's attestation count from peer $p$ is not just "above average" but statistically significantly higher than the average attestation count observed for other validators whose messages are also received from $p$. This helps to filter out cases where a peer might be forwarding a high volume of attestations for a non-local validator due to transient network conditions or dynamic subscriptions.

    These conditions represent a conservative approach, ensuring that only peers with sufficiently stable and informative connections are analyzed, thus reducing the likelihood of false positives.

5. Experimental Setup

5.1. Datasets

The study relied on two primary types of data: Ethereum network-layer logs and validator entity labels.

• Ethereum Network-Layer Logging:

  • Source: The authors developed a modified Prysm client (a popular Ethereum consensus layer client) called RAINBOW.
  • Mechanism: RAINBOW acts like any Prysm node but logs specific data points. It connects to up to 1,000 peers and statically subscribes to all subnets. This modification allows for a broader observation of messages, crucial for deanonymization.
  • Logged Data:
    1. All attestations received, along with their origin (the peer from which they were first received) and origin subnet.
    2. Advertised static subscriptions of its peers, which is essential for determining $n_{\mathrm{sub}}(p)$ in Condition C1.
    3. Precise connection data for all interacted nodes.
  • Deployment: Three RAINBOW instances were run on AWS r5a.4xlarge machines in different data centers: us-east-1 (VA), eu-central-1 (FR), and ap-northeast-2 (SO). An additional node was run on a bare-bones server in Zurich (ZH).
  • Duration & Scale: Data collection spanned three days (May 7-10, 2024 UTC), accumulating approximately 700 GB of compressed data, which was loaded into SQL databases.
  • Duplicate Handling: Only the first received attestation (among potentially many duplicates due to gossiping) was considered to pinpoint the earliest source.

• Ethereum Network Coverage (RAINBOW Crawler):

  • Purpose: To understand the RAINBOW nodes' coverage of the overall Ethereum Beacon network.
  • Mechanism: A custom crawler implementation was used, similar to those for the Ethereum execution network. It leverages the discv5 peer discovery protocol. Nodes maintain a peer table based on the Kademlia hash table, storing ENRs (Ethereum Node Records) that contain a node's identity, IP, and port. The crawler enumerates a node's peer table and repeats this for newly discovered nodes.
  • Observations: Over the three days, an average of 16.5K unique IPs (20K unique node IDs) were discovered daily, with a cumulative total of 20,240 IPs (28,998 IDs).
  • Reachability: Hourly in-protocol ping messages were sent to discovered ENRs to identify reachable nodes (not behind NAT/firewall), averaging 8.1K unique IPs (8.4K node IDs) daily, totaling 8,941 reachable IPs (9,468 IDs) over the period.

• Validator Entity Labeling:

  • Purpose: To validate and verify the deanonymization results by grouping validators by the entity they belong to (e.g., staking pools) and checking consistency.
  • Base Dataset: pubkey_mapping dataset from mevboost.pics, which provides existing labels for validators.
  • Amendments/Enhancements:
    1. Deposit Addresses: Monitored the Beacon chain deposit contract. For the top 15 entities, deposit addresses used over 100 times were identified. Any validator funded by these addresses was attributed to the corresponding entity.
    2. Fee Recipient Addresses: For the top 15 entities, fee recipient addresses used over 100 times were gathered. Validators exclusively using one such address were attributed to that entity. This helps identify who receives the execution layer rewards.
    3. Label Cleaning: Any validators with multiple conflicting labels in the combined dataset were removed to maintain data integrity.

5.2. Evaluation Metrics

The paper utilizes several metrics to assess the effectiveness and accuracy of its deanonymization technique.

• Deanonymization Success Rate:

  • Conceptual Definition: This quantifies the proportion of Ethereum validators that could be successfully linked to a specific IP address (peer) within the network. It directly measures the impact of the deanonymization technique.
  • Formula: Not explicitly given as a formula, but calculated as: $ \text{Deanonymization Success Rate} = \frac{\text{Number of unique validators deanonymized}}{\text{Total number of active Ethereum validators}} $
  • Symbol Explanation:
    • Number of unique validators deanonymized: The count of distinct validator IDs successfully linked to IP addresses by the RAINBOW nodes.
    • Total number of active Ethereum validators: The total count of active validators in the Ethereum network during the measurement period.

• Consistency of Validator Sets (Verification Metrics): These metrics are used to verify the internal consistency of the identified validator sets on a peer, lending credibility to the deanonymization.

  • Conceptual Definition: A set of validators associated with a single peer is considered "consistent" if their attributes (e.g., entity labels, funding addresses, ID patterns) strongly suggest they belong to the same operational entity. This serves as a proxy for ground truth, as validators from a single entity are expected to be co-located.
  • Consistency Conditions (Γ1, Γ2, Γ3, Γ4):
    • Γ1 (Entity Labels): We have entity labels for at least 30% of the validators and at least 90% of these are identical.
    • Γ2 (Deposit Address): At least 90% of the validators were funded by the same deposit address.
    • Γ3 (Fee Recipient Address): At least 90% of the validators have exclusively used the same fee recipient address.
    • Γ4 (Consecutive IDs): The IDs of the validators can be aggregated into a few groups with consecutive IDs. The number of groups must be at most one-tenth of the number of validators at that peer.
    • Single Validator: A peer hosting only a single validator is trivially consistent.
  • Inconsistency Condition (C1'):
    • Conceptual Definition: A validator set is deemed "inconsistent" if it exhibits a high degree of diverse entity labels, suggesting validators from multiple, unrelated entities are co-located. This often points to P2P service providers who relay messages for many distinct entities.
    • Condition C1': We have entity labels for at least 10% of the validators, but less than 90% of these are identical (with exceptions for ENS names and Rocketpool, where some inconsistencies are expected).
  • Unknown: Validator sets not meeting either the consistency or inconsistency criteria.

• Uniqueness of Validator-IP Mapping:

  • Conceptual Definition: This metric assesses whether a single validator ID is consistently mapped to only one IP address (peer) or to multiple. Multiple mappings might indicate redundancy measures by validators or errors in the deanonymization.
  • Formula: Not explicitly given, but derived from counting validator IDs that appear in the deanonymized sets of more than one IP:port combination.
  • Symbol Explanation:
    • Non-unique validators: The count of validator IDs that are mapped to more than one IP:port combination.
    • % non-unique validators: The proportion of these non-unique validators relative to the total number of deanonymized validators.

• Similarity of Deanonymizations Across RAINBOW Nodes:

  • Conceptual Definition: This metric validates the robustness of the deanonymization by checking if multiple RAINBOW nodes (located geographically apart) identify the same set of validators on a given IP:port combination (peer). High similarity indicates the method is reliable and not just specific to one observer's perspective.
  • Formula:
    • Percentage of peers with exact same set: $ \frac{\text{Number of peers where all RAINBOW nodes located exact same set}}{\text{Total number of peers deanonymized by more than one RAINBOW node}} \times 100% $
    • Average overlap of validator sets: $ \text{Average} \left( \frac{|\text{Validators identified by RAINBOW A} \cap \text{Validators identified by RAINBOW B}|}{|\text{Validators identified by RAINBOW A} \cup \text{Validators identified by RAINBOW B}|} \right) \times 100% $
  • Symbol Explanation:
    • RAINBOW A, RAINBOW B: Two different RAINBOW nodes.
    • $|\cdot|$: Cardinality (number of elements) of a set.
    • $\cap$: Set intersection.
    • $\cup$: Set union.

5.3. Baselines

The paper does not compare its deanonymization method against other specific deanonymization models or algorithms as baselines. Instead, its baseline is the expected anonymity in the Ethereum P2P network, which the paper demonstrates is not upheld. The paper's contribution is to show the existence and feasibility of such an attack, rather than optimizing it against competing methods. The "verification" steps (consistency, uniqueness, similarity) serve as internal validation of the method's accuracy, not as a comparison against alternative deanonymization techniques.

6. Results & Analysis

6.1. Core Results Analysis

6.1.1. Peering Overview

The RAINBOW nodes established a large number of connections. The following are the results from Table 1 of the original paper:

Analysis:

• Over three days, the four RAINBOW nodes collectively attempted connections to 11,219 unique peers and successfully connected to 10,785.

• Crucially, 4,372 unique peers maintained "long connections" (total connection time > 32 epochs, or one full epoch duration) with at least one RAINBOW node. This represents approximately half of the reachable network (8,941 nodes detected by the crawler) and about one-third of the estimated total network size.

• The VA (Virginia) and ZH (Zurich) nodes showed higher connection numbers (seen, established, long) compared to FR (Frankfurt) and SO (Seoul), suggesting better network positioning or configuration for these nodes.

  The following figure (Figure 4 from the original paper) shows the number of peers each RAINBOW node connected to over time:

  该图像是图表，展示了四个RAINBOw节点在2024年5月7日至9日的连接同行的平均数。FR节点平均连接645个同行，ZH节点537个，FR节点369个，SO节点338个。该图表揭示了各节点之间的连接变化。

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.

Analysis:

• VA consistently maintained the highest average number of peers (645), followed by ZH (537). FR (369) and SO (338) had fewer peers and exhibited similar dips in peer count, particularly around May 8th, 8:00 UTC. This difference in peer count implies that VA and ZH likely gathered more comprehensive data.

• The drops in peer count, especially for FR and SO that did not fully recover, might be artifacts from AWS or network instability, but the authors state they do not impact accuracy, only the number of deanonymized peers.

  The following are the results from Table 2 of the original paper:

  	FR	SO	VA	ZH
  FR	1,017	496	543	197
  SO	496	1,142	592	205
  VA	543	592	2,207	495
  ZH	197	205	495	1,942

Analysis:

• Table 2 shows the pairwise overlap of peers with long connections. FR and SO had the largest relative overlap (496 peers, about half of their respective total long connections), suggesting they connected to a more similar set of peers.
• VA and ZH had larger absolute numbers of long connections, but their overlap with other nodes constituted a smaller proportion of their total connections.
• The ZH node had the smallest overlap with others, possibly because it was the only node not hosted on AWS, leading to connections with a more distinct set of peers. This geographic and infrastructure diversity among RAINBOW nodes helps ensure a broad and representative sample.

6.1.2. Deanonymization Categories

The deanonymization heuristics classified peers into four categories. The following are the results from Table 3 of the original paper:

Analysis:

• Overall, 52.35% of peers with long connections were successfully deanonymized (validators located).
• 37.52% of peers were confidently identified as hosting no validators (no non-backbone attestations received).
• A very small fraction (0.69%) subscribed to all 64 subnets, making deanonymization with this method impossible for them.
• Only 9.46% fell into the rest category (grey area), where the method received some non-backbone attestations but couldn't confidently locate validators.
• Significantly, for peers not identified as having "no validators," the method could deanonymize 84.57% ($52.35$). This indicates high effectiveness where validators are likely present.
• VA and ZH nodes deanonymized a higher proportion of peers, and had a lower proportion of "no validators" peers, consistent with their stronger overall connectivity.

6.1.3. Deanonymizations Over Time and Across RAINBOW Nodes

The following figure (Figure 5 from the original paper) shows the cumulative unique new peers our RAINBOW nodes connected to over time:

该图像是图表，展示了多个RAINBOW节点在不同时间点连接的累计新节点数量。时间范围从2024年5月7日至5月9日，横轴为时间，纵轴为累计新节点数量，各节点以不同颜色表示。

Figure 5: The cumulative number of peers each of our RAINBOW nodes connected to over time, as well as the cumulative count across all.

Analysis:

• The cumulative number of unique new peers increased almost linearly over the three-day period, with the VA machine showing the fastest rate of new connections. This highlights the benefit of deploying multiple geographically diverse nodes to broaden the reach.

  The following figure (Figure 6 from the original paper) shows the number of validators deanonymized by our RAINBOW nodes over time (excluding service providers):

  该图像是图表，显示了由RAINBOW节点在不同时间段内识别出的Ethereum验证者数量（不包括服务提供者），以及各个节点的累计数量。图中可以看出，随着时间的推移，某些节点的连接质量可能下降，导致识别的验证者数量减小，尤其是SO RAINBOW节点表现明显。

Figure 6: The number of validators (excl. service providers) deanonymized by our RAINBOW nodes over time, as well as the cumulative count across all. Note that the number of deanonymized peers can decrease over time as an initially good connection to a peer can degrade over time. This is particularly evident for the SO RAINBOW node.

Analysis:

• There was a sharp initial increase in deanonymized validators during the first 1.5 days. While the growth rate slowed, the total number of deanonymized validators continued to increase throughout the measurement period.
• The cumulative number of deanonymized validators shows that ZH consistently located the most validators.
• Notably, the number of deanonymized peers could decrease over time for some nodes (e.g., SO), if the connection quality degraded and no longer met the heuristic conditions. This emphasizes the dynamic nature of P2P connections and the conservatism of the heuristics.
• The authors discuss the costs associated with running these nodes (AWS machines, network traffic), noting that while not trivial, they are minor compared to potential MEV profits. They suggest attackers could optimize costs by rotating through peers.

6.1.4. Overall Validators Located

The following are the results from Table 4 of the original paper:

Analysis:

• Across all four RAINBOW nodes, a total of 252,895 validators were initially located.
• After excluding validators from identified P2P service providers (discussed below), 161,057 unique validators were deanonymized. This represents more than 15% of the total Ethereum validator set.
• ZH deanonymized the largest share (132,443 exclusive of service providers), followed by VA (52,916).

6.1.5. Verification: Consistency of Validator Sets

The consistency of validator sets on a peer was a key verification step. The following are the results from Table 5 of the original paper:

Analysis:

• A remarkable 93.75% of deanonymized peers had a consistent validator set (i.e., validators on that peer largely belonged to the same entity based on labels, deposit addresses, fee recipient addresses, or ID patterns). This strongly validates the accuracy of the deanonymization method.
• However, when looking at the proportion of validators, only 63.67% belonged to consistent sets, while 39.67% belonged to inconsistent sets. This discrepancy arises because inconsistent validator sets were, on average, significantly larger.

P2P Service Providers:

• The large, inconsistent validator sets (17 peers with at least 200 validators, one having 84,165) were identified as P2P service providers (e.g., bloXroute). These entities likely do not operate the validators themselves but relay messages for many different clients.

• The following figure (Figure 7 from the original paper) shows the pairwise overlap of validator sets for these large inconsistent peers:

  该图像是一个热力图，显示了所有节点的验证者集之间的成对重叠情况。热力图中色块的深浅表示节点 $j$ 的验证者集中与节点 $i$ 的验证者集的重叠比例，重叠比例越大，颜色越深。该图反映了节点之间验证者的共享情况。

Figure 7: Pairwise overlap of the validator set of all peers with an inconsistent set of at least 200 validators. The darker the color of cell ( i , j ) , the larger the proportion of validators in the set of peer $j$ also found on peer $i$ .

Analysis:

• Figure 7 shows significant overlap between the validator sets of these 17 peers, reinforcing the hypothesis that they are P2P service providers that relay messages for a diverse and large set of validators.
• These 17 suspected P2P service providers were excluded from the final count of deanonymized validators, resulting in the 161,057 figure.

6.1.6. Verification: Uniqueness of Validator-IP Mapping

The third column in Table 4 shows the count of non-unique validators.

• 16,172 validators (roughly 10% of all deanonymizations excluding service providers) were mapped to more than one IP:port combination.
• Closer inspection revealed that nearly three-fourths of this overlap involved peers in the same city, suggesting entities might use multiple machines to relay messages for their validators to ensure uptime. This practice, while aimed at resilience, also provides a degree of privacy by obscuring the exact single point of origin.

6.1.7. Verification: Similarity of Deanonymizations

• Out of 794 peers deanonymized by more than one RAINBOW node, 762 (95.96%) had the exact same set of validators identified by all connected RAINBOW nodes.
• The average overlap of validator sets was 99.20%.
• This high degree of agreement between geographically distributed RAINBOW nodes strongly suggests that the deanonymization method is robust and reliable, identifying consistent validator sets on peers regardless of the observation point.

6.1.8. Insights

The deanonymization provided valuable insights into the Ethereum P2P network structure. The following are the results from Table 6 of the original paper:

Analysis:

• Table 6 shows the pairwise overlap of deanonymized validators across nodes. There is significant overlap, for instance, over half of the validators deanonymized by FR, SO, and VA were also deanonymized by ZH. This indicates that while each node discovers unique validators, a substantial portion is visible to multiple observers.

6.1.9. Geographical Distribution

The following figure (Figure 8 from the original paper) shows the number of peers and validators across different countries:

该图像是一个图表，展示了不同国家的以太坊节点和验证者数量。上图显示各国的节点数量，下图显示各国的验证者数量。美国的节点数量最多，而荷兰的验证者数量领先于其他国家。

Figure 8: The image is a chart showing the number of Ethereum peers and validators across different countries. The top graph displays the number of peers by country, while the bottom graph shows the number of validators. The United States has the highest number of peers, while the Netherlands leads in the number of validators.

Analysis of Figure 8 (Geographical Distribution):

• Peers (Figure 8a):
  • 46.79% of deanonymized peers are in Europe, 38.05% in North America, 9.95% in Asia.
  • The United States hosts the largest number of deanonymized peers (33.03%). Germany is second.
  • A geographical bias exists: VA deanonymized more peers in the US, while ZH deanonymized more in most European countries. SO showed high relative deanonymization in Australia and South Korea.
• Validators (Figure 8b):

  • A notable shift occurs when looking at validators instead of peers. The Netherlands hosts the most validators (12.71%), despite the US having the most peers.

  • 70.90% of located validators are in Europe, 12.48% in North America, 11.46% in Asia.

  • This suggests that while the US has many individual nodes, other European countries (like the Netherlands) host nodes with a higher concentration of validators.

    The following figure (Figure 9 from the original paper) shows the number of Ethereum peers and validators connected by different service providers:

    该图像是柱状图，展示了不同服务提供商连接的以太坊节点数和验证者数量。上半部分（a）显示了各个提供商的节点数量，下半部分（b）列出了各个提供商的验证者数量，突显了不同供应商在以太坊网络中的参与度。

Figure 9: The image is a bar chart showing the number of Ethereum peers and validators connected by different service providers. The upper part (a) displays the number of nodes for each provider, while the lower part (b) lists the number of validators, highlighting the participation of different providers in the Ethereum network.

Analysis of Figure 9 (Organizational Distribution):

• Peers (Figure 9a):
  • The largest organization by peer count is Comcast (a residential ISP, 5.97%), followed by cloud providers like Hetzner, OVH, and Amazon.
  • Roughly half of the deanonymized peers are hosted by cloud providers, and the other half by residential ISPs (home stakers).
• Validators (Figure 9b):
  • A dramatic shift: 8 out of the top 10 organizations hosting validators are cloud providers, with the top 7 being exclusively cloud providers.
  • Amazon data centers host the largest number of validators (19.07%).
  • The ZH node (not on AWS) deanonymized the largest proportion of validators in Amazon data centers, indicating its unique peering advantages.
  • Crucially, about 90% of all deanonymized validators run through cloud providers, while only 10% belong to residential ISPs. This highlights a significant centralization risk on infrastructure providers.

6.1.10. Validator Distribution

The following figure (Figure 10 from the original paper) shows the cumulative distribution function (CDF) of the number of validators hosted per peer:

该图像是图表，展示了每个节点托管的验证者数量的累计分布函数（CDF）。图中显示，27%的节点仅托管一个验证者，而约11%的节点托管至少100个验证者。竖线标记了100、250、300、350、400、500和1000的数量级。

Figure 10: Cumulative distribution function (cdf) of the number of validators hosted per peer. We only locate a single validator on $27 \\%$ of peers, while there at least 100 validators located on around $11 \\%$ of peers. The vertical lines indicate 100, 250, 300, 350, 400, 500, and 1,000.

Analysis:

• The CDF shows that most peers host a small number of validators: 27% host only one, and over half host no more than four validators. This represents individual stakers or small operations.
• However, 11% of peers host more than 100 validators, and there are distinct "jumps" in the CDF at "round numbers" (100, 250, 300, 350, 400, 500, and 1,000 validators per peer). This strongly suggests that large organizations divide their validators across nodes in predefined, often round, numbers (e.g., 1,000 validators per node). This observation also serves as an implicit validation of the deanonymization technique's accuracy, as it implies the method successfully identifies all validators on a machine.

6.1.11. Staking Pools

The following figure (Figure 11 from the original paper) shows the cumulative distribution function (CDF) of the number of validators hosted per peer for the biggest five staking pools:

该图像是图表，展示了最大五个质押池每个节点所托管的验证者数量的累计分布函数（CDF）。横轴表示每个节点的验证者数量，纵轴显示其相应的CDF值。

Figure 11: Cumulative distribution function of the number of validators hosted per peer for the biggest five staking pools.

Analysis:

• Figure 11, focusing on the top five staking pools (Lido, Coinbase, Ether.Fi, Binance, Kraken), also exhibits the "round number" pattern for validators per peer, confirming that these large entities employ structured deployment strategies.

• The average peer in these pools hosts 709 validators, with the largest single peer hosting 19,390 validators. This highlights a security concern: the concentration of thousands of validators on single machines means that relatively few successful attacks against these highly concentrated peers could significantly impact Ethereum's liveness, despite the overall large number of validators.

  The following figure (Figure 12 from the original paper) shows the number of validators per peer for the biggest five staking pools:

  该图像是一个柱状图，展示了五个最大的质押池中每个节点的验证者数量。图中数据显示，来自四个质押池的验证者数量显著高于其他池，反映了验证者在 P2P 网络中的分布情况。

Figure 12: Number of validators per peer for the biggest five staking pools. Notice that we only deanonymize validators from four of the five biggest staking pools.

Analysis:

• Figure 12 further illustrates the concentration, showing that most peers in these major pools host over 100 validators. This demonstrates the economic benefits of staking pools, as they optimize for efficiency by running many validators on fewer, powerful machines.

Inter-pool Dependencies:

• Many staking pools use node operators. While protocols claim independence among these operators to promote decentralization, the study found five instances where validators from two different staking pools, operated by the same node operator, were located on the same machine.
• This finding reveals undesirable dependencies, indicating that staking pools are not always as independent as advertised. If such a shared node goes offline, validators from multiple protocols are affected, raising questions about the resilience and true decentralization of the Ethereum consensus layer, especially given that the largest staking pool controls nearly a third of the staking power.

6.1.12. Implications on Decentralization

The insights gained from the deanonymization raise serious questions about Ethereum's decentralization and resilience:

• Concentration Risk: The discovery of thousands of validators (up to 19,390) on single peers creates single points of failure. If these few highly concentrated peers go offline, Ethereum's liveness could be jeopardized, as more than two-thirds of validators must be online for blocks to finalize.
• Infrastructure Provider Centralization: The heavy reliance on cloud providers (90% of validators) means that the underlying infrastructure is centralized, making it vulnerable to attacks or policy changes affecting these providers.
• Inter-Staking Pool Dependencies: The finding that different staking pools share node operators and even co-locate validators on the same machines contradicts claims of independence and decentralization. This entanglement means a disruption to one node operator could affect multiple major staking pools simultaneously, impacting the broader network.
• Lack of Transparency: The difficulty in accessing data about validator distribution across node providers hinders a transparent assessment of Ethereum's decentralization.

6.2. Ablation Studies / Parameter Analysis

The paper includes an Appendix (A) detailing robustness testing for its heuristic conditions (C1, C2, C3, C4). This is a form of ablation study to understand the impact of each parameter.

The following are the results from Table 7 of the original paper:

The following are the results from Table 8 of the original paper:

Analysis of Heuristics:

• Condition C1 (Proportion of non-backbone attestations):

  • Omitting C1 (|) dramatically increases the number of located validators (to 271,260 excl. service providers) and non-unique validators (to 13.15% from 10.04%). It also significantly decreases the consistency of validator sets (74.32% consistent peers vs. 93.75%). This confirms C1 is crucial for reducing false positives.
  • $c1 = 0.9$ (chosen parameter) offers a good balance. A lower $c1 = 0.3$ yields similar results to 0.9 in terms of located validators but 0.9 provides slightly more consistent validator sets. A more restrictive $c1 = 1.0$ reduces the number of located validators significantly (to 125,578) without substantially improving consistency.

• Condition C2 (Not subscribed to all 64 subnets):

  • Omitting C2 (|) slightly increases the located validators and % non-unique validators (11.08% vs. 10.04%). While the impact is smaller than C1, it helps maintain higher accuracy by excluding un-deanonymizable peers.

• Condition C3 (Sufficient attestation receipt):

  • Omitting C3 (|) leads to a massive increase in validators (885,864 excl. service providers) and non-unique validators (53.42%), and drastically reduces consistency (66.17% consistent peers). This highlights C3's importance for ensuring data quality from strong connections.
  • $c3 = 10$ (chosen parameter) provides a good balance. $c3 = 20$ (less restrictive) locates more validators (270,441) but with lower consistency (88.37%). $c3 = 5$ (more restrictive) locates fewer validators (110,896) without a major gain in consistency. The authors chose $c3 = 10$ as it found significantly more validators with minimal loss in accuracy or consistency.

• Condition C4 (Statistical significance of attestations):

  • The impact of C4 was found to be the smallest. Omitting it (|) or using $c4 = 1$ (chosen parameter) showed very similar results in terms of validators located, non-unique validators, and consistency.

  • A highly restrictive $c4 = 4$ significantly reduced the number of located validators without proportionally improving other metrics. Thus, $c4 = 1$ was chosen for its mild impact while still providing a cautious filter.

    In summary, the ablation studies confirm that the chosen heuristic parameters ($c1=0.9$, $c2=1$, $c3=10$, $c4=1$) strike a good balance between maximizing the number of deanonymized validators and ensuring the accuracy and consistency of the results, primarily by reducing false positives (non-unique validators and inconsistent sets).

7. Conclusion & Reflections

7.1. Conclusion Summary

This paper rigorously demonstrates a critical privacy flaw in the Ethereum P2P network, where validators' anonymity is compromised. It presents a novel, low-cost, and easily deployable deanonymization technique based on observing attestation messages. By exploiting the GossipSub protocol's subnet architecture, the method infers when a peer is the originating source of an attestation from a subnet it's not a backbone for, thereby linking the validator ID to the peer's IP address.

The empirical study, using four RAINBOW nodes over three days, successfully located over 15% (161,057 unique validators excluding service providers) of all Ethereum validators. Extensive verification steps, including the high consistency of validator sets on peers (93.75%), high uniqueness of validator-IP mappings, and high similarity of results across geographically distributed RAINBOW nodes, validate the accuracy and robustness of the technique.

The findings reveal significant implications for Ethereum's security and decentralization:

• Security Risks: The ability to deanonymize validators enables targeted DoS attacks against block proposers, potentially facilitating MEV extraction, compromising chain liveness, and even threatening safety by disrupting block finalization.

• Centralization Concerns: The study exposed a high concentration of validators on single peers (up to 19,390 validators on one machine), and a heavy reliance on cloud providers (90% of validators). It also uncovered interdependencies where single node operators run validators for multiple distinct staking pools on the same infrastructure, undermining claims of independence and exacerbating centralization risks.

  The Ethereum Foundation's acknowledgment with a bug bounty underscores the severity and impact of these findings.

7.2. Limitations & Future Work

The authors themselves point out several avenues for strengthening the attack and areas for future research:

• Attack Strengthening:
  • Running RAINBOW nodes with open ports would expand connections beyond reachable nodes, likely deanonymizing more validators.
  • Including duplicate attestations (currently only the first is considered) could further improve deanonymization.
  • Leveraging information from other validator tasks, such as participation in aggregation and sync committees, could enhance deanonymization and potentially identify aggregators before they self-reveal, opening new attack vectors.
• Privacy-Preserving Mechanisms: The paper emphasizes the urgent need for a privacy-preserving mechanism for the Ethereum P2P network.
• Mitigation Suggestions: The paper proposes several mitigation strategies:
  • Protocol-level changes: Validators taking on additional subnets (though with trade-offs in message complexity), secret leader election (promising for DoS defense), or Distributed Validator Technology (DVT) for resilience.
  • Operational changes: Validator clients connecting to multiple nodes or using private peering agreements to introduce k-anonymity (though these have cost and trust implications).
  • Network-layer defenses: Standard DoS mitigations, though often insufficient or costly for solo stakers.
• Broader Impact: The authors highlight that the underlying vulnerability is inherent to the GossipSub protocol's subnet overlay feature, meaning other projects using GossipSub should also consider these privacy implications.

7.3. Personal Insights & Critique

This paper presents a highly impactful piece of research that deftly leverages a deep understanding of network protocols to expose a critical vulnerability. The methodology is elegant in its simplicity and effectiveness, relying on observable network behavior rather than complex cryptographic breaks.

My key takeaways and critique are:

• Elegance of the Attack: The strength of the attack lies in its simplicity and low barrier to entry. Any node can execute it, and it doesn't require a global view or sophisticated computing resources. This makes the vulnerability highly practical and concerning. The core idea of "out-of-responsibility" messages is a clever exploitation of a mechanism designed for efficiency.

• Validation through Data: The comprehensive data collection and rigorous verification steps (consistency, uniqueness, similarity) are commendable. They lend strong credibility to the deanonymization results, demonstrating that the method is not just theoretical but empirically sound and accurate.

• Impact on Decentralization Narrative: The findings regarding the heavy reliance on cloud providers and the interdependencies between staking pools are particularly important. Ethereum's decentralization is a cornerstone of its security and philosophy. This research provides concrete, quantitative evidence that challenges the perception of robust decentralization, especially at the infrastructure level and within the staking ecosystem. This insight alone is invaluable for the community to address.

• Ethical Considerations: The authors' Responsible Disclosure and detailed Ethics Considerations sections are exemplary. Their commitment to minimizing harm, informing stakeholders, and withholding sensitive data is crucial for responsible security research, especially in critical infrastructure like Ethereum.

• Broader Applicability: The warning about GossipSub and its subnet feature being a general vulnerability for other projects is a significant contribution, extending the paper's impact beyond just Ethereum. This highlights the importance of considering privacy implications when designing performance-optimized P2P protocols.

• Challenges for Mitigation: While mitigations are proposed, many come with trade-offs. Increasing subnets increases message complexity (counter to scaling goals), multiple nodes increase costs (hurting solo stakers), and private peering agreements introduce trust assumptions. Secret leader election seems the most promising long-term solution as it addresses the root cause of DoS vulnerability without sacrificing efficiency or accessibility, but it is still in design stages. The challenge for Ethereum will be to implement effective privacy solutions without undermining its core ethos of decentralization and accessibility, particularly for solo stakers.

• Unverified Assumptions: The assumption that "a peer will be the first to tell us about their attestation most of the time" is a pragmatic one for the heuristic. While validated by the overall consistency, it's a point where network behavior could potentially shift or be manipulated by a sophisticated adversary trying to evade deanonymization. Future work might explore how resilient the method is to peers intentionally delaying their own attestations or broadcasting them differently to obscure origin.

  In conclusion, this paper serves as a crucial wake-up call for the Ethereum community and any system relying on similar GossipSub architectures. It transforms a perceived theoretical privacy risk into a quantified, empirically validated reality, providing clear insights into the network's structure and vulnerabilities while guiding future development towards more robust and privacy-preserving designs.