Проектування архітектури NFT-проекту

Проектування архітектури NFT-проекту

Більшість проблем NFT-проектів виникають не в момент розробки, а при масштабуванні або виході на маркетплейси. Колекція задеплоена, продана, а потім виясняється: метадані зберігаються на централізованому сервері та при його падінні трейдери бачать порожні картинки; роялті не працюють на Blur та LooksRare; контракт не підтримує batch операції та газ на transfer коштує $5 при навантаженій мережі. Архітектурний етап — це про то, щоб такі сюрпризи не сталися через 6 місяців.

Вибір токен-стандарту

ERC-721 vs ERC-1155 vs ERC-721A

ERC-721 — стандарт для унікальних NFT. Кожен tokenId унікальний, кожен має свого owner. Широко підтримується маркетплейсами. Слаба сторона: _mint у цикліі — кожен mint це окрема запис в _owners маппінг, кожна запис = SSTORE = ~20k gas. Mint 100 NFT в одній транзакції = 2M gas.

ERC-721A (Azuki) вирішує саме це: batch mint записує мінімум даних — тільки запис для першого tokenId в batch, решта обчислюються on-demand через ownerOf. Економія при batch mint — 60-80% gas. Компроміс: ownerOf та transferFrom коштують дорожче ніж в ERC-721 через додаткові обчислення. Для проектів, де після mint активно торгують — зважте.

ERC-1155 — мультитокен: один контракт містить кілька ID, кожен ID може мати кілька копій (fungible або semi-fungible). Ідеально для: edition NFT (1000 однакових), gaming items (1000 мечей одного типу), сертифікати. Маркетплейси підтримують ERC-1155, але UX іноді гірше ніж у ERC-721 (не всі агрегатори показують edition коректно).

Апгрейдаємість: потрібна ли вона

Для більшості NFT-колекцій — ні. Immutable контракт викликає більше довіри у колекціонерів. Proxy додає attack surface: storage collision при апгрейді може пошкодити _owners маппінг — та всі токени стають «ніч'їми».

Коли апгрейдаємість виправдана: gaming NFT з evolving механіками, протокольні NFT в рамках DeFi системи. У цьому випадку — UUPS з timelock: будь-який апгрейд має затримку 48-72 години, спільнота може відреагувати.

Зберігання метаданих

IPFS та проблема pinning

IPFS — децентралізоване сховище, але файл існує тільки поки хтось його «пінує». Якщо пінер відключится — ipfs://QmXxxx... стане недоступним. Рішення: платний pinning сервіс (Pinata, NFT.Storage, Filebase) + кілька пінерів.

NFT.Storage (Filecoin) зберігає дані перманентно через Filecoin deals — це ближче до справжньої децентралізації, ніж просто IPFS pinning.

Arweave — pay-once-store-forever. Один платіж при завантаженні, дані зберігаються перманентно (~200 років за розрахунками протоколу). Використовується Metaplex (Solana NFT стандарт) та багатьма серйозними ETH проектами. Для 10 000 NFT зображень Arweave коштує $200-500 — дешевше ніж постійний pinning сервіс за кілька років.

On-chain метадані

Для повністю on-chain NFT (generative art, fully on-chain games) метадані та зображення зберігаються в контракті. tokenURI повертає base64-encoded JSON з base64-encoded SVG всередині. Дорого при деплої, але абсолютно перманентно. Приклад: Loot Project, Nouns DAO.

Структура:

data:application/json;base64,{base64({"name":"...", "image":"data:image/svg+xml;base64,{base64(svg)}"})}

Royalty механіки

EIP-2981 як базовий стандарт

royaltyInfo(uint256 tokenId, uint256 salePrice) повертає (receiver, royaltyAmount). Підтримується OpenSea, Rarible, Foundation. Не enforced — advisory. Реалізується через ERC2981 з OpenZeppelin:

_setDefaultRoyalty(treasury, 500); // 5% = 500 basis points

Або per-token royalty для колабораціях: різні royalty на різні tokenId.

Operator Filter

Для проектів, які бажають enforced royalty: наслідування від OperatorFilterer, реєстрація в OpenSea Operator Filter Registry. Блокує transfer через non-compliant маркетплейси. Вимагає зважиного рішення — обмежує transferability, викликає спори в спільноті.

Mint механіки в архітектурі

Dutch Auction — для проектів з високим попитом. Знижує газ-войни (немає сенсу перебивати ціну), справедливий price discovery. Refund механізм для різниці між сплаченою та фінальною ціною.

Whitelist + Public фази — стандарт. Merkle proof для WL (описано в окремій послузі), Public з rate limiting (max N per wallet per tx).

Lazy mint — NFT існує off-chain, створюється on-chain тільки при першій покупці. Collector платить mint gas. Використовується Zora, Foundation. Знижує ризик creator — не платиш за деплой 10 000 токенів, які можуть не продатися.

Процес архітектурного проектування

Аналітика (1-2 дні). Тип проекту (PFP / gaming / art / membership), цільові маркетплейси, вимоги до royalty, планований utility (staking, governance, доступ до контенту).

Архітектурний документ (1-2 дні). Вибір стандарту з обґрунтуванням, схема зберігання метаданих, mint механіка, royalty підхід, roadmap апгрейдів якщо потрібні.

Технічний аудит архітектури. Перевіряємо сумісність з цільовими маркетплейсами (OpenSea, Blur, LooksRare), потенційні газ-проблеми, attack surface.

Deliverable. Markdown-документ з архітектурними рішеннями, ER-діаграма контрактів, storage layout, список ризиків. На основі документу — розробка.

Орієнтири за часом

Архітектурне проектування NFT-проекту — 3-5 днів. Включає документ з рішеннями, схемами, ревью ризиків.

Вартість розраховується після первинного брифінгу про проект.