InterPlanetary File System (IPFS)

IPFS uses Content Identifiers (CIDs), cryptographic hashes of the content itself, instead of location-based addresses (URLs). This means:

• Immutable Linking: A CID uniquely and permanently identifies a specific piece of data.
• Verifiability: Users can verify they received the exact data they requested by checking the hash.
• Deduplication: Identical content stored by different users is only stored once on the network.

IPFS uses a Distributed Hash Table (DHT) as its core discovery mechanism. This decentralized directory allows nodes to:

• Find Providers: Locate which peers are storing (pinning) a specific piece of content (CID).
• Find Peers: Discover other network participants to connect to.
• The DHT ensures the network is resilient, with no central server controlling data lookup, making it censorship-resistant.

Data in IPFS is structured as a Merkle Directed Acyclic Graph (DAG). This data model provides:

• Tamper-Evidence: Any change to data changes its hash and all parent hashes up to the root.
• Efficient Versioning: New versions of files can share unchanged blocks, saving storage (similar to Git).
• Composability: Complex data structures (like directories, repositories, or blockchains) can be built by linking CIDs together.

IPFS retrieves content via a peer-to-peer bitswap protocol. When a node requests a CID, it:

• Queries the DHT to find provider nodes.
• Connects directly to those peers to request the data blocks.
• Can simultaneously request different blocks from multiple peers for faster retrieval.
• This model distributes bandwidth load and reduces reliance on origin servers, enhancing availability and performance for popular content.

To address mutable content in an immutable system, IPFS provides naming layers:

• IPNS (InterPlanetary Name System): Creates a mutable pointer (linked to a node's cryptographic key) that can be updated to point to a new CID.
• DNSLink: Uses the traditional DNS system to publish a CID, allowing human-readable domains (e.g., docs.ipfs.tech) to resolve to IPFS content. This bridges the decentralized and legacy web.

Data persists on IPFS only while at least one node on the network stores it. Key concepts ensure availability:

• Pinning: A node explicitly marks content to store permanently, preventing garbage collection.
• Pinning Services: Third-party services (like Pinata, web3.storage) offer persistent pinning.
• Incentivized Storage: Protocols like Filecoin build an incentive layer on top of IPFS, paying nodes to store data via verifiable storage deals.

IPFS uses Content Identifiers (CIDs), cryptographic hashes derived from the content itself, rather than location-based addresses (URLs). This means:

• Immutable Links: A CID always points to the exact same data.
• Verifiability: You can verify the data's integrity by recomputing the hash.
• Decentralization: Data can be retrieved from any node that has it, not just a central server.

Example: A CID like QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco uniquely identifies a specific Wikipedia page snapshot.

IPFS operates as a peer-to-peer network where nodes store and serve content. When you request a file by its CID, the network finds nodes storing that data using a Distributed Hash Table (DHT). Key mechanisms include:

• Bitswap: A protocol for requesting and sending blocks of data between peers.
• IPNS (InterPlanetary Name System): A system for creating mutable, human-readable pointers to CIDs, allowing for updated content.
• Pinning: The act of telling your node to permanently store specific data, ensuring its persistence on the network.

IPFS is the standard for storing off-chain NFT metadata and media (images, videos). Storing these assets on IPFS ensures:

• Permanence: The link in the NFT's smart contract (the CID) is immutable.
• Decentralization: Assets aren't reliant on a single company's servers.
• Verifiability: Anyone can cryptographically verify the asset is the original.

A typical NFT tokenURI might point to: ipfs://QmXoy.../metadata.json. This JSON file, also on IPFS, contains the image link and attributes.

dApps use IPFS to host their front-end code and static assets, making them resistant to censorship and downtime. Key use cases:

• Front-End Hosting: Deploying HTML, CSS, and JavaScript files on IPFS (e.g., via Fleek or Pinata).
• Data Storage: Storing user-generated content, configuration files, or datasets in a decentralized manner.
• Data Availability for Blockchains: Providing a verifiable data layer for Layer 2 solutions and modular blockchains that need to post data off-chain.

IPFS represents a paradigm shift from location-based addressing (HTTP) to content-based addressing. A comparison:

HTTP/HTTPS (Location-Based)

• Address: https://server.com/file.jpg
• Fetch: From a specific server.
• Failure: If the server is down, content is lost.
• Centralized: Controlled by server owner.

IPFS (Content-Based)

• Address: ipfs://QmHash... (CID)
• Fetch: From any peer who has the data.
• Resilience: Content persists as long as one node hosts it.
• Decentralized: No single point of control or failure.

IPFS uses Content Identifiers (CIDs) to address data, creating a cryptographic hash of the content itself. This ensures immutability—the same data always produces the same CID. However, this is a guarantee of data integrity, not availability. If no node on the network is hosting the content, it becomes inaccessible, a state known as content eviction.

Data on IPFS is not stored permanently by default; nodes cache content based on demand and clear it to save space. To ensure persistence, data must be pinned. This requires:

• Running your own IPFS node and pinning content.
• Using a commercial pinning service (e.g., Pinata, Infura, Filecoin).
• This introduces operational overhead and potential centralization points, as reliance on a single pinning service creates a single point of failure.

A core trade-off exists between decentralization and reliable data availability. While IPFS is a peer-to-peer protocol, popular content is easily retrievable, but niche or unpinned data can disappear. Solutions like Filecoin (a blockchain built on IPFS) incentivize long-term storage via cryptographic proofs and payments, but add protocol complexity and cost. Pure IPFS relies on altruism or direct payment to pinning services.

By default, content added to a public IPFS node is accessible to anyone who has its CID. This presents challenges:

• No native encryption: Data must be encrypted client-side before being stored.
• Metadata leakage: Node operators can see which CIDs are being requested.
• Private networks: Possible but complex to configure, often defeating the purpose of public decentralized storage. For sensitive data, careful encryption and access control layers are mandatory.

Blockchains like Ethereum use IPFS to store large data (e.g., NFT metadata) by storing only the CID on-chain. This creates a cryptographic commitment. The critical security assumption is that the content referenced by the CID remains available and unchanged. If the off-chain content is altered or lost, the on-chain reference points to invalid or missing data, breaking the application's logic (link rot).

Retrieval speed in IPFS is not guaranteed and depends on network topology. Key factors include:

• Geographic distribution of nodes hosting the content.
• Network connectivity and peer discovery speed.
• Use of Content Routing mechanisms (DHT, Bitswap). For time-sensitive dApp interactions, this variable latency can be problematic. Developers often use gateways (like ipfs.io) for faster HTTP access, but this centralizes the request path.