Разработка NFT-коллекции

Разработка NFT-коллекции

Контракт NFT-коллекции на первый взгляд прост — OpenZeppelin ERC-721 с mint() функцией. На практике большинство проблем возникает не в самом контракте, а в связке метаданных, хранения, механики минтинга и деплоя. Коллекция, где метаданные хранятся на централизованном сервере (HTTP URL в tokenURI), уязвима к «rug pull» в части NFT — владелец сервера может изменить изображения в любой момент. Это не гипотетика: несколько коллекций в 2022-2023 годах заменили artwork после продажи.

Выбор стандарта и механики минтинга

ERC-721 vs ERC-1155

ERC-721 — один токен, один owner. Подходит для PFP-коллекций и уникального арта. ERC-1155 — один контракт, несколько типов токенов, возможен fungible и semi-fungible. Правильный выбор для игровых предметов, где одинаковые items могут быть у тысяч игроков.

Для стандартной PFP-коллекции (10 000 уникальных токенов) — ERC-721A (Azuki) вместо стандартного ERC-721. ERC-721A оптимизирует batch mint: mint 10 токенов за одну транзакцию стоит почти столько же газа, сколько mint одного в стандартном ERC-721. Экономия для пользователя — 50-80% на газе при mint нескольких токенов.

Механики минтинга

Whitelist / allowlist — адреса из списка минтят раньше публики. Реализация через Merkle Tree (не через маппинг): корень дерева хранится в контракте (32 байта), пользователь предоставляет Merkle proof при минтинге. Экономия газа на деплой и хранение — колоссальная по сравнению с mapping(address => bool) на тысячи адресов.

Signature-based allowlist — альтернатива Merkle Tree. Backend подписывает разрешение конкретному адресу через ECDSA (EIP-712), пользователь предоставляет подпись при минтинге. Удобнее для динамических allowlist (можно добавлять адреса без обновления Merkle root), но требует backend инфраструктуру.

Dutch Auction — цена начинается высокой и снижается каждые N минут до floor price. Позволяет рынку самому найти равновесную цену, снижает газ войны в момент старта. Сложнее в реализации — нужен корректный расчёт цены on-chain без оффчейн данных.

Метаданные и хранение

tokenURI должен возвращать JSON с полями name, description, image, attributes. Критичный вопрос — где хранится этот JSON и сами изображения.

IPFS + Pinata/NFT.Storage — децентрализованное хранение, контент-адресуемые ссылки (ipfs://Qm...). Если пиннинг прекращается — файл теоретически недоступен, но может быть восстановлен любым IPFS-нодой, у которого есть копия. Стандарт для большинства коллекций.

Arweave — permanent storage, одноразовая оплата за вечное хранение. Более надёжно чем IPFS с точки зрения persistence. Используется для ценных коллекций и PFP.

On-chain SVG — изображения генерируются прямо в контракте как SVG строки. Полностью децентрализовано, невозможно изменить. Дорого по газу на деплой (если trait-данные хранятся on-chain), но для простых геометрических arт-проектов — идеально.

Reveal механика: при деплое все tokenURI указывают на placeholder. После минта — reveal, контракт обновляет baseURI на финальный IPFS путь. Randomness для генерации traits берём из Chainlink VRF (верифицируемо случайный) или из blockhash (манипулируемо, но дёшево для non-high-value коллекций).

Стек и процесс

Контракт — Solidity 0.8.x, ERC-721A или OpenZeppelin ERC-721. Тесты в Foundry: coverage >90%, тест на газ batch mint, тест Merkle proof verification.

Метаданные генерируем скриптом перед деплоем: берём trait layers, генерируем combinatorics, проверяем rarity distribution, загружаем на IPFS через Pinata API. Финальный IPFS CID фиксируем до деплоя.

Ориентиры по срокам

Базовая коллекция (ERC-721, whitelist через Merkle, public mint, IPFS метаданные) — 1-1.5 недели включая тесты и деплой. С Dutch auction, кастомной reveal механикой, Chainlink VRF — 2 недели. Стоимость зависит от сложности mint механики и объёма работ по метаданным.