Storj: Penyimpanan Cloud Terdesentralisasi dengan Erasure Coding, Audit Merkle, dan Enkripsi Client-Side

Penulis Wilkinson, Shawn; Buterik, Tome; et al. (Storj Labs)
Tahun 2016
Proyek Storj
Lisensi MIT
Sumber Resmi storj.io/storj.pdf
Disclaimer: Halaman ini merupakan ringkasan dan analisis edukatif dari whitepaper atau makalah teknis resmi. Konten ini disajikan untuk tujuan pendidikan semata dan bukan merupakan saran investasi atau keuangan. Selalu baca dokumen asli dan lakukan riset mandiri sebelum mengambil keputusan keuangan apa pun.

Storj adalah whitepaper dari Storj Labs (versi dari 2016 hingga 2018, dengan versi terbaru mendeskripsikan arsitektur Storj V3) yang mendeskripsikan marketplace penyimpanan cloud terdesentralisasi. Dalam Storj: file dienkripsi client-side sebelum meninggalkan perangkat pengunggah; file dibagi menjadi erasure-coded shard; shard didistribusikan ke jaringan global Storage Node Operators (SNO) independen; audit kriptografis memverifikasi bahwa SNO benar-benar menyimpan shard yang mereka klaim simpan; dan pengguna membayar dalam token STORJ (atau kredit berbasis kartu kredit) berdasarkan GB-bulan aktual yang disimpan dan GB yang ditransfer.

Storj adalah salah satu protokol penyimpanan terdesentralisasi yang sedikit yang mencapai product-market fit nyata — digunakan oleh enterprise nyata untuk penyimpanan file produksi dengan harga ~$4/TB/bulan vs. ~$23/TB/bulan AWS S3.

Konteks: Dominasi Cloud Terpusat

Pada 2016, penyimpanan cloud didominasi oleh AWS S3, Google Cloud Storage, dan Dropbox — semua terpusat, tunduk pada pelanggaran data, kenaikan harga, dan pembatasan geografis. Storj mengusulkan marketplace yang menggantikan kepercayaan single-provider dengan verifikasi kriptografis, menawarkan biaya lebih rendah dengan memanfaatkan penyimpanan yang tidak terpakai di mesin SNO di seluruh dunia, dan menjaga privasi dengan mengenkripsi semua data sebelum meninggalkan pengguna.

Arsitektur Tiga Lapisan

1. Klien (Pengunggah/Pengunduh)

  • Menghasilkan kunci enkripsi unik (diturunkan dari passphrase master)
  • Mengenkripsi file client-side menggunakan AES-256-GCM sebelum data mana pun meninggalkan perangkat
  • Menerapkan Reed-Solomon erasure coding untuk membuat 80 piece di mana 29 mana pun dapat merekonstruksi file
  • Mengunggah piece ke SNO via koneksi TCP langsung (bukan melalui server pusat)

2. Satellite (Koordinator Metadata)

  • Node tepercaya (tetapi tidak menyimpan) yang menyimpan metadata file: piece mana yang ada, SNO mana yang menyimpannya, hash piece
  • Mengkoordinasikan koneksi pengunggah-ke-SNO
  • Melakukan audit untuk memverifikasi SNO menyimpan data
  • Menangani pembayaran ke SNO berdasarkan hasil audit + pengiriman bandwidth
  • Satellite adalah titik sentralisasi — Storj Labs menjalankan satellite resmi; satellite pihak ketiga dimungkinkan tetapi jarang

3. Storage Node Operators (SNO)

  • Individu atau bisnis dengan kapasitas disk yang memiliki dan menjalankan software Storj Node
  • Menerima unggahan piece, melayani unduhan piece, merespons audit
  • Mendapatkan token STORJ untuk storage-bulan yang dipertahankan (diverifikasi oleh audit) dan GB yang ditransfer

Erasure Coding: Reed-Solomon

Storj menggunakan Reed-Solomon erasure coding (algoritma yang sama digunakan dalam penyimpanan RAID dan Blu-ray):

  • Untuk file ukuran S: bagi menjadi k=29 piece data, hasilkan n=80 piece total (51 piece paritas)
  • Piece mana pun dari 80 yang tersedia 29 dapat merekonstruksi file asli
  • Bahkan jika 51 dari 80 SNO offline secara bersamaan, file tetap dapat diambil sepenuhnya

Protokol Audit: Tantangan Merkle

Bagaimana Satellite memverifikasi SNO benar-benar menyimpan piece?

  1. Ketika SNO menerima piece, ia membuat Merkle tree atas data piece dan mengirimkan Merkle root ke Satellite
  2. Secara berkala, Satellite mengirimkan tantangan: berikan Merkle proof untuk leaf i
  3. SNO harus mengembalikan data di posisi i dan Merkle proof yang menunjukkan ia cocok dengan committed root
  4. Jika SNO menghapus data, mereka tidak dapat menghasilkan proof yang valid tanpa piece penuh

SNO yang gagal audit memiliki skor reputasi berkurang; kegagalan berulang mengakibatkan penghapusan dari jaringan dan penyitaan token STORJ yang disimpan dalam escrow.

Macaroons Kriptografis

Storj menggunakan macaroons (generalisasi bearer token oleh Google Research) untuk kontrol akses:

  • Pengunggah mencetak macaroon root untuk file/bucket dengan izin penuh
  • Mereka dapat mengecilkan macaroon: membuat macaroon turunan yang hanya memberikan akses baca, atau akses baca sampai tanggal tertentu
  • Macaroon turunan tidak dapat melebihi izin induknya

Kompatibilitas S3

Storj sepenuhnya kompatibel S3: klien AWS S3 standar (boto3, rclone, AWS CLI) bekerja dengan endpoint Storj. Ini adalah keputusan kritis adoption — developer tidak perlu belajar API baru.

Catatan Realistis

  • Storj adalah layanan penyimpanan terdesentralisasi yang berfungsi nyata dan digunakan oleh enterprise nyata — langka dalam ruang ini.
  • Sentralisasi Satellite: Storj Labs’ Satellite adalah koordinator pusat. Jika Storj Labs mematikan Satellite mereka, file menjadi tidak dapat diakses (meskipun pengguna dapat menjalankan Satellite sendiri).
  • Resistansi sensor terbatas: Enkripsi client-side mencegah Storj membaca konten, tetapi Satellite dapat menonaktifkan akses ke file atau akun tertentu.
  • Variabilitas latensi: Kualitas unduhan dari beberapa SNO kurang dapat diprediksi dari CDN-backed S3 untuk beban kerja throughput-sensitif.

Warisan

Storj adalah salah satu protokol penyimpanan terdesentralisasi yang sedikit yang mencapai product-market fit nyata. Desain audit-nya (tantangan Merkle vs. PoRep/PoSt Filecoin) lebih sederhana namun cukup untuk persyaratan durabilitas dunia nyata. Pendekatan erasure coding untuk keandalan penyimpanan terdistribusi telah mempengaruhi desain penyimpanan terdesentralisasi selanjutnya.

Istilah Terkait

Referensi

  • Wilkinson, S.; Buterik, T.; et al. (2016). Storj: A Peer-to-Peer Cloud Storage Network. storj.io/storj.pdf