Розробка децентралізованої системи зберігання даних

Розробка децентралізованих систем зберігання даних

Якщо ви читаєте це після того, як ваш AWS S3 bucket став причиною регуляторних претензій, або після чергового "ми оновлюємо інфраструктуру" від централізованого сховища — ласкаво просимо. Децентралізоване зберігання даних — це не про ідеологію, а про конкретні властивості: відсутність єдиної точки відмови, верифікованість контенту через content addressing та можливість зберігати дані без дозволу оператора.

У 2024 році під "децентралізованим зберіганням" розуміють три принципово різних стека: IPFS + Filecoin, Arweave та Storj/Sia (incentivized distributed storage). Кожний підходить для своєї категорії задач.

IPFS + Filecoin: content addressing та економіка зберігання

IPFS — це не сховище, це адресація та транспорт. Content Identifier (CID) — це multihash контенту файлу, обчислений за замовчуванням як SHA2-256 через DAG-структуру (dag-pb з UnixFS). Якщо файл змінився — CID змінився. Ця фундаментальна властивість робить IPFS придатним для NFT-метаданих, верифіковних документів, незмінюваних артефактів.

Проблема IPFS: pinning. Якщо ваш вузол перестав пінити контент — він зникне з мережі. Filecoin додає економіку: storage providers отримують FIL за зберігання верифікованих deals.

Робота з IPFS Cluster

Для production систем потрібен IPFS Cluster — координатор репліції поверх кількох IPFS-вузлів. Мінімальна конфігурація: 3 вузли, replication factor 2.

// Приклад pinning через Cluster REST API
type ClusterPinRequest struct {
    CID            string            `json:"cid"`
    ReplicationMin int               `json:"replication-min"`
    ReplicationMax int               `json:"replication-max"`
    Name           string            `json:"name"`
    Meta           map[string]string `json:"meta"`
}

func PinToCluster(cid string, name string) error {
    req := ClusterPinRequest{
        CID:            cid,
        ReplicationMin: 2,
        ReplicationMax: 3,
        Name:           name,
    }
    body, _ := json.Marshal(req)
    resp, err := http.Post(
        "http://cluster-api:9094/pins/" + cid,
        "application/json",
        bytes.NewReader(body),
    )
    // ...
    return err
}

Для завантаження великих файлів критично важливо використовувати chunking strategy. За замовчуванням IPFS використовує size-262144 (256 KB chunks), але для відео та великих бінарних файлів rabin chunker дає краще дедуплювання завдяки content-defined boundaries:

ipfs add --chunker=rabin-262144-524288-1048576 large_file.bin

Filecoin Storage Deals

Пряма робота з Filecoin через Lotus — це низькорівневий шлях. Для production використовують Estuary (deprecated) або сучасний Lighthouse SDK / web3.storage:

import { Web3Storage } from 'web3.storage'

const client = new Web3Storage({ token: process.env.W3S_TOKEN })

async function storeWithReplication(files: File[]): Promise<string> {
    const cid = await client.put(files, {
        wrapWithDirectory: false,
        onRootCidReady: (rootCid) => {
            console.log('Root CID:', rootCid) // доступний до завершення завантаження
        },
        onStoredChunk: (size) => {
            console.log(`Uploaded chunk of ${size} bytes`)
        }
    })
    return cid
}

web3.storage робить hot IPFS pinning + холодний Filecoin deal автоматично. Для enterprise — NFT.Storage з аналогічним API але фокусом на метаданих.

Arweave: permanent storage із одноразовою оплатою

Arweave — інша модель: платиш один раз, дані зберігаються "назавжди" (endowment fund розраховується на 200+ років при консервативних припущеннях про удешевлення зберігання). Це принципово змінює use cases.

Коли Arweave — правильний вибір:

• Smart contract source code та ABI (верифікованість назавжди)
• NFT-метаданих та медіа (уникнути NFT rot)
• Юридичні та нотаріальні документи
• Протоколи управління та результати голосувань (DAO governance history)

Дані в Arweave — це transaction з data полем та тегами. Теги — ключ до індексації через GraphQL:

import Arweave from 'arweave'
import { WarpFactory } from 'warp-contracts'

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

async function uploadDocument(data: Buffer, mimeType: string, metadata: Record<string, string>) {
    const tx = await arweave.createTransaction({ data })

    tx.addTag('Content-Type', mimeType)
    tx.addTag('App-Name', 'YourDApp')
    tx.addTag('Version', '1.0.0')

    // Користувальницькі теги для пошуку через GraphQL
    for (const [key, value] of Object.entries(metadata)) {
        tx.addTag(key, value)
    }

    await arweave.transactions.sign(tx, jwk)
    const response = await arweave.transactions.post(tx)

    return tx.id // постійний ID документа
}

Запрос до Arweave через ArQL / GraphQL для пошуку документів за тегами:

query FindDocuments($owner: String!, $docType: String!) {
  transactions(
    owners: [$owner]
    tags: [
      { name: "App-Name", values: ["YourDApp"] }
      { name: "Document-Type", values: [$docType] }
    ]
    first: 100
  ) {
    edges {
      node {
        id
        tags { name value }
        block { timestamp }
      }
    }
  }
}

Bundlr / Irys: батчева загрузка та миттєва фіналізація

Нативні Arweave транзакції підтверджуються ~2 хвилини, це проблема для UX. Irys (раніше Bundlr) вирішує це через layer 2 поверх Arweave: транзакції підтверджуються миттєво, батчуються та постяться в Arweave.

import Irys from '@irys/sdk'

const irys = new Irys({
    url: 'https://node1.irys.xyz',
    token: 'ethereum',
    key: privateKey,
})

// Перевірка вартості до завантаження
const price = await irys.getPrice(data.length)
console.log(`Cost: ${irys.utils.fromAtomic(price)} ETH`)

// Завантаження з тегами
const receipt = await irys.upload(data, {
    tags: [
        { name: 'Content-Type', value: 'application/json' },
        { name: 'Contract-Address', value: contractAddress },
    ]
})
// receipt.id — TXID, доступен одразу через https://gateway.irys.xyz/{id}

Гібридна архітектура: гарячого + холодного зберігання

У реальних системах рідко використовують лише один протокол. Типова архітектура для DApp з вимогами до продуктивності та постійності:

Запис даних:
User → App Backend → [паралельно]:
    1. IPFS Cluster (hot, швидкий доступ, ~3 репліки)
    2. Irys → Arweave (cold, permanent, 1-2 хв)
    3. PostgreSQL (CID + Arweave TXID + метаданих, для пошуку)

Читання даних:
User → App Backend → PostgreSQL (lookup CID/TXID)
    → IPFS Gateway (швидко, якщо пінед)
    → Fallback: Arweave Gateway (якщо IPFS недоступний)

Це дає: миттєве читання через IPFS, гарантію постійності через Arweave та пошук через звичайну базу даних.

Верифікація цілісності

Content addressing — це верифікація "з коробки" для IPFS: CID — це хеш контенту. Для Arweave верифікація через транзакційні докази:

async function verifyArweaveData(txId: string, expectedHash: string): Promise<boolean> {
    const tx = await arweave.transactions.get(txId)
    const data = await arweave.transactions.getData(txId, { decode: true })
    const hash = crypto.createHash('sha256').update(data as Buffer).digest('hex')
    return hash === expectedHash
}

Шифрування та контроль доступу

Децентралізоване зберігання не означає публічне. Для чутливих даних — Lit Protocol для threshold encryption з on-chain умовами доступу:

import * as LitJsSdk from '@lit-protocol/lit-node-client'

// Умова доступу: власник NFT з колекції
const accessControlConditions = [{
    contractAddress: NFT_CONTRACT,
    standardContractType: 'ERC721',
    chain: 'ethereum',
    method: 'balanceOf',
    parameters: [':userAddress'],
    returnValueTest: { comparator: '>', value: '0' }
}]

// Шифрування перед завантаженням в IPFS
const { ciphertext, dataToEncryptHash } = await LitJsSdk.encryptString(
    { accessControlConditions, dataToEncrypt: sensitiveData },
    litNodeClient
)

// Розшифрування — тільки при виконанні умови on-chain
const decrypted = await LitJsSdk.decryptToString(
    { accessControlConditions, ciphertext, dataToEncryptHash, chain: 'ethereum' },
    litNodeClient
)

Модель вартості та вибір стека

Для NFT-проектів та DAO: Arweave через Irys — єдиний розумний вибір, вартість метаданих незначна, постійність критична. Для даних додатків з високими вимогами до latency: IPFS Cluster з hot replication + Filecoin для архівних копій. Для enterprise з compliance вимогами: гібридна схема з шифруванням через Lit Protocol.