Eclipse Attacks on P2P Networks

An eclipse attack is not a consensus bug. It is a routing bug that creates the preconditions for every consensus bug. If an adversary controls all inbound and outbound connections of a target validator, that validator can be fed a fabricated view of the chain at trivial cost. This note explains how we reproduce eclipses in adversarial testnets and what mitigations survive the test.

Attack model

The attacker does not need to break signatures or stake. They need addresses. By spinning up enough nodes in the same IP buckets as a victim, an attacker can crowd out honest peers. In protocols that use deterministic peer selection, the attacker can often precompute exactly which addresses to announce. The goal is to surround the victim so that every block, vote, and transaction passes through attacker-controlled relays.

Why it matters for consensus

Once eclipsed, a validator can be:

• Partitioned from the main chain and made to vote on a stale fork.
• Fed a private chain with higher total difficulty or weight.
• Induced to waste resources validating an isolated subnetwork.
• Blinded to a censorship attack against its own transactions.

The eclipse is usually the first step; the second step is a double-sign or a long-range fork.

Practical reproduction

Our internal testnet uses a controllable P2P simulator. We seed the victim with a small set of bootstrap peers, then flood the network with attacker nodes that share the victim’s IP prefix. We do not break the protocol; we simply become the better peer. A naive implementation often falls into the eclipse within minutes because peer selection optimizes for low latency and high uptime, both of which the attacker can fake.

Defences that work

Outbound diversity

A validator should maintain outbound connections to peers chosen from independent buckets: different IP prefixes, different ASNs, different geographic regions if known. One peer per bucket is a practical lower bound. Never allow all outbound slots to be filled by the same /24.

Randomised peer selection

Deterministic selection by ping time is exploitable. Use a weighted random function with a bias toward long-lived, previously honest peers. An attacker can still win some slots, but cannot guarantee a monopoly.

Feeler connections

Periodically open short-lived connections to randomly chosen addresses, measure their view of the chain, and compare it against the current best tip. If a peer reports a divergent tip that no one else sees, flag it.

Peer eviction with churn

Do not wait for an attacker to misbehave before replacing a peer. Active churn — dropping a random fraction of peers and replacing them from the address book — prevents an attacker from amortising the cost of the attack over a long session.

Anchor peers

Maintain a small set of manually configured or historically trustworthy peers that cannot be evicted. These are not a replacement for decentralisation, but they are a safety net against a rapid eclipse.

What does not work

• Connection count alone. A thousand connections to a thousand attacker nodes is not diversity; it is a thousand attacker nodes.
• Reputation without churn. Long-lived reputation scores let an attacker invest once and exploit forever.
• IP-only bucketing. IPv6 and NAT traversal can collapse many attacker addresses into a single physical host.

Closing note

P2P security is the hardest part of Layer-1 assurance because it lives outside the elegant math of consensus. A perfectly correct BFT protocol fails if it cannot receive an honest message. Treat the P2P layer as part of the trust boundary, not as plumbing.