Централизованное хранение метаданных NFT — риск, который может обесценить коллекцию. Сервер упал, домен умер, провайдер сменил политику — и владельцы токенов видят пустое место вместо изображения. IPFS решает это на протокольном уровне: адрес файла (CID) зависит только от его содержимого. Изменить файл, не изменив CID, невозможно. Это фундаментальное свойство делает IPFS единственным правильным выбором для размещения метаданных NFT. Мы используем IPFS во всех своих проектах и обеспечиваем неизменность данных без компромиссов.
Согласно документации IPFS, content-addressing гарантирует, что данные остаются ссылочно-целостными даже при смене хранилища.
Почему IPFS — правильный выбор для метаданных NFT?
Каждый NFT — это токен с URI, указывающим на JSON-файл метаданных. Если URI ведёт на централизованный сервер, вы доверяете его администратору. IPFS превращает URI в ipfs://QmXxx... — адрес, который привязан к содержимому. Пока существует хотя бы одна копия файла в сети, метаданные доступны. Для дополнительной надёжности мы используем пиннинг: фиксируем данные на собственных нодах и в облачных сервисах.
Структура метаданных и пиннинг
Что и как загружаем
Стандартный набор для 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 раза быстрее загружает файлы, а Arweave хранит данные навсегда за один платёж — это сочетание обеспечивает доступность при любых сценариях.
Сравнение: облачный пиннинг vs перманентное хранение
| Pinata (облачный) | Arweave (перманентное) | |
|---|---|---|
| Оплата | Ежемесячная подписка | Одноразовая комиссия (≈0.0001 AR/байт) |
| Долговечность | Пока оплачиваете подписку | Навсегда (проверено консенсусом) |
| Скорость загрузки | Высокая (≈50 МБ/с) | Средняя (≈10 МБ/с) |
| Изменение данных | Да (перезапись) | Нет (append-only) |
Практическая настройка скрипта загрузки
Скрипт загрузки через Pinata API (Node.js):
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 для контракта. Стоимость рассчитывается индивидуально в зависимости от объёма данных и выбранных сервисов.
Что входит в работу
- Подготовка изображений и метаданных к загрузке (оптимизация, проверка форматов)
- Загрузка на IPFS с пиннингом через Pinata и Arweave
- Генерация и проверка tokenURI
- Тестирование доступности через основные шлюзы и маркетплейсы
- Предоставление CID и документации для развёртывания контракта
- Гарантия доступности метаданных на весь период проекта
Мы — команда с семилетним опытом в блокчейн-разработке, реализовали более 30 NFT-проектов на Ethereum, Polygon и Base. Наши инженеры сертифицированы по Solidity и владеют стеком Foundry, Hardhat, Tenderly. Свяжитесь с нами для консультации по настройке хранения метаданных — подберём оптимальное решение под вашу коллекцию.