Peer To Peer Model - Learning Module

Loading content...

0/228

P2P Protocols

Beyond File Sharing

While file sharing demonstrated P2P's potential, the paradigm has evolved far beyond exchanging files. Modern P2P protocols power real-time video communication, cryptocurrency networks, decentralized storage systems, and the emerging decentralized web.

Each application domain presents unique challenges that drive protocol innovation. Real-time communication needs low latency; cryptocurrencies need consensus; storage systems need reliability. Understanding these protocols reveals how P2P principles adapt to diverse requirements.

Learning Objectives

By the end of this page, you'll understand: key P2P protocol categories and their design considerations, WebRTC for browser-based P2P, blockchain gossip protocols, IPFS and content-addressed storage, and the engineering tradeoffs shaping modern P2P protocol design.

P2P Protocol Categories

P2P protocols can be categorized by their primary function, though many real systems combine multiple categories:

P2P Protocol Categories
Category	Primary Function	Key Challenge	Examples
Content Distribution	Efficiently distribute files/data	Piece selection, incentives	BitTorrent, IPFS
Real-Time Communication	Low-latency audio/video	NAT traversal, codec negotiation	WebRTC, original Skype
Distributed Storage	Persistent, redundant storage	Reliability, availability guarantees	IPFS, Storj, Filecoin
Consensus/Blockchain	Agreement on shared state	Byzantine fault tolerance	Bitcoin, Ethereum gossip
Messaging/Chat	Private or group communication	Key exchange, metadata privacy	Matrix, Signal (uses P2P ideas)
Computation	Distributed processing	Task allocation, verification	BOINC, Golem

Cross-Cutting Concerns:

Regardless of category, P2P protocols share common challenges:

Peer Discovery — How do nodes find each other initially and continuously?
NAT Traversal — How do peers behind NATs establish direct connections?
Identity and Authentication — How do peers prove identity without central authority?
Message Routing — How do messages reach their intended destination efficiently?
Data Integrity — How do peers verify received data hasn't been tampered with?
Incentive Alignment — How do we ensure peers contribute rather than just consume?

Different protocols prioritize these concerns differently based on their use case. Let's explore key protocols in depth.

Protocol Layering

Many P2P systems layer multiple protocols. IPFS, for example, uses libp2p for transport, Kademlia DHT for content routing, BitSwap for data exchange, and IPLD for data structures. Understanding individual protocols illuminates these larger systems.

WebRTC: Browser-to-Browser P2P

WebRTC (Web Real-Time Communication) enables peer-to-peer audio, video, and data communication directly between web browsers without plugins. It's the technology behind browser-based video conferencing, screen sharing, and file transfer.

Why WebRTC Matters:

Before WebRTC, real-time browser communication required:

Flash/Java plugins (security nightmares)
Server-mediated streams (expensive, high latency)
Custom applications (poor reach)

WebRTC provides native browser APIs for peer-to-peer media, enabling:

Direct peer connections (lowest possible latency)
Encrypted communications (end-to-end by default)
Adaptive quality (codecs adjust to network conditions)
Universal availability (all major browsers)

Converting Mermaid diagram...

WebRTC Architecture Components:

Signaling Server: WebRTC doesn't define how peers find each other—that's left to the application. A signaling server (typically WebSocket-based) exchanges:

Session Description Protocol (SDP) offers/answers describing media capabilities
ICE candidates describing possible connection paths

STUN (Session Traversal Utilities for NAT): STUN servers help peers discover their public IP address and NAT type. When a browser behind NAT contacts a STUN server, the server reports back the source address it sees—the peer's public IP and port.

TURN (Traversal Using Relays around NAT): When direct connection fails (symmetric NATs, firewalls), TURN servers relay traffic. This defeats the P2P purpose somewhat but provides fallback connectivity.

ICE (Interactive Connectivity Establishment): ICE orchestrates the connection process:

Gather candidates (host, server-reflexive, relay)
Check connectivity for each candidate pair
Select best working path
Handle path changes during session

WebRTC Connection Flow
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Simplified WebRTC Connection Setup
 
// Browser A (caller)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: 'stun:stun.example.com' },
        { urls: 'turn:turn.example.com', username: 'user', credential: 'pass' }
    ]
});
 
// Add local stream
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));
 
// Handle ICE candidates
pc.onicecandidate = (event) => {
    if (event.candidate) {
        signalingServer.send({ type: 'candidate', candidate: event.candidate });
    }
};
 
// Create and send offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signalingServer.send({ type: 'offer', sdp: offer.sdp });
 
// Receive answer from Browser B
signalingServer.onMessage = async (msg) => {
    if (msg.type === 'answer') {
        await pc.setRemoteDescription(new RTCSessionDescription(msg));
    } else if (msg.type === 'candidate') {
        await pc.addIceCandidate(new RTCIceCandidate(msg.candidate));
    }
};
 
// Receive remote stream
pc.ontrack = (event) => {
    remoteVideo.srcObject = event.streams[0];
};

Beyond Video Chat

WebRTC DataChannels enable arbitrary data transfer between browsers—file sharing, game state synchronization, collaborative editing, and even P2P CDNs that distribute video using viewer bandwidth. The P2P data dimension is often underutilized.

Blockchain Gossip Protocols

Cryptocurrency networks like Bitcoin and Ethereum rely on P2P protocols to propagate transactions and blocks across thousands of nodes worldwide. Their gossip protocols ensure that all nodes eventually see all data—a requirement for consensus.

The Gossip Model:

Gossip (or epidemic) protocols spread information like a disease:

A node receives new information (transaction, block)
The node sends it to some random subset of neighbors
Each neighbor repeats the process
Information spreads exponentially until all nodes have it

This approach is remarkably robust—even with node failures, adversarial nodes, and network partitions, information still spreads.

Bitcoin P2P Protocol Messages

Protocol

/* Bitcoin P2P Protocol (Simplified) */
 
// Network Discovery
VERSION     // Initial handshake with protocol version
VERACK      // Acknowledgment of VERSION
ADDR        // List of known network addresses
GETADDR     // Request for peer addresses
 
// Block Propagation  
INV         // Inventory - "I have these blocks/transactions"
GETDATA     // Request specific items from INV
BLOCK       // Full block data
HEADERS     // Block headers only (for SPV)
GETHEADERS  // Request header chain
 
// Transaction Propagation
TX          // Full transaction data
MEMPOOL     // Request mempool transactions
 
// Compact Block Relay (BIP 152)
SENDCMPCT   // Enable compact block relay
CMPCTBLOCK  // Compact block (header + short IDs)
GETBLOCKTXN // Request missing transactions
BLOCKTXN    // Missing transactions for compact block
 
/* Propagation Flow */
1. Miner creates new block
2. Miner sends INV to peers: "I have block X"
3. Peers reply GETDATA for block X
4. Miner sends BLOCK containing full block data
5. Peers validate block, add to chain
6. Peers send INV to THEIR peers
7. Process repeats across network
8. Full propagation: ~seconds for global reach

Bitcoin Network Structure:

Full Nodes — Store complete blockchain, validate all transactions and blocks, relay to other nodes
SPV (Light) Clients — Store only block headers, request relevant transactions, trust full nodes for validation
Mining Nodes — Full nodes that also produce new blocks

Propagation Optimizations:

Compact Block Relay (BIP 152): Blocks contain mostly transactions that peers already know (from mempool). Compact blocks send:

Block header
Short transaction IDs (6 bytes vs. 32-byte hashes)
Only novel transactions included

Peers reconstruct full blocks from their mempool + short IDs, dramatically reducing bandwidth.

FIBRE (Fast Internet Bitcoin Relay Engine): A network of well-connected relay nodes using UDP-based transmission and forward error correction to propagate blocks in <100ms globally. Critical for reducing orphan blocks from propagation delays.

Ethereum's Gossip:

Ethereum uses devp2p with Kademlia-based discovery (discv4/discv5). Its gossip protocol handles:

Transactions (eth protocol)
Block announcements and fetching
State synchronization (snap protocol)
Light client serving (les protocol)

Eclipse Attacks on Blockchains

If an attacker controls all of a node's connections, they can feed it a false view of the blockchain—enabling double-spends against that node. Bitcoin defends with diverse outbound connections, IP-based limits, and random peer selection.

IPFS: Content-Addressed Storage

IPFS (InterPlanetary File System) represents the evolution of P2P file sharing into a general-purpose content-addressed distributed file system. Where BitTorrent is optimized for large file distribution, IPFS aims to be a foundational layer for the decentralized web.

The Content Addressing Paradigm:

Traditional web addressing is location-based:

https://example.com/files/document.pdf

This says WHERE to get the file, not WHAT the file is. The server could change the content; the link might break; mirrors need explicit management.

Content addressing is hash-based:

ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco

This says WHAT the content is (its cryptographic hash). The same content always has the same address. Any peer with the content can serve it. The content is self-verifying.

IPFS Protocol Stack

•libp2p — Modular networking layer handling transport, security, stream multiplexing, and peer discovery across multiple protocols (TCP, QUIC, WebRTC, etc.)
•Kademlia DHT — Content routing: "Who has content with hash X?" Similar to BitTorrent's mainline DHT but more generalized.
•BitSwap — Data exchange protocol: peers request blocks by hash and send blocks they have. Credit/debt tracking incentivizes reciprocity.
•IPLD (InterPlanetary Linked Data) — Data model for content-addressed structures. Merkle DAGs enable efficient verification and deduplication.
•IPNS (InterPlanetary Name System) — Mutable pointers: a peer-controlled name that can point to changing IPFS content (like DNS for IPFS).

How IPFS Works:

Adding Content:

1. Split content into blocks (typically ~256KB)
2. Hash each block with SHA-256
3. Create Merkle DAG linking blocks
4. Root hash becomes Content Identifier (CID)
5. Announce to DHT: "I have CID abc123"

Retrieving Content:

1. Given CID, query DHT for providers
2. Connect to providers, request blocks via BitSwap
3. Verify each block hash matches CID
4. Reconstruct content from blocks
5. Optionally, cache and re-provide to others

Deduplication:

Content addressing enables automatic deduplication. If 1000 users store the same file, they all get the same CID, and the network stores it once. Updates to files only require storing changed blocks.

Pinning and Persistence:

IPFS doesn't guarantee persistence—nodes can garbage-collect unpinned content. Persistence requires:

Local pinning (keep on your node)
Pinning services (pay others to pin)
Filecoin (blockchain-incentivized storage)

IPFS in Production

Wikipedia mirrors run on IPFS. NFT metadata is often stored on IPFS. Cloudflare and Brave provide IPFS gateways. Many decentralized applications use IPFS for content storage while keeping state on-chain.

libp2p: P2P Building Blocks

libp2p emerged from IPFS as a standalone modular networking stack for building P2P applications. Rather than implementing P2P networking from scratch, developers compose libp2p modules to create custom P2P systems.

The Modularity Philosophy:

Every P2P system needs transport, security, peer discovery, and routing—but requirements vary. libp2p makes each concern pluggable:

libp2p Module Categories
Category	Options	Use Case
Transport	TCP, QUIC, WebSocket, WebRTC	Adapt to network environment
Security	TLS 1.3, Noise Protocol	Encrypt all peer communications
Multiplexing	yamux, mplex	Multiple streams per connection
Peer Discovery	mDNS, DHT, Bootstrap	Find peers in various environments
Content Routing	Kademlia DHT, GossipSub	Locate content/topics
PubSub	FloodSub, GossipSub	Topic-based message broadcast

Peer Identity:

libp2p peers are identified by cryptographic keys rather than network addresses:

Peer ID = Multihash(Public Key)

Example: QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N

Advantages:

Identity survives IP changes, NAT, network migration
Connections authenticated via key exchange
No central identity registry needed

GossipSub Protocol:

GossipSub is libp2p's scalable pub/sub protocol, used by Ethereum 2.0 for consensus message propagation:

1. Peers subscribe to topics (e.g., "blocks", "transactions")
2. Each peer maintains a mesh of topic-connected peers
3. Messages propagate through mesh (eager push)
4. Gossip about seen messages enables missing message recovery
5. Peer scoring penalizes misbehavior (spam, invalid messages)

GossipSub provides:

O(log n) message delivery
Resilience to churn and attacks
Configurable redundancy vs. efficiency

libp2p Node Setup (Conceptual)
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// Conceptual libp2p node configuration
 
const node = await createLibp2p({
    addresses: {
        listen: ['/ip4/0.0.0.0/tcp/0']
    },
    transports: [
        tcp(),
        webSockets(),
        webRTC()
    ],
    connectionEncryption: [noise()],
    streamMuxers: [yamux(), mplex()],
    peerDiscovery: [
        mdns(),
        bootstrap({ list: bootstrapPeers }),
        kadDHT()
    ],
    services: {
        pubsub: gossipsub(),
        dht: kadDHT()
    }
});
 
await node.start();
 
// Subscribe to a topic
node.services.pubsub.subscribe('my-topic');
node.services.pubsub.addEventListener('message', (evt) => {
    console.log('Received:', evt.detail.data);
});
 
// Publish to topic
node.services.pubsub.publish('my-topic', new TextEncoder().encode('Hello P2P!'));

Growing Ecosystem

libp2p implementations exist in Go, JavaScript, Rust, Python, and more. Projects like Polkadot, Filecoin, and Ethereum 2.0 build on libp2p, validating its design at massive scale.

NAT Traversal Techniques

NAT (Network Address Translation) is P2P's greatest obstacle. Most devices connect through NATs that block unsolicited inbound connections—exactly the connections P2P requires. Understanding NAT traversal is essential for P2P protocol design.

NAT Types and Their Impact:

NAT Types and P2P Connectivity
NAT Type	Behavior	P2P Difficulty
Full Cone	Any external host can send to mapped port	Easy - external address is predictable
Address-Restricted Cone	Only hosts peer has contacted can reply	Moderate - requires simultaneous open
Port-Restricted Cone	Only specific host:port can reply	Moderate - requires coordination
Symmetric	Different mapping for each destination	Hard - external port unpredictable

NAT Traversal Strategies:

1. UPnP/NAT-PMP Port Forwarding:

Client → Router: "Please forward external port 50000 to me"
Router → Client: "OK, external:50000 → your_internal_ip:50000"

Simple when available, but many routers disable UPnP for security.

2. STUN (Session Traversal Utilities for NAT):

Client → STUN Server: "What address do you see for me?"
STUN Server → Client: "You appear as 203.0.113.5:54321"
Client shares this "server-reflexive" address with peers

Works for non-symmetric NATs. Peer connections use this external address.

3. Hole Punching:

Peer A (behind NAT-A) and Peer B (behind NAT-B) want to connect:
1. Both contact coordination server, share their external addresses
2. Both simultaneously send packets to each other's external address
3. Outgoing packets create NAT mappings; incoming packets arrive
4. Result: bidirectional path through both NATs

Requires timing coordination. Fails with symmetric NATs (different port per destination).

4. TURN Relay:

When direct connection fails:
Peer A → TURN Server → Peer B

Always works but defeats P2P efficiency. Used as last resort.

Converting Mermaid diagram...

IPv6 Eliminates NAT

IPv6 provides enough addresses for every device to have a public IP, eliminating NAT for P2P. As IPv6 adoption grows, NAT traversal becomes less critical—though firewalls still require consideration.

Protocol Security Considerations

P2P protocols face unique security challenges. Without central servers to trust, every peer is potentially hostile. Protocol design must assume adversarial conditions.

P2P Attack Vectors

•Sybil Attacks — Creating many fake identities to gain disproportionate influence or monitoring capability
•Eclipse Attacks — Isolating a node by controlling all its connections, feeding it false information
•Routing Attacks — Manipulating DHT routing to intercept queries or deny service
•Pollution Attacks — Injecting garbage data that appears legitimate, wasting bandwidth
•DDoS via Amplification — Triggering massive responses from small requests

Defense Mechanisms

•Cryptographic Identity — Tie node IDs to provable key ownership; expensive to generate many
•Diverse Peer Selection — Connect to peers from varied IP ranges; limit per-subnet connections
•Content Verification — Hash-verify all data; reject mismatched content immediately
•Peer Scoring — Track peer behavior; deprioritize or disconnect misbehaving peers
•Rate Limiting — Cap responses per peer; prevent amplification abuse

End-to-End Encryption:

Modern P2P protocols encrypt all peer communications:

Noise Protocol Framework — Flexible, modern handshake providing forward secrecy and identity verification
TLS 1.3 — Industry-standard encryption with well-understood security properties
Double Ratchet — Per-message keys for extreme forward secrecy (Signal protocol)

Metadata Protection:

Encryption protects content but not metadata. An observer can still see:

Who connects to whom
When connections occur
Data volume transferred

Advanced protocols attempt metadata protection:

Onion Routing (Tor) — Layered encryption hides source/destination
Mix Networks — Messages mixed through multiple servers
Private Information Retrieval — Query servers without revealing query content

These protections add latency and complexity, suitable for privacy-critical applications.

Trust No Peer

The fundamental P2P security principle: verify everything, trust nothing. Data must be self-verifying (hashes, signatures). Peer behavior must be validated. Protocol design must assume Byzantine conditions—some peers are actively trying to cause harm.

Summary: P2P Protocols

We've explored the landscape of P2P protocols beyond file sharing. Let's consolidate the key concepts:

Key Takeaways

•WebRTC enables browser P2P — Native browser APIs for video, audio, and data with ICE/STUN/TURN for NAT traversal.
•Blockchain gossip spreads consensus — Epidemic protocols ensure all nodes see all transactions and blocks for agreement.
•IPFS provides content-addressed storage — Data identified by what it is, not where it is, enabling deduplication and verification.
•libp2p modularizes P2P networking — Pluggable components for transport, security, discovery, and routing across implementations.
•NAT traversal is fundamental — Hole punching, STUN, TURN, and UPnP enable connections through ubiquitous NATs.
•Security requires verification — Without central authority, self-verifying data and peer scoring defend against attacks.

What's next:

With protocol foundations covered, we'll examine hybrid models that combine P2P with traditional architectures—exploring how real systems blend decentralized data transfer with centralized coordination to achieve the best of both worlds.

Page Complete

You now understand the diverse landscape of P2P protocols—from real-time WebRTC to blockchain gossip to content-addressed IPFS. These protocols power billions of dollars of infrastructure and serve billions of users daily.

P2P Protocols

Beyond File Sharing

Learning Objectives

P2P Protocol Categories

P2P protocols can be categorized by their primary function, though many real systems combine multiple categories:

P2P Protocol Categories
Category	Primary Function	Key Challenge	Examples
Content Distribution	Efficiently distribute files/data	Piece selection, incentives	BitTorrent, IPFS
Real-Time Communication	Low-latency audio/video	NAT traversal, codec negotiation	WebRTC, original Skype
Distributed Storage	Persistent, redundant storage	Reliability, availability guarantees	IPFS, Storj, Filecoin
Consensus/Blockchain	Agreement on shared state	Byzantine fault tolerance	Bitcoin, Ethereum gossip
Messaging/Chat	Private or group communication	Key exchange, metadata privacy	Matrix, Signal (uses P2P ideas)
Computation	Distributed processing	Task allocation, verification	BOINC, Golem

Cross-Cutting Concerns:

Regardless of category, P2P protocols share common challenges:

Peer Discovery — How do nodes find each other initially and continuously?
NAT Traversal — How do peers behind NATs establish direct connections?
Identity and Authentication — How do peers prove identity without central authority?
Message Routing — How do messages reach their intended destination efficiently?
Data Integrity — How do peers verify received data hasn't been tampered with?
Incentive Alignment — How do we ensure peers contribute rather than just consume?

Different protocols prioritize these concerns differently based on their use case. Let's explore key protocols in depth.

Protocol Layering

WebRTC: Browser-to-Browser P2P

Why WebRTC Matters:

Before WebRTC, real-time browser communication required:

Flash/Java plugins (security nightmares)
Server-mediated streams (expensive, high latency)
Custom applications (poor reach)

WebRTC provides native browser APIs for peer-to-peer media, enabling:

Direct peer connections (lowest possible latency)
Encrypted communications (end-to-end by default)
Adaptive quality (codecs adjust to network conditions)
Universal availability (all major browsers)

Converting Mermaid diagram...

WebRTC Architecture Components:

Signaling Server: WebRTC doesn't define how peers find each other—that's left to the application. A signaling server (typically WebSocket-based) exchanges:

Session Description Protocol (SDP) offers/answers describing media capabilities
ICE candidates describing possible connection paths

ICE (Interactive Connectivity Establishment): ICE orchestrates the connection process:

Gather candidates (host, server-reflexive, relay)
Check connectivity for each candidate pair
Select best working path
Handle path changes during session

WebRTC Connection Flow
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Simplified WebRTC Connection Setup
 
// Browser A (caller)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: 'stun:stun.example.com' },
        { urls: 'turn:turn.example.com', username: 'user', credential: 'pass' }
    ]
});
 
// Add local stream
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));
 
// Handle ICE candidates
pc.onicecandidate = (event) => {
    if (event.candidate) {
        signalingServer.send({ type: 'candidate', candidate: event.candidate });
    }
};
 
// Create and send offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signalingServer.send({ type: 'offer', sdp: offer.sdp });
 
// Receive answer from Browser B
signalingServer.onMessage = async (msg) => {
    if (msg.type === 'answer') {
        await pc.setRemoteDescription(new RTCSessionDescription(msg));
    } else if (msg.type === 'candidate') {
        await pc.addIceCandidate(new RTCIceCandidate(msg.candidate));
    }
};
 
// Receive remote stream
pc.ontrack = (event) => {
    remoteVideo.srcObject = event.streams[0];
};

Beyond Video Chat

Blockchain Gossip Protocols

The Gossip Model:

Gossip (or epidemic) protocols spread information like a disease:

A node receives new information (transaction, block)
The node sends it to some random subset of neighbors
Each neighbor repeats the process
Information spreads exponentially until all nodes have it

This approach is remarkably robust—even with node failures, adversarial nodes, and network partitions, information still spreads.

Bitcoin P2P Protocol Messages

Protocol

/* Bitcoin P2P Protocol (Simplified) */
 
// Network Discovery
VERSION     // Initial handshake with protocol version
VERACK      // Acknowledgment of VERSION
ADDR        // List of known network addresses
GETADDR     // Request for peer addresses
 
// Block Propagation  
INV         // Inventory - "I have these blocks/transactions"
GETDATA     // Request specific items from INV
BLOCK       // Full block data
HEADERS     // Block headers only (for SPV)
GETHEADERS  // Request header chain
 
// Transaction Propagation
TX          // Full transaction data
MEMPOOL     // Request mempool transactions
 
// Compact Block Relay (BIP 152)
SENDCMPCT   // Enable compact block relay
CMPCTBLOCK  // Compact block (header + short IDs)
GETBLOCKTXN // Request missing transactions
BLOCKTXN    // Missing transactions for compact block
 
/* Propagation Flow */
1. Miner creates new block
2. Miner sends INV to peers: "I have block X"
3. Peers reply GETDATA for block X
4. Miner sends BLOCK containing full block data
5. Peers validate block, add to chain
6. Peers send INV to THEIR peers
7. Process repeats across network
8. Full propagation: ~seconds for global reach

Bitcoin Network Structure:

Full Nodes — Store complete blockchain, validate all transactions and blocks, relay to other nodes
SPV (Light) Clients — Store only block headers, request relevant transactions, trust full nodes for validation
Mining Nodes — Full nodes that also produce new blocks

Propagation Optimizations:

Compact Block Relay (BIP 152): Blocks contain mostly transactions that peers already know (from mempool). Compact blocks send:

Block header
Short transaction IDs (6 bytes vs. 32-byte hashes)
Only novel transactions included

Peers reconstruct full blocks from their mempool + short IDs, dramatically reducing bandwidth.

Ethereum's Gossip:

Ethereum uses devp2p with Kademlia-based discovery (discv4/discv5). Its gossip protocol handles:

Transactions (eth protocol)
Block announcements and fetching
State synchronization (snap protocol)
Light client serving (les protocol)

Eclipse Attacks on Blockchains

IPFS: Content-Addressed Storage

The Content Addressing Paradigm:

Traditional web addressing is location-based:

https://example.com/files/document.pdf

This says WHERE to get the file, not WHAT the file is. The server could change the content; the link might break; mirrors need explicit management.

Content addressing is hash-based:

ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco

This says WHAT the content is (its cryptographic hash). The same content always has the same address. Any peer with the content can serve it. The content is self-verifying.

IPFS Protocol Stack

•libp2p — Modular networking layer handling transport, security, stream multiplexing, and peer discovery across multiple protocols (TCP, QUIC, WebRTC, etc.)
•Kademlia DHT — Content routing: "Who has content with hash X?" Similar to BitTorrent's mainline DHT but more generalized.
•BitSwap — Data exchange protocol: peers request blocks by hash and send blocks they have. Credit/debt tracking incentivizes reciprocity.
•IPLD (InterPlanetary Linked Data) — Data model for content-addressed structures. Merkle DAGs enable efficient verification and deduplication.
•IPNS (InterPlanetary Name System) — Mutable pointers: a peer-controlled name that can point to changing IPFS content (like DNS for IPFS).

How IPFS Works:

Adding Content:

1. Split content into blocks (typically ~256KB)
2. Hash each block with SHA-256
3. Create Merkle DAG linking blocks
4. Root hash becomes Content Identifier (CID)
5. Announce to DHT: "I have CID abc123"

Retrieving Content:

1. Given CID, query DHT for providers
2. Connect to providers, request blocks via BitSwap
3. Verify each block hash matches CID
4. Reconstruct content from blocks
5. Optionally, cache and re-provide to others

Deduplication:

Content addressing enables automatic deduplication. If 1000 users store the same file, they all get the same CID, and the network stores it once. Updates to files only require storing changed blocks.

Pinning and Persistence:

IPFS doesn't guarantee persistence—nodes can garbage-collect unpinned content. Persistence requires:

Local pinning (keep on your node)
Pinning services (pay others to pin)
Filecoin (blockchain-incentivized storage)

IPFS in Production

libp2p: P2P Building Blocks

The Modularity Philosophy:

Every P2P system needs transport, security, peer discovery, and routing—but requirements vary. libp2p makes each concern pluggable:

libp2p Module Categories
Category	Options	Use Case
Transport	TCP, QUIC, WebSocket, WebRTC	Adapt to network environment
Security	TLS 1.3, Noise Protocol	Encrypt all peer communications
Multiplexing	yamux, mplex	Multiple streams per connection
Peer Discovery	mDNS, DHT, Bootstrap	Find peers in various environments
Content Routing	Kademlia DHT, GossipSub	Locate content/topics
PubSub	FloodSub, GossipSub	Topic-based message broadcast

Peer Identity:

libp2p peers are identified by cryptographic keys rather than network addresses:

Peer ID = Multihash(Public Key)

Example: QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N

Advantages:

Identity survives IP changes, NAT, network migration
Connections authenticated via key exchange
No central identity registry needed

GossipSub Protocol:

GossipSub is libp2p's scalable pub/sub protocol, used by Ethereum 2.0 for consensus message propagation:

1. Peers subscribe to topics (e.g., "blocks", "transactions")
2. Each peer maintains a mesh of topic-connected peers
3. Messages propagate through mesh (eager push)
4. Gossip about seen messages enables missing message recovery
5. Peer scoring penalizes misbehavior (spam, invalid messages)

GossipSub provides:

O(log n) message delivery
Resilience to churn and attacks
Configurable redundancy vs. efficiency

libp2p Node Setup (Conceptual)
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// Conceptual libp2p node configuration
 
const node = await createLibp2p({
    addresses: {
        listen: ['/ip4/0.0.0.0/tcp/0']
    },
    transports: [
        tcp(),
        webSockets(),
        webRTC()
    ],
    connectionEncryption: [noise()],
    streamMuxers: [yamux(), mplex()],
    peerDiscovery: [
        mdns(),
        bootstrap({ list: bootstrapPeers }),
        kadDHT()
    ],
    services: {
        pubsub: gossipsub(),
        dht: kadDHT()
    }
});
 
await node.start();
 
// Subscribe to a topic
node.services.pubsub.subscribe('my-topic');
node.services.pubsub.addEventListener('message', (evt) => {
    console.log('Received:', evt.detail.data);
});
 
// Publish to topic
node.services.pubsub.publish('my-topic', new TextEncoder().encode('Hello P2P!'));

Growing Ecosystem

libp2p implementations exist in Go, JavaScript, Rust, Python, and more. Projects like Polkadot, Filecoin, and Ethereum 2.0 build on libp2p, validating its design at massive scale.

NAT Traversal Techniques

NAT Types and Their Impact:

NAT Types and P2P Connectivity
NAT Type	Behavior	P2P Difficulty
Full Cone	Any external host can send to mapped port	Easy - external address is predictable
Address-Restricted Cone	Only hosts peer has contacted can reply	Moderate - requires simultaneous open
Port-Restricted Cone	Only specific host:port can reply	Moderate - requires coordination
Symmetric	Different mapping for each destination	Hard - external port unpredictable

NAT Traversal Strategies:

1. UPnP/NAT-PMP Port Forwarding:

Client → Router: "Please forward external port 50000 to me"
Router → Client: "OK, external:50000 → your_internal_ip:50000"

Simple when available, but many routers disable UPnP for security.

2. STUN (Session Traversal Utilities for NAT):

Client → STUN Server: "What address do you see for me?"
STUN Server → Client: "You appear as 203.0.113.5:54321"
Client shares this "server-reflexive" address with peers

Works for non-symmetric NATs. Peer connections use this external address.

3. Hole Punching:

Peer A (behind NAT-A) and Peer B (behind NAT-B) want to connect:
1. Both contact coordination server, share their external addresses
2. Both simultaneously send packets to each other's external address
3. Outgoing packets create NAT mappings; incoming packets arrive
4. Result: bidirectional path through both NATs

Requires timing coordination. Fails with symmetric NATs (different port per destination).

4. TURN Relay:

When direct connection fails:
Peer A → TURN Server → Peer B

Always works but defeats P2P efficiency. Used as last resort.

Converting Mermaid diagram...

IPv6 Eliminates NAT

Protocol Security Considerations

P2P protocols face unique security challenges. Without central servers to trust, every peer is potentially hostile. Protocol design must assume adversarial conditions.

P2P Attack Vectors

•Sybil Attacks — Creating many fake identities to gain disproportionate influence or monitoring capability
•Eclipse Attacks — Isolating a node by controlling all its connections, feeding it false information
•Routing Attacks — Manipulating DHT routing to intercept queries or deny service
•Pollution Attacks — Injecting garbage data that appears legitimate, wasting bandwidth
•DDoS via Amplification — Triggering massive responses from small requests

Defense Mechanisms

•Cryptographic Identity — Tie node IDs to provable key ownership; expensive to generate many
•Diverse Peer Selection — Connect to peers from varied IP ranges; limit per-subnet connections
•Content Verification — Hash-verify all data; reject mismatched content immediately
•Peer Scoring — Track peer behavior; deprioritize or disconnect misbehaving peers
•Rate Limiting — Cap responses per peer; prevent amplification abuse

End-to-End Encryption:

Modern P2P protocols encrypt all peer communications:

Noise Protocol Framework — Flexible, modern handshake providing forward secrecy and identity verification
TLS 1.3 — Industry-standard encryption with well-understood security properties
Double Ratchet — Per-message keys for extreme forward secrecy (Signal protocol)

Metadata Protection:

Encryption protects content but not metadata. An observer can still see:

Who connects to whom
When connections occur
Data volume transferred

Advanced protocols attempt metadata protection:

Onion Routing (Tor) — Layered encryption hides source/destination
Mix Networks — Messages mixed through multiple servers
Private Information Retrieval — Query servers without revealing query content

These protections add latency and complexity, suitable for privacy-critical applications.

Trust No Peer

Summary: P2P Protocols

We've explored the landscape of P2P protocols beyond file sharing. Let's consolidate the key concepts:

Key Takeaways

•WebRTC enables browser P2P — Native browser APIs for video, audio, and data with ICE/STUN/TURN for NAT traversal.
•Blockchain gossip spreads consensus — Epidemic protocols ensure all nodes see all transactions and blocks for agreement.
•IPFS provides content-addressed storage — Data identified by what it is, not where it is, enabling deduplication and verification.
•libp2p modularizes P2P networking — Pluggable components for transport, security, discovery, and routing across implementations.
•NAT traversal is fundamental — Hole punching, STUN, TURN, and UPnP enable connections through ubiquitous NATs.
•Security requires verification — Without central authority, self-verifying data and peer scoring defend against attacks.

What's next:

Page Complete