In this module, you’ll learn: - IPFS’s Content Exchange protocols, namely, Bitswap and GraphSync, - the message types and workflows of Bitswap and GraphSync, and - the differences between the two protocols.

1. Module:
Content Exchange
ResNetLab on Tour

2. Agenda
➔ Bitswap: Content Exchange Protocol
● Modular architecture
● Common Request Patterns
● Bitswap’s operation
➔ 1:1 Exchanges with Graphsync
➔ Bitswap vs. Graphsync

3. Content in
IPFS
● Content is chunked in blocks
● Blocks are abstraction serialized
information
● Blocks are uniquely identified by a
Content IDentifier (CID, i.e. hash of the
block)
● Structured as a DAG (link of blocks),
IPLD graphs
File
..
CID1 CID2 CID3

4. 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
a

5. ● Bitswap is a message-oriented
protocol to exchange blocks in a
P2P network.
● Bitswap is IPFS’
content-exchange protocol.
Bitswap’s Modular
Architecture

6. Bitswap’s Modular
Architecture
● Bitswap is a message-oriented
protocol to exchange blocks in a
P2P network.
● Bitswap is IPFS’
content-exchange protocol.

7. Bitswap’s Modular
Architecture
● Bitswap is a message-oriented
protocol to exchange blocks in a
P2P network.
● Bitswap is IPFS’
content-exchange protocol.

8. Bitswap’s Modular
Architecture
● Bitswap is a message-oriented
protocol to exchange blocks in a
P2P network.
● Bitswap is IPFS’
content-exchange protocol.

9. Bitswap’s Modular
Architecture
● Bitswap is a message-oriented
protocol to exchange blocks in a
P2P network.
● Bitswap is IPFS’
content-exchange protocol.

10. ● IPFS asks Bitswap for blocks
● Bitswap fetches blocks from the
network
● Message-oriented protocol:
○ Requests: WANT-HAVE / WANT-BLOCK
/ CANCEL
○ Responses: HAVE / BLOCK /
DONT_HAVE
IPFS
Blockstore
Bitswap
The IPFS Example
Bitswap
Operation

11. Common Retrieval Patterns
How content is requested affects the operation of Bitswap
(what blocks are requested, in what order, and how the DAG is traversed)
Level 1
Level 2
Level 3
Request all nodes at each
level of a DAG (eg a file)
web
web/page
web/page/doc.html
Request nodes down a DAG
(eg web/page/doc.html)
<contents>

12. Bitswap
Discovery
● Broadcast WANT to connected
Peers
● If there’s no response, ask DHT
who has root CID
WANT-
HAVE
CID1
WANT
CID1
WANT-
HAVE
CID1
Providers CID1
DHT
Connected Peers

13. Bitswap
Sessions
● Peers who respond are added to
the Session
● Subsequent requests are sent
only to peers in the session
HAVE
(CID1)
HAVE
(CID1)
Provider CID1
DHT
Connected Peers

14. ● HAVE message
○ Sometimes we don’t want a
whole block
○ We just want to know who has
a block (eg for discovery)
● Two kinds of WANT messages
○ want-have
○ want-block
● If the block is small enough,
send the whole block (instead
of sending HAVE)
Root Block
RTT
want-have CID1?
Peer A Peer B Peer C Peer D
HAVE CID1 ✓
want-block CID1 ▫
Block (CID1) ▧
HAVE CID1 ✓
HAVE CID1 ✓
Discovery:
Ask who has
CID1
Peer B has
CID1
Request block
from Peer B
Peer C & D
have CID1
Peer B
sends block

15. Subsequent
Requests
● DONT_HAVE message
○ Allows peer to indicate that it
does NOT have a block
○ Requester can set a flag to tell
responder to send DONT_HAVE
in response to want-block or
want-have
● Requests:
○ want-block
○ want-have
● Respond with combination of
○ HAVE, DONT_HAVE
○ block
Peer A sends
either
- want-block ▫ -
want-have ?
for each CID
that it wants
▫▫▫?
????
???▫
▫▫??
????
??▫▫
▧▧✗✓
✓✓✗✓
✗✓✓▧
▧▧✓✓
✗✓✓▧
▧▧✓✓
Peers B, C & D
respond with
- Block ▧
- HAVE ✓
- DONT_HAVE ✗
for each CID
Peer A Peer B Peer C Peer D

16. Ledger
Wantlist
● Nodes send WANT messages to
peers
● Each node remembers the want
list for each of its peers
● The wantlist is discarded when
the peer disconnects
WANT
CID1
1
WANT
CID2
1 2
Block
(CID1)
1 2
Block
(CID1)
Peer A Peer B
Peer B
remembers
Peer A’s
wantlist
Peer B
receives
Block (CID1)
Peer B
removes
CID1 from
wantlist for
Peer A
A
A
A
Peer B
sends Block
(CID1) to
Peer A

17. Wantlist
CANCEL
● Nodes send WANT
messages to peers
● Each node remembers the
want list for each of its
peers
● The wantlist is discarded
when the peer disconnects
WANT
CID1
1
WANT
CID2
1 2
Block
(CID1)
1 2
CANCEL
(CID1)
Peer A Peer B
A
A
A
Peer B
remembers
Peer A’s
wantlist
Peer B
receives
Block (CID1)
Peer B
removes
CID1 from
wantlist for
Peer A
Peer B
sends Block
(CID1) to
Peer A

18. 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
a

19. Graphsync
Operation
Single CID + Metadata
Several Blocks
● Request-response protocol to synchronize
graphs across peers.
● Uses IPLD selectors to request the blocks
of the graph to be exchanged
○ IPLD is a decentralized data
structure (DAG structure)
○ Selectors identify a subset of nodes
in the structure.
● 1:1 stream exchange (content is not
exchanged block by block like in Bitswap)
○ 1:1 exchanges in IPFS
○ Exchange of blockchain information
and user data in Filecoin

20. Graphsync vs. Bitswap
Bitswap Graphsync
Protocol type Message-oriented Request-Response
Content exchange Block by block Stream
Request patterns CID Path
/ipfs/<path_to>/cid
IPLD Selector
/sel/<path>/<cid>/*
Multi-path download Yes No, 1:1 exchange
Use cases File-sharing / download
Block exchange
Accelerate content routing
File sharing / download
Blockchain sync
Large dataset sync

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

22. Bitswap’s modular
architecture
● Bitswap is a message-oriented
protocol to exchange blocks in a
P2P network.
● Bitswap is IPFS’
content-exchange protocol.