Разработка 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.