Please enable JavaScript.

Coggle requires JavaScript to display documents.

IPFS - Coggle Diagram

- - - - Kademlia DHT
        
        Provides
        
        Efficient lookup through massive networks (E.g. 20 hops for a n/w of 10 Mn nodes)
        
        Low coordination overhead - Optimizes no. of control msgs it sends to other nodes
        
        Resistance to various attacks by preferring long-lived nodes
        
        Wide usage in p2p apps, including Gnutella & BitTorrent, forming n/w of over 20 Mn nodes
        
        Challenges
        
        Wasted Storage & B/W - Kademlia stores values in nodes whose ids are nearest to the nodes. Does not take into account far nodes that may already have the data & forces the nearest node to store it.
      - Coral DHT
        
        Addresses Kademlia's issues:
        
        Stores addresses to peers (not data) who can provide the data blocks
        
        Relaxes the DHT API from get_value(key) to get_any_values(key) since it needs only a single peer, not the complete list. In return, Coral can return only subset of values to the nearest nodes, avoiding hotspots
        
        Coral organises a hierarchy of separate DSHTs called clusters depending on region & size (regional). So nodes can query peers in their region first
      - S/Kademlia DHT
        
        Extends Kademlia to protect
        against malicious attacks in 2 ways
        
        1. Secure nodeId generation Each node generates a PKI key pair to derive their identify from it & also sign messages to each other. One scheme includes a proof of work crypto puzzle to make generating Sybills expensive
        
        Disjoint node lookup paths. To ensure honest nodes can connect to each other in the presence of a large fraction of adversaries in the n/w. Achieves a success rate of 0.85 even with half of the nodes being adverserial
- - - - Node ID Nodes are identified by a NodeId - Cryptographic hash of a public-key (created with S/Kademlia's static crypto puzzle)
        
        Incentivized to remain the same Users are free to instantiate a new node identity on every launch, but nodes are incentivized to remain the same
        
        Favors self-describing values IPFS does not lock the system to a particular set of function choices. Hash digest values are stored in multihash format which includes a short header specifying the hash function used, and the digest length in bytes. This allows
        a) choose the best function for the use case (e.g. stronger security vs faster performance),
        b) evolve as function choices change
    - - The network stack features:
        
        Transport - Any transport protocol (TCP/UDP), but best-suited for webRTC channels or uTP
        
        Reliability - Can provide reliability separately if underlying transport does not provide it
        
        Connectivity - Uses ICE NAT traversal techniques
        
        Integrity - optionally checks integrity of the messages using a hash checksum
        
        Authenticity - optionally checks the authenticity of the messages using HMAC with sender's public key
      - Note: Does not rely only on IP. This makes it useable in overlay networks as well.
    - - Need a routing system to
        a) Other peers' network addresses
        b) peers who can serve particular objects
        
        Achieves this using a DSHT based on S/Kademlia and Coral
        
        Small values are stored directly on DHT (< 1KB)
        
        Larger values are stored as references
    - - BitSwap
        
        Data distribution happens by exchanging blocks with peers using a BitTorrent inspired protocol: BitSwap
        
        Like BitTorrent, BitSwap peers are looking to acquire a set of blocks (want_list) and have another set of blocks to offer in return (have_list)
        
        Nodes come together to barter in the marketplace. This implies a virtual currency with a global ledger to track ownership and transfer of currency. (Filecoin?)
      - BitSwap Credit
        
        The protocol must incentivize nodes to seed even when they don't need anything as they might have blocks others want
        So the BitSwap nodes send blocks to their peers optimistically, expecting the debt to be repaid. But leeches need to be protected from
        A simple credit system solves this problem:
        
        Peers track their balance (in bytes verified) with other nodes
        
        Peers send their blocks to debtors probabilistically, according to a function that falls as debt increases
      - BitSwap Strategy
        
        A range of strategies can be implemented by BitSwap peers.
        E.g. Tit-for-Tat, BitTyrant, BitThief or Propshare
        So the choice of function should aim to:
        
        Maximize the trade performance of the node, and the whole exchange
        
        prevent freeloaders from exploiting & degrading the exchange
        
        Be effective with and resistance to other, unknown strategies
        
        be lenient to trusted peers
        
        One such choice of function is debt ratio, r = bytes_sent / bytes_received + 1
        
        Debt ratio is a measure of trust - Lenient to debts between nodes that have previously exchanged lots of data successfully, and merciless to unknown, untrusted nodes
      - BitSwap Ledger
        
        type Ledger struct {
        owner NodeId
        partner NodeId
        bytes_sent int
        bytes_recv int
        timestamp Timestamp
        }
    - - Object Merkle DAG