Ethereum P2P eclipse attacks

Goal

Understand Ethereum's peer-to-peer neighbor discovery (geth ≈ v1.8.0 era) and why the network layer could be eclipsed. These are study notes on the paper Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network (eprint 2018/236).

Overview

An eclipse attacker monopolizes a victim's incoming and outgoing peer connections, isolating that node from honest peers. From there the attacker can filter the victim's view of the chain or bend the victim's hashpower into a larger strategy (double-spend, selfish mining, and related).

The paper's claim that mattered: against pre-1.8 geth, this did not require a botnet. Two hosts, each with one IP, could be enough — off-path, without sitting on the victim's route.

Bitcoin and Ethereum both use PoW-era consensus ideas, but the networks differ. Bitcoin leans on an unstructured random graph; Ethereum borrowed Kademlia DHT structure for discovery. Bitcoin nodes default to fewer outgoing edges; Ethereum opened more. Ethereum also authenticates many P2P messages cryptographically. That looks harder to eclipse — until node identity is cheap to mint.

Root cause (pre-geth v1.8)

Nodes were identified by ECDSA public keys. Generating a new key is trivial, so an attacker could mint thousands of node IDs quickly. Before geth v1.8, many node IDs could share one IP.

Peer selection was also biased in ways an attacker could predict: some IDs were more likely to be chosen than others. An adversary could craft IDs the victim preferred over honest peers.

So the cheap resource was not bandwidth or BGP — it was key generation plus table poisoning.

Kademlia inheritance

Ethereum's discovery protocol inherited Kademlia-style XOR distance and buckets. Classic Kademlia stores content near keys; Ethereum mainly needed peer discovery. Every full node already stores the chain. The DHT machinery mostly fills routing tables, not content lookups — except in rare cases (static NodeID without IP, empty IP field) where iterative lookup still runs.

That mismatch mattered: formal hop guarantees from content DHTs do not automatically buy eclipse resistance when the only "content" everyone wants is peers.

Off-path patterns (conceptual)

Paper taxonomy (high level):

1. Connection monopolization. After a victim reboot, attacker-controlled peers fill incoming slots. If every slot is theirs, the victim is eclipsed.
2. Table ownership. Even if clients force a mix of incoming and outgoing links, carefully chosen pings can bias the routing table so that after reboot the victim's outgoing dials land on attacker IDs. Remaining slots are then filled inbound.
3. Clock skew. If a host clock runs far ahead of the network (for example via NTP manipulation), the node can be isolated by time checks other peers enforce.

Mitigations argued in the paper and partially shipped in geth v1.8 (2018-02-14): stop treating ECDSA keys alone as uniform node identity; bind identity to IP+key; diverge from naive Kademlia assumptions where they hurt blockchain P2P.

Why eclipse matters

Consensus. An eclipsed miner or validator can be steered into double-spend or selfish-mining strategies.

Layer-2 channels. Payment-channel safety assumes parties see channel-close transactions. An eclipsed merchant can believe a channel is still open after it closed on the honest network.

Smart contracts. Contracts that depend on pending state are unsafe if different users see inconsistent chain views. A toy auction with a bid-count gate is enough to show the shape: Alice signs a bid under a stale view; the non-eclipsed network already moved the counter past the gate.

Network machinery (geth-era)

Discovery is RLPx Node Discovery Protocol v4. Distance is XOR on NodeIDs. Buckets store peers by distance. Seeding runs on reboot, hourly, or when lookup() hits an empty table — bonding to bootstrap / recent DB peers, then lookup(self).

Outgoing TCP peers are chosen from lookup buffers and tables under a task runner (discover_task / dial_task) with concurrency limits and dial checks (not self, not blacklisted, not recently dialed, and so on).

The eclipse-relevant hinge: seeding does little when the table is already non-empty. A poisoned table survives across the moments when a clean bootstrap would have helped.

Takeaway

Ethereum looked more eclipse-resistant than Bitcoin on paper (more outgoing peers, authenticated control messages) and still fell to low-resource eclipses while node IDs were free ECDSA keys unbound to IP. Consensus security sits on P2P assumptions; when those assumptions fail, double-spend and channel logic fail with them. geth v1.8 absorbed several of the paper's hardening ideas — the historical lesson is that discovery design is consensus-adjacent, not plumbing.

References

• https://eprint.iacr.org/2018/236.pdf
• https://ieeexplore.ieee.org/document/7467362
• https://dl.acm.org/doi/10.1145/2810103.2813655