This repository has been archived by the owner on Apr 16, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
started formal description of bitswap
- Loading branch information
Showing
1 changed file
with
33 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
Bitswap Description (WIP) | ||
=== | ||
|
||
Bitswap is a protocol for the exchange of data blocks between peers. | ||
|
||
Peers | ||
----- | ||
Peers have access to information about the network (e.g. latency of connections to peers). Each peer also maintains information about their interactions with other peers (ledgers) and the hashes of the blocks it currently has and wants. | ||
|
||
Exchanging Blocks | ||
---- | ||
Peers should be able to request blocks from other peers and respond to requests themselves. | ||
|
||
When a peer opens a connection with another peer, it receives the ledger of the other peer. Using this information, the peer can determine whether the other peer is malicious and can choose to ignore the request. | ||
|
||
If a peer opens a connection with another peer, they exchange want lists. Want lists are then exchanged again on updates or specified time intervals. If a peer has a block wanted by another peer, the block is sent probabilistically according to a strategy which is a function of the information the peer has access to. | ||
|
||
If a block is sent, the receiving peer moves it from its want list to its have list, and the ledgers of both peers are updated. | ||
|
||
Strategies | ||
---- | ||
Each peer should utilize the information about the network to make trades that will maximize the data throughput to all peers in the system. | ||
|
||
Thus, a good strategy should (taken from ipfs paper): | ||
1. maximize the trade performance for the node, and the | ||
whole exchange | ||
2. prevent freeloaders from exploiting and degrading the | ||
exchange | ||
3. be effective with and resistant to other, unknown strategies | ||
4. be lenient to trusted peers | ||
|
||
|
||
|