The content routing system of IPFS is the part of the architecture that discovers content in the network. It is considered by many as the most important part of the architecture, as well as the one with the most open research questions. Through this module, you will learn: - IPFS's Content Routing Architecture, - the protocol settings and algorithmics of IPFS’s mighty DHT, - IPFS's gossip-based content routing approaches.

1. Module:
Content Routing
ResNetLab on Tour

2. Agenda
➔ Introduction
◆ Location Addressing vs. Content Addressing
◆ The Challenge of content routing in P2P networks
➔ Content Routing Architecture
➔ Content Routing Implementation
◆ DHT-based Content Routing
◆ Gossip-based Content Routing
◆ And other Content Routing subsystems

3. VS
Location Addressing vs
Content Addressing
Tell me which
server you
know stores
<fileA>?
<server> has it,
here you go!
LOCATION ADDRESSING CONTENT ADDRESSING
Who has
file <CID A>?
Sure, I have it
if you want it
Me too!
And me!
Take it!
<fileA>
<fileA>
<server>

4. The challenge
of Content
Routing in
P2P networks
Challenges apply to...
Discovering peers
in the network
Finding peers
storing the
content
Contacting these
peers to request
the content
Doing it all in
scalable way!
● There is no central entity orchestrating the storage and
discovery of content.
● There is no central directory to find how to reach every peer in
the network.
● P2P networks present high node churn.
● Thousands of peers and millions of content!

5. a
CONTENT ADDRESSING CONTENT DISCOVERY
& ROUTING
CONTENT EXCHANGE
● Chunking
● Linking Chunks
in Merkle DAGs
● From Data to
Data Structures with IPLD
● Anatomy of the IPFS CID
● Routing & Provider
Records
● DHT-based Routing
● Gossip-based Routing
● Bitswap
● GraphSync
MUTABLE NAMES &
MESSAGE DELIVERY
● Dynamic Data
● IPNS
● PubSub
● CRDTs
IPFS Components

6. Content
Routing
Interface in
libp2p/IPFS
● Common interface for content routing:
○ Provide: Make content available for other peers in the
network
○ Resolve: Find the peers storing the content in the
network.
○ Fetch: Fetches content from a provider.
● Additional schemes are required to learn how to reach peers
in the network (peer routing).
Network
Peer
● Content | Peer
● Peer | Contact info

7. Content
Routing
Interface in
libp2p/IPFS
● Design goals:
○ Reliable: any content can be found.
○ Scalable and fast: The performance of queries are not
affected by the size of the network.
○ Resistant to node churn and sybil attacks.
● Two design approaches:
○ DHT-based: libp2p KadDHT
○ Gossip-based: Bitswap, PubSub.
○ Centrally governed providing subsystems.

8. Peer Routing
Every peer uses a cryptographic key pair,
for the purpose of
● Identity: unique name in the network
"QmTuAM7RMnMqKnTq6qH1u9JiK5LqQvUxFdnrcM4aRHxeew"
● Channel security (encryption)
Has unique ID in
the p2p network
namespace
Provides
services to
other peers
Must be
“discoverable”
(DHT)
Uses encrypted
communication
channels
Uses services
from other
peers
Must be
“routable”/
reachable
(multiaddress)
The Swarm
The Peer

9. a
CONTENT ADDRESSING CONTENT DISCOVERY
& ROUTING
CONTENT EXCHANGE
● Chunking
● Linking Chunks
in Merkle DAGs
● From Data to
Data Structures with IPLD
● Anatomy of the IPFS CID
● Routing & Provider
Records
● DHT-based Routing
● Gossip-based Routing
● Bitswap
● GraphSync
MUTABLE NAMES &
MESSAGE DELIVERY
● Dynamic Data
● IPNS
● PubSub
● CRDTs
IPFS Components

10. The DHT
● A DHT provides a 2-column table (key-value
store) maintained by multiple peers.
● Each row is stored by peers based on similarity
between the key and the peer ID. We call this
“distance”:
○ A peer ID can be “closer” to some keys
than others
○ A peer ID can be “closer” to other peers.
● The DHT is used in IPFS to provide:
○ Peer routing (PeerID, /ipv4/1.2.3.4/tcp/...)
○ Content Discovery (ContentID, PeerID)
○ IPNS Records (IPNS key, IPNS Record)
Peer 1
(key1, value1)
(key2, value2)
Peer 2
(key3, value6)
(key4, value5)
Peer 5
(key7, value7)
Peer 6
(key5, value3)
Peer 3
(key5, value5)
Peer 4
(key4,value4)

11. ● IPFS uses an adaptation of the Kademlia DHT:
○ 256 bits address space - SHA256
○ Distance between two object through XOR
■ distance(a, b) = a XOR b = distance(b,a)
○ It uses tree-based routing (figure)
○ The binary tree is divided into a series of
successively lower subtrees. Each contain a
k-bucket (list of nodes with that prefix)
○ Initiates parallel asynchronous queries to
avoid waiting for offline nodes.
Inspired by Kademlia DHT

12. Providing
Content
Put content hash H
Lookup k
closest peers
to SHA256(H)
Put provider
record at
those k
closest peers
Periodically
re-publish to
accommodate
churn
● Content is not replicated or uploaded to any external server
(Provide). The content stays local on the user’s device.
● It is the Content Identifier (CID) together with a pointer to the
user’s machine that is made known to the network.
○ This tuple is called the provider record and is added to 20 peers.
■ Provide records expire (i.e. they’re not provided by peers) after 24
hours to account for provider churn.
■ Provider records are re-published after 12 hours (by providers) to
account for peer-churn (i.e. make sure close to 20 peers still
store the record).

13. Providing
Content
Put content hash H
Lookup k
closest peers
to SHA256(H)
Put provider
record at
those k
closest peers
Periodically
re-publish to
accommodate
churn
● Peers requesting content become temporary providers when
receiving the content.
○ Pinning content converts you in a permanent provider.
○ Content is garbage collected in temporary nodes (> 90%
datastore size; every 1h )

14. ● Content Discovery (Resolve): Contact k closest peers to the CID. If they have the object
they send it back, if not they respond with the provider record.
● Peer Discovery: A peer may not know the multiaddress for the peer in the provider
record so it needs to perform a new DHT query to find the peer’s network addresses.
○ Routing tables refresh every 10 min. This usually determines if a new walk is
needed to get the peer’s contact information.
● Peer Routing: Use the multiaddress of the provider to contact it.
Content
Routing
(DHT-based)
Get content hash H
Lookup k closest
peers to
SHA256(H)
Request record to
peers if they have
it.
(Bitswap)
Continue until
lookup
terminates.
Multi-round iterative lookups

15. Including records for peers in networks not
reachable from the public (local networks,
isolated VPNs, etc.) is problematic.
● Public DHT (WAN DHT): Only
includes publicly reachable peers.
● Private DHT (LAN DHT): Only
includes peers belonging to the same
private network
A public DHT
and a private one

16. Pros and Cons
of using a DHT
● Fault tolerant. Resistance to churn.
● Finds peers 100% probability (as long as they are reachable).
● Ensures freshness of the routing information.
● Can be slow in network with a large number of peers.
○ Lookup O(logN), it may require several hops to find peers
if N is large.
● DHT proximity ≠ Spatial proximity
IP Network
Overlay
Network

17. IPFS Defaults
Metric Default
Value
IPFS
K: Size of buckets 20
Alpha (closest peers queried) 10
Beta (successful peers for
termination)
3
K-bucket refresh interval 10 min
Metric Default Value IPFS
Re-publish interval 12 hr
Provider record expiry 24 hr
Garbage collection
triggered
Every hour, if 90% of
datastore size used
(10GB)

18. a
CONTENT ADDRESSING CONTENT DISCOVERY
& ROUTING
CONTENT EXCHANGE
● Chunking
● Linking Chunks
in Merkle DAGs
● From Data to
Data Structures with IPLD
● Anatomy of the IPFS CID
● Routing & Provider
Records
● DHT-based Routing
● Gossip-based Routing
● Bitswap
● GraphSync
MUTABLE NAMES &
MESSAGE DELIVERY
● Dynamic Data
● IPNS
● PubSub
● CRDTs
IPFS Components

19. ● IPFS can leverage other content routing subsystems to
discover content in the network:
○ Gossip-based:
■ Bitswap asks its neighbors for the content while
performing a DHT lookup. Gossiping is fast but
the probability of success is low.
■ PubSub protocols build swarms of peers
interested in the same content. Exchange
information about content being requested and
announced in the network.
○ External subsystems: Such as Bittorrent trackers or
DNS.
● The current implementation of IPFS uses gossip-based and
DHT-based content routing orchestrated by Bitswap (more in
Content Exchange Module)
Gossip-based
and other
content
routing
subsystems

20. Content Discovery in IPFS
Content Provider
Step 0: Get CID out of band.
Step 1: Bitswap asks all
“neighbours” in the peerlist:
● in case of positive response,
content is fetched and
process terminates
● in case of negative
response, proceed to Step 2:
Ask in the DHT

21. 1 2 3
1
2
3
Content Provider
4
5
REQ(CID)
DATA
Step 5: Cache content, publish provider
record, provide content when asked
Content Discovery in IPFS
Step 2: Find provider record by
walking the DHT iteratively, in each
step getting closer to the target.
The provider record includes PeerID
and MultiAddr of provider, iff the
provider record has been updated
within the last 10 mins.
Step 3: If provider record includes
provider’s MultiAddrs, start a
Bitswap session, contact peer
directly and ask for the data -
If not, skip to Step 4. -
4 5
Step 4: “Walk” the DHT again to
map: PeerID -> MultiAddr.
Repeat: -
1 5

22. Thank you for watching
Reach out in case you have questions or comments!