In an eclipse attack, a malicious actor gains control over all the connections of a target node within the P2P network. The attacker accomplishes this by flooding the node's connection slots with a swarm of sybil nodes—fake identities under the attacker's control—that they control. This effectively 'eclipses' the victim's view of the honest network, creating a false, attacker-controlled reality. The isolated node can then be fed manipulated data, such as fraudulent transactions or alternative blockchain histories, without being able to verify information with legitimate peers.
Eclipse Attack
What is an Eclipse Attack?
An eclipse attack is a network-level attack on a blockchain peer-to-peer (P2P) network where an attacker isolates a specific node by monopolizing all its incoming and outgoing connections.
The attack exploits the structure of blockchain P2P networks, which typically maintain a limited number of connections (e.g., 8-125 for Bitcoin) to manage bandwidth. Attackers use techniques like IP address spoofing and manipulating a node's peer discovery mechanisms—such as its neighbor tables and DNS seeders—to ensure their sybil nodes are the only ones the victim connects to. This isolation is a prerequisite for more damaging follow-on attacks, including double-spending, selfish mining, or Nakamoto consensus manipulation, as the victim cannot see the true state of the chain.
Mitigating eclipse attacks involves strengthening a node's peer selection and management. Key defenses include: - Randomized peer selection to prevent predictable connections. - Outbound connection persistence to maintain links to known honest peers. - Using anchor connections or hardcoded trusted nodes. - Implementing checks against Erebus attacks, a stealthier variant where the attacker infiltrates connections without being detected. Major networks like Bitcoin and Ethereum have continuously updated their client software (e.g., Bitcoin Core, Geth) to incorporate these countermeasures, making large-scale eclipse attacks increasingly difficult and resource-intensive to execute.
How an Eclipse Attack Works
An eclipse attack is a network-level attack that isolates a specific node from the honest peer-to-peer network, forcing it to view a falsified version of the blockchain.
An eclipse attack is executed by an adversary who gains control over all, or a majority, of the victim node's incoming and outgoing connections. In a peer-to-peer network like Bitcoin or Ethereum, nodes discover and communicate with peers through a gossip protocol. The attacker floods the victim's connection slots with malicious nodes under their control, effectively "eclipsing" it from the legitimate network. This isolation is the prerequisite for subsequent exploits, such as double-spending or selfish mining, as the victim can only see transactions and blocks provided by the attacker.
The attack leverages specific vulnerabilities in a node's peer management. Key vectors include the manipulation of a node's peer table—the list of known network addresses it uses to find connections. An attacker can poison this table by repeatedly connecting to the victim with many IP addresses, causing the victim to evict honest peers and remember the attacker's addresses. Furthermore, weaknesses in the process for discovering new peers, often via DNS seeds or a fixed list of bootnodes, can be exploited to ensure the victim only connects to malicious entities upon restart.
Once eclipsed, the victim node operates in a fabricated reality. The attacker can present a fake blockchain that diverges from the canonical chain, perhaps showing invalid transactions as confirmed. This enables double-spending: the attacker can send a transaction to the victim (e.g., for goods or services), have the victim see it confirmed on the fake chain, and then broadcast a conflicting transaction to the real network that spends the same funds elsewhere. Because the victim is isolated, it remains unaware of the conflicting transaction and the real chain's progress.
Mitigating eclipse attacks involves hardening a node's peer selection logic. Core defenses include: inbound/outbound connection limits to prevent takeover, randomized peer selection to avoid predictable patterns, anchor connections that are hard to displace, and diversified peer discovery sources. Modern clients like Bitcoin Core and Geth implement these countermeasures, making large-scale eclipse attacks significantly more resource-intensive and difficult to execute on well-connected nodes, though the threat remains a fundamental consideration in P2P network design.
Key Characteristics of an Eclipse Attack
An Eclipse Attack is a network-level attack where an adversary isolates a specific node by monopolizing all its incoming and outgoing connections with malicious peers. This prevents the victim from seeing the legitimate state of the network.
Network-Level Isolation
The core goal is to isolate a single node from the honest network. The attacker floods the victim's peer table with controlled IP addresses, ensuring all inbound and outbound connections are to malicious nodes. This creates a false, attacker-controlled view of the blockchain.
Prerequisites & Cost
Executing this attack requires significant resources:
- IP Addresses: The attacker must control many IPs to fill the victim's peer slots (e.g., Bitcoin's default is 125).
- Bandwidth: High bandwidth is needed to establish and maintain connections.
- Sybil Attack: The attacker creates many fake node identities (Sybil nodes) to appear as distinct peers.
Primary Attack Vectors
Once eclipsed, the victim is vulnerable to:
- Double-Spending: The attacker can feed the victim a fraudulent blockchain where a spent UTXO appears unspent, tricking it into accepting invalid transactions.
- Nakamoto Consensus Disruption: Isolating mining nodes can disrupt block propagation, giving the attacker a mining advantage.
- Denial-of-Service (DoS): By controlling all data, the attacker can simply starve the node of new blocks and transactions.
Defense Mechanisms
Protocols implement several countermeasures:
- Outbound Connection Randomization: Nodes initiate connections to random peers from a hardcoded list of DNS seeds.
- Anchor Connections: Persistent connections to trusted peers that are difficult to displace.
- Incoming Connection Limits & Diversity: Rules to ensure peer IPs come from diverse network ranges.
- Peer Authentication: Using node IDs makes it harder to spoof multiple identities from one IP.
Real-World Example & Impact
A notable case was the Ethereum Eclipse Attack in 2016, which affected the Geth and Parity clients. Researchers demonstrated they could eclipse a node with just two hosts, exploiting vulnerabilities in the peer discovery and eviction logic. This led to significant code changes in Ethereum's DevP2P protocol.
Related Concepts
- Sybil Attack: Creating many fake identities to gain disproportionate influence. Eclipse attacks are a specific application of a Sybil attack.
- 51% Attack: Controlling majority hash power to rewrite history. An eclipse attack can be a precursor.
- BGP Hijacking: A network-level attack at the ISP routing layer that could facilitate eclipse conditions.
- Peer-to-Peer (P2P) Networking: The underlying network architecture being exploited.
Primary Goals of an Eclipse Attack
An Eclipse Attack is a network-level attack where an adversary isolates a specific node by controlling its peer connections. The attacker's goals are not to disrupt the entire network, but to manipulate the victim's view of the blockchain for specific, exploitative purposes.
Double-Spending
The primary financial goal. By isolating a victim node (e.g., an exchange or merchant), the attacker can:
- Create a conflicting transaction that spends the same UTXO/balance.
- Broadcast one version to the eclipsed victim, making them believe the payment is valid.
- Broadcast a different version to the honest network, ensuring their own funds are not spent.
- The victim releases goods or services based on the invalid transaction they accepted.
N-Confidence Fraud
Exploiting the concept of transaction finality. Many services wait for 'N' confirmations. The attacker:
- Mines a private chain in isolation from the victim.
- Shows the victim a transaction with the required number of confirmations on their fake chain.
- Once the victim acts (e.g., releases crypto), the attacker releases their longer, alternative chain to the main network, reorganizing the blockchain and erasing the victim's transaction.
Denial-of-Service (Targeted)
A non-financial goal to censor or disable a specific network participant. By eclipsing a node (often a mining pool or validator), the attacker can:
- Block all incoming transactions from reaching the victim, censoring their ability to participate.
- Prevent block or attestation propagation from the victim, reducing their rewards or causing slashing in Proof-of-Stake systems.
- This can be used to gain a competitive advantage or to target a specific entity.
Preparation for 51% Attacks
An Eclipse Attack can be the first stage in a larger 51% (Majority) Attack. The attacker eclipses one or more mining pools or large validators.
- This artificially reduces the honest hashing/staking power visible on the main network.
- The attacker can then execute a chain reorganization with less than 50% of the real total power, as the eclipsed honest power is not contributing to the public chain.
- It's a force-multiplier for other consensus attacks.
Data Theft or Manipulation
Aims to gain unauthorized access or feed false data. By controlling all peer connections, the attacker acts as a man-in-the-middle.
- Can intercept unencrypted traffic from the victim node.
- May feed the victim spoofed data about mempool transactions, network state, or oracle prices to influence their off-chain decisions.
- This is particularly relevant for DeFi protocols or bots that rely on real-time, unverified network data.
Undermining Light Clients & Wallets
Targets simplified payment verification (SPV) clients and light wallets that rely on a small set of full nodes. The attacker:
- Eclipses the light client by posing as its only peer connections.
- Can provide fraudulent block headers and merkle proofs for non-existent or invalid transactions.
- Causes the wallet to display incorrect balances or confirm fake payments.
- This exploits the inherent trust assumption light clients have in their connected peers.
Eclipse Attack vs. Sybil Attack
A comparison of two distinct network-level attacks that target a node's peer connections and network view.
| Feature | Eclipse Attack | Sybil Attack |
|---|---|---|
Primary Target | Individual Node | Entire Network |
Attack Vector | Peer-to-Peer (P2P) Connections | Node Identity Creation |
Goal | Isolate a single node to manipulate its view | Gain disproportionate influence over network consensus or routing |
Resource Requirement | Moderate (control of IP addresses) | High (control of many node identities, often via IPs or stake) |
Key Mitigation | Random peer selection, outgoing connection rules | Costly identity creation (Proof-of-Work, Proof-of-Stake) |
Commonly Associated With | Blockchain P2P networks (Bitcoin, Ethereum) | Distributed systems, reputation systems, some consensus mechanisms |
Impact on Victim | Censorship, double-spend against the victim | Network partition, consensus manipulation, data availability issues |
Security Considerations & Mitigations
An Eclipse Attack is a network-level attack where an adversary isolates a specific node by monopolizing its peer connections, controlling the information it receives and potentially forcing it onto a fraudulent view of the blockchain.
How It Works
The attacker floods the target node's peer table with malicious nodes under their control. By monopolizing all incoming and outgoing connections, the attacker eclipses the honest network. The isolated node then only sees blocks and transactions the attacker chooses to relay, enabling double-spend attempts or manipulation of decentralized applications (dApps).
Primary Attack Vectors
Key methods include:
- IP Address Manipulation: Exploiting the node's peer discovery to fill its peer list with attacker-controlled IPs.
- Sybil Attack: Creating a large number of fake node identities to overwhelm the target's connection slots.
- Birthday Attack: Targeting a node when it first joins the network, before it establishes trust with honest peers.
Core Mitigations
Protocol-level defenses are critical:
- Strict Peer Selection: Using criteria like proof-of-work in node IDs (as in Bitcoin's Erebus resistance) to make Sybil attacks costly.
- Outbound Connection Diversity: Nodes initiate connections to a random, diverse set of peers, making complete isolation harder.
- Anchor Connections: Maintaining persistent connections to known, trusted nodes to ensure a link to the honest network.
Impact on Consensus & dApps
While an eclipse does not directly break the global consensus, it enables powerful secondary attacks:
- Selfish Mining: The attacker can mine blocks in secret on the isolated node's view.
- Double-Spend: The node may accept a transaction that is later reversed on the main chain.
- dApp Manipulation: The node's smart contract interactions are based on fraudulent state data, leading to financial loss.
Client Implementation Best Practices
Node software can implement several defenses:
- Random Peer Sampling: Regularly refreshing the peer list from DNS seeds or hardcoded bootstrap nodes.
- Inbound Connection Limits: Restricting the percentage of connections a single IP or subnet can occupy.
- Monitoring & Alerts: Tracking peer diversity and geolocation to detect anomalous isolation patterns.
Related Network Attacks
Eclipse attacks are part of a broader class of network-layer attacks:
- BGP Hijacking: Intercepting internet traffic at the ISP level to reroute a node's connections.
- Sybil Attack: The foundational attack of creating many fake identities, which enables eclipse conditions.
- Timejacking: Manipulating a node's network time to disrupt its consensus rules, often paired with an eclipse.
Notable Examples & Research
While often discussed theoretically, real-world eclipse attacks have been demonstrated in research and have targeted live networks, highlighting the importance of robust peer-to-peer protocols.
Light Client Vulnerabilities
Light clients (or SPV clients) are particularly susceptible to eclipse attacks because they connect to a small number of full nodes. A successful eclipse can feed the light client fraudulent blockchain data. Solutions like Fraud Proofs (as proposed for Ethereum) and Non-Interactive Proofs of Proof-of-Work (NIPoPoWs) aim to allow light clients to verify chain validity without trusting a small set of peers.
The Sybil Attack Prerequisite
An eclipse attack fundamentally relies on a Sybil attack, where an adversary creates a large number of fake identities (nodes). To eclipse a victim, the attacker must control enough Sybil nodes to fill the victim's peer slots. Defenses focus on making Sybil attacks costly, often through Proof-of-Work in peer discovery (like Ethereum's Discv4/5) or Proof-of-Stake mechanisms for network participation.
Frequently Asked Questions
An eclipse attack is a network-level attack on a blockchain peer. These questions cover its mechanics, risks, and defensive strategies.
An eclipse attack is a network-level attack where a malicious actor isolates a specific node from the honest peer-to-peer network by monopolizing all its incoming and outgoing connections. The attacker floods the victim node's connection slots with sybil nodes under their control, creating a fabricated view of the blockchain state. This allows the attacker to double-spend against the victim, censor transactions, or waste the victim's computational resources by feeding them invalid blocks. Unlike a 51% attack which targets the global consensus, an eclipse attack targets an individual node's local network perception.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.