Blockchain and Web3 Development: Decentralized Applications dApps Decentralized Storage IPFS Filecoin Arweave

Study Guide – Decentralized Storage (IPFS, Filecoin, Arweave)

What This Is

Decentralized storage moves data off a single server and spreads it across a peer‑to‑peer network. Instead of a cloud provider owning the files, anyone running a node can serve (or “pin”) them, and the content is addressed by a cryptographic hash. This makes NFTs, DAO proposals, or DeFi front‑ends tamper‑proof because the metadata lives on an immutable, censorship‑resistant layer. Real‑world example: an NFT minting dApp stores the artwork on IPFS, pins the hash on Filecoin for long‑term guarantees, and the token’s tokenURI points to that hash—so the image can never be taken down by a centralized host.

Key Terms & Code Snippets

• IPFS (InterPlanetary File System) – A content‑addressed P2P file system; files are retrieved by their SHA‑256 hash (CID).
• CID (Content Identifier) – The multihash string that uniquely represents a piece of data on IPFS (e.g., Qm...).
• Pinning – Keeping a node permanently storing a CID; services like Pinata, Eternum, or your own node can pin.
• Filecoin Deal – A storage contract on the Filecoin network where miners commit to store a CID for a specified duration and price.
• Arweave Permaweb – A blockchain‑like storage layer that charges a one‑time fee for permanent storage; data is written to a “blockweave”.
• tokenURI (Solidity) – Returns a URL or IPFS URI for an NFT’s metadata.

solidity function tokenURI(uint256 tokenId) public view override returns (string memory) {
require(_exists(tokenId), "ERC721: nonexistent token");
return string(abi.encodePacked("ipfs://", _tokenURIs[tokenId])); }

• ipfs-http-client (JS) – Minimal library to add files to IPFS from a Node/Browser.

```js const { create } = require('ipfs-http-client'); const ipfs = create({ url: 'https://ipfs.infura.io:5001/api/v0' });

async function uploadJSON(obj) {
const { cid } = await ipfs.add(JSON.stringify(obj));
return cid.toString(); // → CID } ```

• Web3.Storage (Filecoin) – Simple SDK that uploads to IPFS and automatically creates a Filecoin deal.

```js const { Web3Storage, File } = require('web3.storage'); const client = new Web3Storage({ token: process.env.W3S_TOKEN });

async function storeOnFilecoin(data) {
const file = new File([JSON.stringify(data)], 'metadata.json');
const cid = await client.put([file]); // pins to IPFS + backs with Filecoin
return cid; } ```

• Arweave Transaction (JS) – One‑off payment to write data permanently.

```js const Arweave = require('arweave'); const arweave = Arweave.init({ host: 'arweave.net', port: 443, protocol: 'https' });

async function writeArweave(data) {
const wallet = await arweave.wallets.generate(); // or load existing keyfile
const tx = await arweave.createTransaction({ data: JSON.stringify(data) }, wallet);
tx.addTag('Content-Type', 'application/json');
await arweave.transactions.sign(tx, wallet);
const response = await arweave.transactions.post(tx);
return tx.id; // transaction ID = permanent address } ```

• IPFSResolver (Solidity) – A helper library that converts a CID to a base‑58 string for on‑chain lookup (useful when you need to verify a hash inside a contract).

solidity library IPFSResolver {
function toBase58(bytes memory data) internal pure returns (string memory) {
// minimal implementation omitted for brevity
} }

• gateway vs ipfs:// URI – gateway (e.g., https://ipfs.io/ipfs/<cid>) is HTTP‑compatible; ipfs:// is protocol‑agnostic and preferred for dApp UI code.

Step‑by‑Step / Process Flow

1. Create the asset – Generate JSON metadata + image (or any file) locally.
2. Upload to IPFS – Use ipfs-http-client or a hosted pinning service; capture the returned CID.
3. Back the CID with Filecoin (optional but recommended) – Call client.put() from Web3.Storage or use lotus CLI to make a storage deal, ensuring the data survives beyond the IPFS cache.
4. Write the CID to your smart contract – Call setTokenURI(tokenId, cid) (or similar) from your front‑end via Ethers.js.
5. Read the data in the dApp – Resolve ipfs://<cid> with a public gateway or an in‑app IPFS node; display the image/metadata.
6. (Arweave path) If you need permanent storage, replace steps 2‑3 with a single writeArweave() call; store the returned transaction ID as the URI (ar://<txId>).

Common Mistakes

• Mistake: Storing the full IPFS URL (https://ipfs.io/ipfs/...) in tokenURI.
  Correction: Store only the CID (or ipfs:// URI). This lets you switch gateways later without redeploying the contract.

• Mistake: Assuming a CID is immutable forever.
  Correction: A CID points to a hash of the data; if the underlying data changes, the CID changes. Pin the CID and optionally back it with Filecoin to avoid accidental GC.

• Mistake: Forgetting to set the correct MIME type when uploading to Arweave.
  Correction: Always add a Content-Type tag; otherwise browsers may render the data as plain text, breaking UI expectations.

• Mistake: Using a low‑gas bytes32 field to store a CID (which is ~46‑bytes).
  Correction: Store the CID off‑chain (in a mapping) or keep it as a string/bytes variable; otherwise you’ll truncate the hash.

• Mistake: Relying on a single public IPFS gateway for production.
  Correction: Deploy a fallback strategy (multiple gateways or a local node) to avoid downtime and censorship.

Blockchain Developer Interview / Practical Insights

1. “Explain the difference between IPFS pinning and a Filecoin storage deal.” – Pinning keeps a node alive locally; Filecoin creates a verifiable on‑chain contract that miners must prove they store the data for a set period.
2. “How would you verify on‑chain that a given CID actually points to the data you expect?” – Use a Merkle‑Proof or retrieve the data off‑chain, hash it again, and compare to the stored CID; some projects embed a bytes32 SHA‑256 hash inside the contract for quick verification.
3. “What are the trade‑offs of using Arweave vs. Filecoin for NFT metadata?” – Arweave offers a single upfront fee and true permanence, but higher cost per MB; Filecoin is cheaper for large files but requires monitoring deal expiration and may need re‑pinning.
4. “Why might a DAO choose to store proposals on Arweave rather than IPFS?” – Because DAO votes need immutable, audit‑ready records that cannot be pruned; Arweave guarantees that the proposal text will never disappear, even if the IPFS network loses the CID.

Quick Check Questions

1. Scenario: Your NFT contract stores tokenURI = "https://ipfs.io/ipfs/QmX...". The gateway goes down. What happens?
   Answer: The UI can’t fetch the metadata, breaking the NFT display.
   Why: The contract hard‑coded an HTTP gateway; swapping to another gateway requires a contract upgrade.

2. Scenario: A developer uploads a 5 MB image to IPFS, then immediately deletes the local node. Will the image stay accessible?
   Answer: Not necessarily; unless another node pins it or a Filecoin deal is made, the content may be garbage‑collected.

3. Scenario: You see a contract that stores a CID in a bytes32 variable. Is this safe?
   Answer: No – a CID is ~46 bytes; truncating it loses data and makes the hash invalid.

Last‑Minute Cram Sheet (10 one‑liners)

1. ⚠️ Never store a full gateway URL in a contract; store only the CID (ipfs://<cid>).
2. IPFS uses content‑addressing: the CID is the SHA‑256 hash of the file’s bytes.
3. Filecoin deals are on‑chain storage contracts; they require a miner to submit a proof‑of‑replication.
4. Arweave’s “perma‑fee” = price_per_byte * file_size; the fee is paid once, no renewal needed.
5. web3.storage automatically pins to IPFS and backs with Filecoin – a one‑step solution for most dApps.
6. Gas tip: Store CIDs as string (dynamic) rather than bytes32 to avoid truncation and extra conversion cost.
7. When reading from IPFS in the browser, prefer https://<gateway>/ipfs/<cid> or the ipfs:// protocol with a library like ipfs-http-client.
8. Pinning services charge per GB‑month; Filecoin charges per epoch (≈30 seconds) and is cheaper for long‑term storage.
9. Arweave transactions are immutable; you cannot delete or edit data once written.
10. Security trap: Do not trust user‑provided CIDs for on‑chain logic without off‑chain verification; a malicious CID can point to harmful content.

You now have a ready‑to‑code, interview‑proof cheat sheet for decentralized storage. Happy building!