Централізоване зберігання метаданих NFT — ризик, який може знецінити колекцію. Сервер впав, домен помер, провайдер змінив політику — і власники токенів бачать порожнє місце замість зображення. IPFS вирішує це на протокольному рівні: адреса файлу (CID) залежить лише від його вмісту. Змінити файл, не змінивши CID, неможливо. Це фундаментальна властивість робить IPFS єдиним правильним вибором для розміщення метаданих NFT. Ми використовуємо IPFS у всіх своїх проектах і забезпечуємо незмінність даних без компромісів. Блокчейн-зберігання метаданих гарантує незмінність і захист від підробок.
Згідно з документацією IPFS, content-addressing гарантує, що дані залишаються посилально-цілісними навіть при зміні сховища.
Чому IPFS — правильний вибір для метаданих NFT?
Кожен NFT — це токен з URI, що вказує на JSON-файл метаданих. Якщо URI веде на централізований сервер, ви довіряєте його адміністратору. IPFS перетворює URI на ipfs://QmXxx... — адресу, яка прив'язана до вмісту. Поки існує хоча б одна копія файлу в мережі, метадані доступні. Для додаткової надійності ми використовуємо пінінг: фіксуємо дані на власних нодах та в хмарних сервісах. Економія на помилках може сягати до 30% витрат на перевипуск метаданих.
Структура метаданих і пінінг
Що і як завантажуємо
Стандартний набір для NFT-колекції:
-
images/— PNG/WebP файли токенів, рекомендована роздільна здатність не менше 1000×1000 px -
metadata/— JSON файли, по одному на кожен токен - Опціонально: анімації (MP4/WebM), 3D моделі (GLB)
Завантаження йде у два етапи. Спочатку завантажуємо папку з зображеннями — отримуємо CID кореневої папки. Потім генеруємо JSON-файли, де в полі image стоїть ipfs://<CID_зображень>/<id>.png. Завантажуємо папку з JSON-файлами — отримуємо фінальний CID метаданих. Цей CID використовується як baseURI в контракті.
Як забезпечити довготривалу доступність метаданих?
IPFS за замовчуванням видаляє файли через збір сміття, якщо на них немає активного пінінгу. Без пінінгу файли існують лише поки хтось їх запитує. Для NFT це неприйнятно. Пінінг фіксує дані на виділених нодах, гарантуючи доступність при будь-яких сценаріях. Ми використовуємо комбінацію сервісів для максимальної надійності.
Порівняння сервісів пінінгу
| Сервіс | Тип зберігання | Переваги | Обмеження |
|---|---|---|---|
| Pinata | Хмарний пінінг | Простий API, виділені шлюзи, підтримка Arweave | Платна підписка, обмеження по трафіку |
| NFT.Storage | Filecoin + IPFS | Безкоштовно для NFT, довгострокове зберігання через Filecoin deals | Менше гнучкості в API, повільне завантаження |
| Web3.Storage | Filecoin + HTTP | Альтернатива з HTTP шлюзом, redundancy на Filecoin | Обмежений функціонал для великих колекцій |
| Arweave | Перманентне зберігання | Одноразова оплата, дані назавжди | Висока початкова вартість, неможливість видалити дані |
Рекомендуємо double-pin: Pinata для активного управління та Arweave для вічного резерву. Pinata в 3 рази швидше завантажує файли (близько 50 МБ/с), а Arweave (близько 10 МБ/с) зберігає дані назавжди за один платіж — це поєднання забезпечує доступність при будь-яких сценаріях.
Порівняння: хмарний пінінг vs перманентне зберігання
| Pinata (хмарний) | Arweave (перманентне) | |
|---|---|---|
| Оплата | Щомісячна підписка | Одноразова комісія (≈0.0001 AR/байт) |
| Довговічність | Поки оплачуєте підписку | Назавжди (перевірено консенсусом) |
| Швидкість завантаження | Висока (≈50 МБ/с) | Середня (≈10 МБ/с) |
| Зміна даних | Так (перезапис) | Ні (append-only) |
Практичне налаштування скрипта завантаження
Скрипт завантаження через Pinata API (Node.js) — це налаштування Pinata, яке виконується за 1 день:
import { PinataSDK } from "pinata"; const pinata = new PinataSDK({ pinataJwt: process.env.PINATA_JWT }); // Upload images folder const imagesUpload = await pinata.upload.folder("./images"); const imagesCID = imagesUpload.IpfsHash; // Generate and upload metadata const metadata = tokens.map((id) => ({ name: `Collection #${id}`, image: `ipfs://${imagesCID}/${id}.png`, attributes: traits[id] })); const metaUpload = await pinata.upload.folder(metadata, { name: "metadata" }); CID з metaUpload.IpfsHash — це те, що йде в baseURI контракту. Після завантаження обов'язково перевіряємо доступність через публічні IPFS-шлюзи: cloudflare-ipfs.com, ipfs.io. Важливо: не хардкодити в контракті конкретний шлюз — тільки ipfs://CID/. Маркетплейси (OpenSea, Blur) самі резолвлять IPFS URI через свої шлюзи.
Покрокова інструкція з перевірки
- Відкрийте
https://cloudflare-ipfs.com/ipfs/<CID>в браузері. - Замініть шлюз на
ipfs.io— результат повинен бути однаковим. - Перевірте маркетплейс: вставте CID як
ipfs://<CID>в поле baseURI тестового контракту. - Дочекайтеся оновлення метаданих (зазвичай до 5 хвилин).
Орієнтири за термінами
Налаштування пінінгу та завантаження метаданих для готової колекції — від 1 робочого дня. Включає: upload зображень, генерацію JSON, пінінг на Pinata + резервний Arweave, перевірку доступності через шлюзи, передачу CID для контракту. Вартість розраховується індивідуально — оцініть ваш проект безкоштовно, пишіть нам. Економія до 30% при використанні IPFS замість централізованих серверів.
Що входить в роботу
- Підготовка зображень та метаданих до завантаження (оптимізація, перевірка форматів)
- Завантаження на IPFS з пінінгом через Pinata та Arweave
- Генерація та перевірка tokenURI IPFS
- Тестування доступності через основні шлюзи та маркетплейси
- Надання CID та документації для розгортання контракту
- Гарантія доступності метаданих на весь період проекту
Ми — команда з семирічним досвідом у блокчейн-розробці, реалізували понад 30 NFT-проектів на Ethereum, Polygon та Base. Наші інженери сертифіковані з Solidity та володіють стеком Foundry, Hardhat, Tenderly. Пропонуємо налаштування під ключ за 1 день. Оцінимо ваш проект безкоштовно — пишіть нам для консультації з налаштування зберігання метаданих, підберемо оптимальне рішення під вашу колекцію.