Peer Discovery and Networking

A new node knows nothing about the network. Getting from that state to synchronised participation involves a discovery process that is worth understanding.

The bootstrap

Hardcoded bootstrap nodes. Client software ships with a list of stable nodes to contact first. These provide initial peers.

This is a centralisation point, and it is a small one: if the bootstrap nodes were unavailable, a new node could still be given peers manually.

Peer exchange. Once connected to any peer, a node learns about others. The peer set grows from there.

Discovery protocols. Most networks use a structured discovery mechanism that lets nodes find peers with particular characteristics, such as those serving a specific subnet.

Maintaining connections

A node maintains a target number of peers, typically a few dozen. Connections drop and are replaced continuously.

Peers are scored on behaviour. A peer sending invalid data or failing to respond is disconnected and may be banned temporarily.

The adversarial dimension

Eclipse attacks. An attacker fills a victim node’s peer slots with nodes they control, isolating it from the real network. The victim then sees only what the attacker shows it.

Defences include diversifying peers across network ranges, reserving slots for outbound connections the node initiates, and anchoring to known-good peers.

Sybil attacks. Creating many identities to influence the peer graph. Mitigated by making identity creation costly or by weighting by other signals.

Transaction censorship at the network layer. A node surrounded by hostile peers may find its transactions not propagating. Broadcasting through multiple routes mitigates this.

Why this matters for a light client

A light client verifies proofs against headers it receives. If it receives headers only from an attacker, it can be shown a fabricated chain.

That is why light client designs emphasise connecting to multiple independent sources, and why sync committee mechanisms that let a client verify a small set of signatures are a meaningful improvement.

The practical relevance

For an operator, peer connectivity is the most common cause of a node appearing to be stuck. A node with too few peers syncs slowly or not at all, and the fix is usually checking that inbound connections are reachable.

For a user of someone else’s node, none of this is visible, which is the point. You are trusting that their peer set is honest, along with everything else you are trusting them for.

That is the argument for running your own, and for the portion of holdings where that is impractical, the argument for a counterparty you have chosen deliberately, such as exchanges that let you specify the network, rather than an endpoint you never selected.