Eclipse attacks target a single blockchain node by surrounding it with attacker-controlled peers, so that every message it receives passes through the attacker first. The victim still runs correct software, but its picture of the network is filtered, delayed, or fabricated.
This guide explains how nodes choose peers, how an eclipse is set up at a conceptual level, what an attacker can achieve with an isolated node, and which signs and defenses matter most. It is written for node operators, wallet and exchange engineers, and anyone who relies on a single node for blockchain data.
When a Node Sees Only What the Attacker Allows
A blockchain node has no central server to consult. It learns about new blocks and transactions only from the peers it is connected to. If all of those peers are honest, the node sees the real chain. If all of them belong to one adversary, the node sees whatever that adversary chooses.
That is the essence of an eclipse. The name refers to an object passing in front of the sun: the victim is still running, but the light of the honest network no longer reaches it. Nothing about cryptography fails. The attacker exploits the trust the node places in its own peer list.
The danger is quiet. An eclipsed node does not crash or display an alarm by default. It keeps validating whatever blocks arrive, and those blocks may be perfectly valid by protocol rules. The problem is what the node is missing: newer blocks, competing chains, or transactions the attacker has decided to hide.
How Nodes Find and Keep Their Peers
To understand the attack, it helps to know how peer discovery works. A new node usually starts by contacting a list of seed addresses or DNS seeds that the client software ships with. Those seeds return addresses of other nodes, which the new node stores and tries to connect to.
Over time, each node builds an address table, which is a local database of peers it has heard about. Nodes share addresses with each other, so the table grows as the node participates. When the node needs a new connection, it picks addresses from this table.
Nodes typically make outbound connections, which they initiate themselves, and accept inbound connections from others. Ethereum clients use a discovery protocol based on a distributed hash table, while Bitcoin relies on address gossip. In both designs, whoever influences the address table and the open connection slots influences what the node sees.
Anatomy of an Eclipse Attack
At a conceptual level, an eclipse attack has a few stages. The details vary by client and network, and modern software has added many countermeasures, but the general pattern helps defenders understand what to protect.
Polluting the Address Table
The attacker first tries to make its own addresses dominate the victim’s address table. This usually means operating many nodes or announcing many addresses, which links the eclipse to the broader Sybil problem. If most stored addresses belong to the attacker, any new connection the victim makes is likely to land on an attacker node.
Waiting for a Reconnection Window
A node with established honest connections is hard to isolate. Attackers therefore benefit when the victim restarts, loses connectivity, or rotates peers. At that moment, the node draws fresh addresses from its table. Restarts after software updates or crashes are routine events, which is why defenses focus heavily on what happens during startup.
Occupying Every Slot
The final stage is controlling all outbound and inbound connections. Once every peer belongs to the attacker, the victim is fully isolated. Partial control is still harmful, but full control lets the attacker decide exactly which blocks and transactions reach the node and which of its own broadcasts ever leave it.
What an Attacker Can Do With an Eclipsed Node
Isolation is rarely the goal in itself. It is a stepping stone to other attacks that would be much harder against a well-connected node. The value depends on who runs the victim node and what decisions depend on its data.
- Double spending against a merchant: show the victim a payment that never reaches the honest chain.
- Wasting mining or validator effort: keep a miner working on an outdated chain tip.
- Amplifying selfish mining: split honest hashing power by feeding different views to different miners.
- Censoring transactions: silently drop the victim’s outgoing transactions so they never propagate.
- Feeding stale data: delay new blocks so price-sensitive or time-sensitive actions use outdated state.
Most of these outcomes require the attacker to keep the eclipse running for some time and, in several cases, to control meaningful mining or staking resources as well. That combination of cost and effort explains why high-value nodes are the realistic targets.
Eclipse Attacks Versus Sybil Attacks
The two terms are often confused because they share tools. A Sybil attack is about one entity controlling many identities in a network. An eclipse attack is about isolating one specific victim. Many fake identities can help achieve an eclipse, but the goals are different.
A Sybil attack aims at the network as a whole, for example by trying to sway a vote or a reputation system. An eclipse aims at a single node’s view of reality. An attacker could, in theory, eclipse a node using a modest number of well-placed peers if the victim’s connection logic is weak.
The distinction matters for defense. Sybil resistance at the consensus layer, such as proof of work or proof of stake, does not stop an eclipse, because peer connections are not weighted by hash power or stake. Eclipse protection comes from how a node selects, keeps, and verifies its peers.
Why Light Clients and Wallet Backends Are Attractive Targets
Light clients do not download and verify every block. They rely on full nodes to supply block headers and proofs, such as Merkle proofs showing that a transaction is included in a block. If every full node a light client contacts is malicious, the client has limited ability to detect deception.
Wallet backends face a similar problem. A mobile wallet may depend on a small set of servers run by its developer. If those servers or their own node connections are eclipsed, every user of that wallet may see incorrect balances or confirmations at once.
The mitigation is redundancy. Light clients and wallet backends should query several independent sources, compare chain tips and header chains, and treat disagreement as a reason to pause rather than proceed. Developers building such services should document which nodes they rely on and how those nodes are hardened.
Eclipse Risks in Proof of Stake Networks
Proof of stake networks are not immune. A validator that is eclipsed may miss attestations or block proposals, which can lead to reduced rewards or, in some designs, penalties for inactivity. The validator also cannot see slashable behavior by others if its view is filtered.
New or long-offline nodes face an extra risk related to weak subjectivity. In many proof of stake systems, a node that has been offline for a long time needs a recent trusted checkpoint to know which chain is correct. An eclipsed node at that moment could be steered toward a fake history.
That is why proof of stake clients encourage starting from a checkpoint obtained from several trusted sources, rather than from whatever peers the node meets first. Operators should verify checkpoints against multiple independent references, and they should follow their client’s documentation for the exact process on their network.
Warning Signs That a Node May Be Eclipsed
Because eclipses are quiet, detection relies on monitoring. A node operator who watches a few simple indicators can often notice that something is wrong long before a costly decision is made on stale or manipulated data.
- The node’s best block falls behind the height reported by independent sources.
- Peer count is normal, but nearly all peers share a small set of network ranges or hosting providers.
- Outgoing transactions are not visible on independent block explorers after a reasonable time.
- Block arrival becomes irregular, with long gaps followed by sudden bursts.
- Peer churn changes sharply, such as many new inbound peers appearing at once.
None of these signs proves an attack on its own. Network outages and client bugs can produce similar symptoms. Treat them as triggers for investigation: compare against other nodes you control, check external sources, and hold high-value actions until the node’s view is confirmed.
Client-Level Defenses Built Into Node Software
Client developers have responded to published research by changing how peer selection works. Academic work demonstrated eclipse techniques against both Bitcoin and Ethereum clients, and both ecosystems adopted countermeasures. Keeping node software up to date is therefore the single most important defense for most operators.
Common client protections include bucketing stored addresses by network group so that one range cannot fill the table, limiting how much a single peer can add, and preserving a set of anchor connections across restarts. Some clients also maintain extra connections that relay only blocks, which are harder to fingerprint and disrupt.
Other measures include testing old addresses before evicting them, protecting long-lived well-behaved peers from eviction, and supporting encrypted transport so that peers cannot be easily impersonated by network-level attackers. The exact features and settings vary by client, so operators should review release notes when upgrading.
Operator Hardening for Exchanges and Service Providers
Organizations that accept deposits or settle payments are the most valuable eclipse targets. For them, a single node is a single point of failure. Running several nodes in different data centers and network providers, and comparing their views, makes isolation of every node at once far more difficult.
Operators can also configure trusted peer connections to other nodes they control or to well-known partners. These connections act as anchors that an attacker cannot easily displace. Firewalls and rate limits help prevent a flood of inbound connections from consuming available slots.
Monitoring ties these measures together. Alert on block height divergence between internal nodes, on unusual peer concentration, and on transactions that fail to propagate. Document a response plan so that staff know when to halt deposits or withdrawals and how to restore a node’s connections safely.
Confirmations, Checkpoints, and Cross-Checks
Even a well-defended node should not be the only source of truth for important decisions. Waiting for more confirmations before crediting a large deposit raises the cost of any deception, because an attacker must produce more valid blocks on a fake branch.
Cross-checking is equally effective. Before releasing goods or funds, a service can confirm that a transaction appears in the chain seen by several independent nodes. If one node disagrees with the others, the service should investigate before acting rather than trusting the majority blindly.
For proof of stake networks, finality offers an additional anchor. Once a block is finalized according to the protocol’s rules, reverting it would require a large share of validators to be slashed. Waiting for finality on high-value transfers is a sensible default, though the timing varies by network.
Keeping Your Node’s View of the Network Honest
For an individual running a personal node, the practical steps are simple. Keep the client updated, avoid restarting it unnecessarily, allow inbound connections if your network permits, and compare your chain height occasionally with an independent source you trust.
For teams running infrastructure, treat peer connectivity as a security control rather than a networking detail. Diversify hosting, use anchor peers, monitor divergence, and rehearse what to do when a node falls out of sync. These habits protect against honest outages as well as deliberate attacks.
Looking ahead, encrypted peer transport, better discovery protocols, and wider use of light-client proofs will continue to raise the cost of eclipses. Even so, no network can promise that isolation is impossible. A node that knows how to doubt its own view is the strongest defense available.