IPFS and Filecoin

IPFS

IPFS is a peer-to-peer content-addressed data network. A file is chunked into blocks, each block is hashed, and the root becomes a CID (Content Identifier). If a client asks for a CID, any peer with the blocks can serve it. The client verifies the blocks by hash.

Key mechanics:

• CIDs. Self-certifying identifiers that include a multihash and codec information.
• DAGs. Files and directories are represented as Merkle DAGs.
• Bitswap. Block exchange protocol used by IPFS peers.
• libp2p. Networking stack for peer discovery, streams, and transports.
• Gateways. HTTP bridges that let browsers fetch IPFS content without running a local node.

IPFS solves integrity and distribution. It does not automatically solve persistence. Content stays available only while at least one reachable node pins or serves it.

Filecoin

Filecoin is a storage market built around cryptographic storage proofs. Clients make deals with storage providers; providers commit data into sectors and periodically prove they still store it.

Core pieces:

• Storage deals. Client and provider agree on size, duration, price, and collateral.
• Proof-of-Replication. Provider proves a unique sealed copy of the data exists.
• Proof-of-Spacetime. Provider repeatedly proves storage over the deal duration.
• Sectors. Storage units sealed by providers and proven on-chain.
• Retrieval markets. Data retrieval can happen through separate retrieval paths and gateways.

Filecoin is not "IPFS with a token." IPFS retrieves content by CID. Filecoin creates economic guarantees that someone stores a piece over time.

How They Compose

User data
  → chunk / encode
  → CID or PieceCID
  → pin locally / publish via IPFS
  → make Filecoin storage deals for persistence
  → publish CID through ENS, PKARR, website, Nostr, or signed metadata

For user-facing applications, the common stack is:

1. Put data in IPFS-compatible form.
2. Pin it on at least two pinning providers.
3. Store archival copies through Filecoin deals.
4. Publish the CID in a signed index or decentralized name.

Use Cases

Trade-offs

Strengths

• Content hashes make tampering obvious.
• Gateway and provider choice reduce platform lock-in.
• Filecoin proofs make storage claims auditable.
• CIDs compose cleanly with decentralized names and smart contracts.

Limitations

• IPFS availability depends on pinning.
• Public gateways leak request metadata and can censor.
• Filecoin deal UX remains more complex than ordinary cloud storage.
• Retrieval performance depends on provider behavior and caching.
• Plaintext data is public data unless encrypted first.

Attack Surface

Primary sources

• Benet: IPFS, Content Addressed, Versioned, P2P File System
• IPFS persistence and pinning
• Filecoin storage proofs
• Trautwein et al.: Design and Evaluation of IPFS
• Filecoin protocol specification

Continue with IPNS and DNSLink for naming, BitTorrent for Archive Distribution for another distribution model, and Choosing Decentralized Storage for the retention and privacy comparison.