A blockchain's consensus rules only protect a node that can see the real network. An eclipse attack targets that visibility instead of the cryptography: the adversary surrounds one node with dishonest peers until everything the node sees is a lie. This note walks through the mechanics and the defenses, based on experiments in our network simulator.
The attack, step by step
- Mapping. The adversary crawls the peer-to-peer network to learn which addresses a target node might connect to.
- Flooding. The adversary spins up many nodes — often on many IP addresses — and waits for the target to make its routine outbound connections, which naturally land on attacker peers.
- Holding. Attacker peers accept the connections, keep them alive, and never relay anything honest. If the target also accepts inbound connections, the adversary occupies those slots too.
- Exploiting. The isolated node now sees a filtered view: delayed blocks, censored transactions, or — in the worst case — an entirely fabricated branch of history during a reorg.
Why it works at all
Peer selection was historically simple: keep the connections that work, pick new ones randomly. Randomness fails when the adversary controls a large fraction of the address space a node samples from. IPv4 makes this cheap: one machine can hold thousands of addresses, so "many independent peers" can be a single actor wearing masks.
"You are not defending against a thousand peers. You are defending against one adversary who owns a thousand addresses."
Defenses that actually work
- AddrMan bucketing. Modern clients group candidate addresses into buckets keyed by network group, capping how many addresses from one group can influence selection — the direct countermeasure to address flooding.
- Feeler connections. Short-lived probe connections test whether current peers are honest before rotating them in, so eclipse sets get detected and evicted.
- Inbound slot scarcity. Treating inbound connection slots as a scarce resource, with eviction of the oldest or least useful, raises the cost of slot occupation.
- Anchors and diversity. Keeping a few long-lived, manually diversified "anchor" peers across network groups gives a stable, trustworthy backbone.
- Height sanity checks. If every peer reports a chain tip that stops advancing, the node flags its view as suspect and widens its peer search.
What we measured
In our reproducible simulator, a naïve node design with random peer selection could be eclipsed with roughly 250 adversarial addresses. With bucketing plus feeler connections, the same attack needed orders of magnitude more addresses and hours of sustained effort — moving the attack from "cheap" to "detectable." The full experiment configuration is in our public repository.
Takeaway
Eclipse attacks are not magic and not cryptography failures. They are resource games against peer selection, and the winning defenses are boring: structure the address table, probe before trusting, diversify, and sanity-check what you are shown.
This note is educational content about network security. It is not investment, legal, or financial advice, and it discusses no financial products. See our Independence Notice.