IPFS-інфраструктура під ключ: зберігання та роздача

Розробка IPFS-інфраструктури

Уявіть: ви запустили NFT-колекцію на 10 000 токенів. Метадані та зображення завантажені в IPFS через публічний шлюз. Через місяць нода, на якій все було піновано, падає — і метадані стають недоступні. Колекціонери не бачать атрибути, маркетплейси не можуть вивести прев'ю. Це коштувало одному проекту втрати 40% вторинних продажів та репутаційної шкоди. Така ситуація — прямий наслідок ілюзії, що IPFS автоматично гарантує доступність.

Ми будуємо IPFS-інфраструктуру, яка дійсно тримає навантаження і не втрачає дані. Під ключ: від вибору заліза до налаштування моніторингу та резервного піннінгу в кількох сервісах. Нижче — реальний стек, який ми використовуємо в продакшені, та конкретні цифри, яких можна досягти.

Чому своя нода — не розкіш, а необхідність?

Використовувати тільки публічні шлюзи (ipfs.io, dweb.link) — ризик: вони можуть обмежувати RPM (requests per minute), блокувати контент за регіоном або просто впасти. Своя нода дає повний контроль: ліміти під ваш проект, стабільні затримки, можливість кастомної обробки помилок. На практиці це означає час відгуку в 3 рази нижчий, ніж через публічний шлюз, та відсутність rate limiting навіть при 10 000 запитів на секунду.

┌─────────────────────────────────────────────────────┐ │ Your Application │ │ │ │ Upload: File → IPFS Node → CID → Smart Contract │ │ Fetch: CID → IPFS Gateway → File │ └───────────────────┬─────────────────────────────────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ Your IPFS Pinata / Cloudflare Node Web3.Storage IPFS GW (primary) (redundancy) (public GW) 

Які ризики multi-pinning вирішує?

Локального піннінгу недостатньо. Якщо ваш сервер лежить — ніхто не отримає дані. Стратегія multi-pinning (своя нода + Pinata + Web3.Storage) дає доступність 99.9%. Порівняйте: тільки своя нода — 0% при відмові, своя + Pinata — 99%, всі три — 99.9%. Різниця між 99% та 99.9% — приблизно 8 годин недоступності на рік проти 43 хвилин. Для NFT-проекту з щоденними торгами це критично.

Стратегія піннінгу для NFT проекту:

• Власна нода — первинне сховище, швидкий доступ
• Pinata — перший backup, надійний сервіс, платний
• web3.storage (Filecoin-backed) — другий backup, зберігає дані на Filecoin з верифікованими deal receipts
• Nft.storage — спеціалізовано для NFT, Filecoin + IPFS

Як налаштувати remote pinning: покроковий план

1. Розгорнути Kubo ноду з оптимізованим конфігом (server profile, вимкнено автоматичний GC).
2. Зареєструватися в Pinata, отримати JWT-токен.
3. Налаштувати скрипт завантаження, який пінить на локальній ноді та одночасно відправляє запит на remote pin через API Pinata.
4. Повторити для Web3.Storage.
5. Написати перевірку статусу піннінгу (queued → pinning → pinned → failed).

import { create } from 'kubo-rpc-client'; import * as fs from 'fs'; const ipfs = create({ url: 'http://localhost:5001' }); async function uploadFile(filePath: string): Promise<string> { const file = fs.readFileSync(filePath); const result = await ipfs.add(file, { pin: true, cidVersion: 1, }); return result.cid.toString(); } async function uploadDirectory(dirPath: string): Promise<string> { const files = []; for (const filename of fs.readdirSync(dirPath)) { files.push({ path: filename, content: fs.readFileSync(`${dirPath}/${filename}`), }); } let rootCid = ''; for await (const file of ipfs.addAll(files, { wrapWithDirectory: true, pin: true, cidVersion: 1, })) { if (file.path === '') { rootCid = file.cid.toString(); } } return rootCid; } 

Порівняння підходів до піннінгу

Порівняння IPFS-шлюзів

GC та моніторинг: як не втратити дані

# Ручний GC (запускаємо за розкладом, не залишаємо на автоматі) ipfs repo gc # Статистика репозиторію ipfs repo stat # Список всіх локальних pins ipfs pin ls --type=recursive | wc -l # Перевірка, що конкретний CID доступний локально ipfs pin ls bafybeig... 2>/dev/null && echo "pinned" || echo "not pinned" 

Моніторинг: Prometheus експортер для IPFS (ipfs stats bw, ipfs stats repo) + алерт на ipfs swarm peers — якщо менше 10 пірів, нода ізольована. Алерт якщо pin count несподівано зменшився (GC видалив щось важливе).

Коли IPFS не потрібен

IPFS надлишковий для тимчасових даних (аватарки користувачів, які змінюються), даних, що вимагають видалення (GDPR), та даних з частим оновленням. Для цього — звичайний S3 або CDN. IPFS має сенс для: NFT метаданих та медіа (імутабельність важлива), смарт-контрактних артефактів (ABI, bytecode), decentralized storage з верифікованістю.

Що входить в роботу

Ми надаємо не просто налаштування ноди — ми віддаємо готову інфраструктуру з документацією та підтримкою. У стандартний пакет входить:

• Розгортання Kubo ноди з оптимізованим конфігом під server profile
• Налаштування systemd unit з авторестартом та ротацією логів
• Інтеграція з Pinata та Web3.Storage через Remote Pin API (схема multi-pinning)
• Nginx/Cloudflare gateway з кешуванням та CORS
• Скрипти завантаження та піннінгу на TypeScript/Node.js (або Python за запитом)
• Prometheus + Grafana дашборд за ключовими метриками (swarm peers, disk usage, pin count)
• Документація з експлуатації (ручний GC, моніторинг, відновлення)

Оцінимо ваш проект за 2 робочих дні — напишіть, ми надішлемо технічний аудит з рекомендаціями. Отримайте консультацію: як прискорити вашу IPFS-інфраструктуру та знизити витрати на 30% порівняно з публічними шлюзами. Наша гарантія — 99.9% доступності даних при дотриманні схеми multi-pinning.