Menyimpan data di storage terdesentralisasi: IPFS dengan CID dan pinning, Arweave yang permanen, dan Filecoin untuk penyimpanan terverifikasi, plus strategi metadata NFT di IPFS serta kapan data on-chain dan off-chain

Setelah di episode 12 UI kalian bisa menampilkan data real-time, pada episode ini kita menjawab pertanyaan arsitektur yang sudah tertunda sejak episode 2: di mana menyimpan file besar? Jawabannya hampir tidak pernah di blockchain — karena menyimpan 1 MB di Ethereum sangat mahal.
Mengapa episode ini penting? Karena hampir semua NFT dan DApp yang mengandung gambar, audio, atau dokumen memakai storage terdesentralisasi. Memahami CID, pinning, dan trade-off antar layanan menentukan apakah metadata NFT kalian bertahan 10 tahun atau hilang setelah Pinata gratis kedaluwarsa.
IPFS adalah protokol file peer-to-peer: file dipecah, di-hash, dan didistribusikan di banyak node. Identitas file bukan URL server, melainkan CID (Content Identifier) — hash isi file.
Sifat unik CID: content-addressed. Dua file dengan isi sama punya CID sama; mengubah satu byte mengubah CID. Ini memungkinkan verifikasi integritas: siapa pun yang mengunduh CID bisa membuktikan isinya asli.
ipfs add metadata.jsonOutputnya sebuah CID seperti Qm... (atau bafy...). Untuk memastikan file tetap tersedia, file harus di-pin — dijaga hidup oleh node yang memegangnya.
IPFS tidak menjanjikan persistensi: jika tidak ada node yang menyimpan file, ia hilang. Pinning adalah janji sebuah node untuk terus menyimpan file. Layanan pinning populer: Pinata, Web3.Storage, Filebase, dan NFT.Storage.
const form = new FormData()
form.append("file", fileBlob)
const res = await fetch("https://api.pinata.cloud/pinning/pinFileToIPFS", {
method: "POST",
headers: { Authorization: `Bearer ${PINATA_JWT}` },
body: form,
})
const { IpfsHash } = await res.json() // CIDArweave dirancang untuk penyimpanan sekali bayar, permanen: user membayar sekali dan data disimpan selamanya (didanai perpetual endowment). Ini berbeda fundamental dari IPFS yang butuh pinning berkelanjutan.
| Aspek | IPFS | Arweave |
|---|---|---|
| Identitas | CID (content-addressed) | Arweave TX ID |
| Biaya | Gratis upload, bayar pinning | Sekali bayar, permanen |
| Persistensi | Tergantung pinning | Dijamin permanen |
| Akses | lewat gateway (ipfs.io, pinata.cloud) | lewat gateway (arweave.net) |
| Cocok untuk | Metadata NFT, konten aktif | Data arsip, dokumen legal, permanen |
Filecoin adalah pasar penyimpanan: penyedia (miner) menyimpan file dan membuktikannya secara berkala lewat proofs on-chain. User membayar untuk kontrak penyimpanan yang bisa diverifikasi.
Kombinasi umum: IPFS untuk akses cepat + Filecoin untuk persistensi yang dibuktikan. Sering dipakai untuk data besar: dataset, backup, dan content yang perlu bukti penyimpanan.
Pola standar NFT: kontrak menyimpan tokenURI yang menunjuk ke JSON metadata, dan JSON menunjuk ke gambar di IPFS:
{
"name": "Koleksi #1",
"description": "Contoh metadata NFT di IPFS",
"image": "ipfs://QmXk7k...",
"attributes": [
{ "trait_type": "warna", "value": "biru" }
]
}Kontrak menyimpan ipfs://bafybe.../1.json sebagai tokenURI. Wallet dan marketplace menampilkan gambar dari CID tersebut.
Warning
Hati-hati dengan "IPFS metadata yang mudah rusak": banyak koleksi NFT menyimpan metadata di server terpusat atau pinning gratis yang kedaluwarsa. Untuk produksi, gunakan layanan pinning berbayar, pertimbangkan Arweave untuk nilai jangka panjang, dan pastikan tokenURI menunjuk ke URI permanen — bukan ke ipfs:// CID yang tidak pernah di-pin.
Pertanyaan kunci setiap DApp: data mana yang on-chain, mana yang off-chain?
| Jenis Data | Tempat | Alasan |
|---|---|---|
| Kepemilikan, saldo, logika | On-chain (contract) | Perlu konsensus & verifikasi |
| Gambar, audio, dokumen | IPFS/Arweave | Terlalu besar/mahal untuk on-chain |
| Data pribadi | Jangan di chain sama sekali | Publik permanen |
| Data ephemeral | Off-chain biasa | Tidak perlu verifikasi |
| Nilai & aset | On-chain | Harus provable & portable |
Aturan sederhananya: apa pun yang harus bisa diverifikasi siapa pun, taruh on-chain; apa pun yang besar atau pribadi, taruh di luar — dengan CID/permanent link jika perlu persistensi.
Rangkuman yang sudah kalian pelajari di episode 13:
tokenURI → JSON di IPFS → gambar di IPFS.Inti yang harus dibawa pulang:
Di episode 14 selanjutnya, kita membahas indexing: The Graph & subgraph — mengapa query on-chain langsung tidak cukup, struktur subgraph (subgraph.yaml, schema.graphql, mappings), cara deploy, dan query GraphQL dari frontend plus alternatif SubQuery dan Goldsky. Sampai jumpa di episode 14!