6 min read
On this page

Peer-to-Peer Networking

P2P Fundamentals

In peer-to-peer systems, participating nodes (peers) act as both clients and servers, collectively providing services without centralized infrastructure.

P2P Classification

| Generation | Structure | Examples | |-----------|-----------|---------| | Centralized directory | Central index, distributed storage | Napster | | Unstructured | Flooding/gossip for discovery | Gnutella, Kazaa | | Structured (DHT) | Deterministic key-to-node mapping | Chord, Kademlia, Pastry | | Hybrid | Supernode architecture | Skype (legacy), Kazaa |

Structured P2P: Distributed Hash Tables

DHTs provide a decentralized key-value lookup service with guaranteed bounds on routing hops and storage load.

Common Properties

  • Each node assigned an identifier from the same space as keys (typically 160-bit).
  • Each key is assigned to a specific node based on a distance metric.
  • Routing tables enable O(log N) lookup hops for N nodes.
  • Nodes join/leave with O(log^2 N) messages for maintenance.

Chord

Chord (Stoica et al., 2001) arranges nodes on a circular identifier space [0, 2^m - 1].

Key Assignment

Key k is assigned to the first node whose ID >= k (called the successor of k).

Identifier ring (m=6, IDs 0-63):

        0
      /    \
   56       8
   |         |
  48    ←    16
   |         |
   40      24
      \   /
       32

Node 8 is responsible for keys (1, 2, ..., 8)
Node 16 is responsible for keys (9, 10, ..., 16)

Finger Table

Each node maintains m entries. The i-th finger of node n points to the successor of (n + 2^i) mod 2^m.

Node 8's finger table (m=6):
  finger[0]: successor(9)   → covers [9, 10)
  finger[1]: successor(10)  → covers [10, 12)
  finger[2]: successor(12)  → covers [12, 16)
  finger[3]: successor(16)  → covers [16, 24)
  finger[4]: successor(24)  → covers [24, 40)
  finger[5]: successor(40)  → covers [40, 72 mod 64 = 8)

Lookup Algorithm

lookup(key):
  if key is between (self, successor]:
    return successor
  else:
    forward to closest preceding finger
  • O(log N) hops per lookup (each hop covers at least half the remaining distance).
  • Successor list (not just one successor) provides fault tolerance.

Stabilization

Periodic background process to maintain correct successor/predecessor pointers and finger tables as nodes join and leave:

  1. Each node periodically asks its successor for the successor's predecessor.
  2. If that predecessor is between the node and its successor, adopt it as new successor.
  3. Notify the new successor to update its predecessor pointer.
  4. Periodically refresh finger table entries.

Kademlia

Kademlia (Maymounkov & Mazieres, 2002) uses XOR distance metric. Used by BitTorrent DHT, Ethereum, and IPFS.

XOR Distance

d(x, y) = x XOR y

Properties:
  - d(x, x) = 0
  - d(x, y) = d(y, x)     (symmetric — unlike Chord)
  - d(x, z) <= d(x, y) + d(y, z)  (triangle inequality)

Symmetry means every lookup brings useful routing information to both parties.

k-Buckets

Each node maintains a routing table of 160 k-buckets (for 160-bit IDs):

  • Bucket i holds up to k contacts whose distance from the node has the i-th bit as the most significant set bit.
  • k is a redundancy parameter (typically k = 20).
  • Entries ordered by last-seen time; most recently seen at the tail.
Bucket 0: nodes at distance [1, 2)           — closest
Bucket 1: nodes at distance [2, 4)
Bucket 2: nodes at distance [4, 8)
...
Bucket 159: nodes at distance [2^159, 2^160) — farthest

Kademlia RPCs

| RPC | Purpose | |-----|---------| | PING | Check if a node is alive | | STORE | Store a (key, value) pair at a node | | FIND_NODE | Return k closest nodes to a given ID | | FIND_VALUE | Like FIND_NODE, but return value if the node has it |

Iterative Lookup

1. Pick alpha closest nodes from local routing table (alpha = 3)
2. Send FIND_NODE RPCs to them in parallel
3. From responses, select alpha closest not yet queried
4. Repeat until k closest nodes have been queried
5. Return the k closest nodes found
  • Parallelism (alpha concurrent RPCs) reduces latency.
  • Lookup completes in O(log N) steps.

Pastry

Pastry (Rowstron & Druschel, 2001) routes based on prefix matching of hexadecimal node IDs.

Routing Table

Each row i contains 15 entries (one per hex digit except self's digit at position i), pointing to a node sharing the first i digits with the current node but differing at digit i+1.

Node ID: 10233102

Row 0: 0_______, 2_______, 3_______, ..., f_______
Row 1: 11______, 12______, 13______, ..., 1f______
Row 2: 100_____, 101_____, 103_____, ..., 10f_____
Row 3: 1020____, 1021____, 1023____, ..., 102f____
...
  • Each routing step resolves at least one more hex digit.
  • O(log_{16} N) hops with a routing table of O(log_{16} N) rows x 15 entries.
  • Also maintains a leaf set (L/2 closest nodes on each side) for reliable delivery.

DHT Operations

PUT/GET

PUT(key, value):
  1. Hash content to produce key
  2. Route to node responsible for key
  3. Store (key, value) at that node and r replicas

GET(key):
  1. Route to node responsible for key
  2. Retrieve and return value

Replication Strategies

| Strategy | Description | |----------|-------------| | Successor replication | Store at r successive nodes in the ring | | Symmetric replication | Store at multiple points in ID space | | Caching | Cache results along the lookup path |

Churn Handling

  • Nodes join/leave constantly (churn) in real-world P2P systems.
  • Periodic stabilization protocols repair routing tables.
  • Replication ensures data survives node departures.
  • Aggressive churn (>50% turnover per hour) degrades DHT performance significantly.

BitTorrent

BitTorrent is the most successful P2P file-sharing protocol, using swarming for efficient content distribution.

Architecture

Tracker / DHT (peer discovery)
         |
   +-----+-----+
   |     |     |
 Peer1 Peer2 Peer3  (swarm)
   sharing pieces of the same file

Key Mechanisms

| Mechanism | Description | |-----------|-------------| | Piece selection | Rarest-first — download rarest pieces first to maximize availability | | Choking | Upload to top-k peers with best download rates (tit-for-tat) | | Optimistic unchoking | Periodically unchoke a random peer to discover faster partners | | Endgame mode | Request final pieces from multiple peers to avoid tail latency |

Incentive Design

  • Tit-for-tat reciprocity: peers that upload more get better download rates.
  • Free-riders (leechers) are penalized by being choked.
  • Not perfectly strategy-proof (BitTyrant showed strategic manipulation possible).

DHT-Based Trackerless Operation

BitTorrent uses a Kademlia-based DHT (BEP 5) for decentralized peer discovery:

  • Infohash of the torrent serves as the DHT key.
  • Peers announce themselves by storing their contact info at nodes close to the infohash.
  • get_peers queries find peers for a given infohash.

Blockchain Networking

P2P Network Layer

Blockchain networks use unstructured P2P overlays for block and transaction propagation.

| Aspect | Bitcoin | Ethereum | |--------|---------|----------| | Discovery | DNS seeds + addr messages | Discovery v4/v5 (Kademlia-based) | | Topology | Random graph (~8 outbound connections) | Random graph (~25 peers) | | Propagation | Flooding with inv/getdata | Gossip (devp2p) | | Transport | TCP | TCP (RLPx encrypted) |

Block Propagation Optimization

  • Compact blocks (BIP 152): Send block header + short transaction IDs; receiver reconstructs from mempool.
  • Relay networks (FIBRE): Low-latency relay between miners using UDP + FEC.
  • Graphene: Bloom filter + IBLT encoding achieves ~10x compression over compact blocks.

IPFS (InterPlanetary File System)

IPFS is a content-addressed, peer-to-peer distributed file system.

Core Components

Application Layer
     |
Naming (IPNS — mutable pointers via public keys)
     |
Merkle DAG (content-addressed data structure)
     |
Exchange (Bitswap — block exchange protocol)
     |
Routing (Kademlia DHT for peer and content discovery)
     |
Network (libp2p — modular networking stack)

Content Addressing

  • Files split into blocks, each identified by its cryptographic hash (CID — Content Identifier).
  • CIDv1 format: <multibase><version><multicodec><multihash>
  • Deduplication is automatic: identical content always produces the same CID.
  • Content is immutable by definition; IPNS provides mutable names.

Bitswap Protocol

  • Peers maintain want-lists (blocks they need) and exchange blocks directly.
  • Credit-based system: peers track bilateral ledgers of bytes exchanged.
  • Peers that contribute more receive better service (incentive compatibility).

libp2p

libp2p is a modular networking stack extracted from IPFS, now used by many P2P projects.

Module Categories

| Module | Function | Implementations | |--------|----------|----------------| | Transport | Connection establishment | TCP, QUIC, WebSocket, WebRTC | | Security | Encryption and authentication | TLS 1.3, Noise | | Multiplexing | Multiple streams per connection | yamux, mplex | | Peer Discovery | Finding peers | mDNS, Kademlia, Rendezvous | | Pubsub | Topic-based messaging | GossipSub, FloodSub | | NAT Traversal | Connectivity behind NAT | AutoNAT, Circuit Relay, hole punching |

GossipSub

Publish-subscribe protocol used by Ethereum 2.0 and Filecoin:

  • Maintains a mesh of D peers per topic (D typically 6).
  • Full messages sent within the mesh (eager push).
  • Metadata (IHAVE) gossiped to non-mesh peers; they request (IWANT) if interested.
  • Peer scoring system penalizes misbehavior (spam, invalid messages).
  • Flood publishing ensures high reliability for own messages.