Проектирование архитектуры NFT-проекта
Большинство проблем NFT-проектов возникают не в момент разработки, а при масштабировании или выходе на маркетплейсы. Коллекция задеплоена, продана, а потом выясняется: метаданные хранятся на централизованном сервере и при его падении трейдеры видят пустые картинки; роялти не работают на Blur и LooksRare; контракт не поддерживает batch operations и газ на transfer $5 при загруженной сети. Архитектурный этап — это про то, чтобы такие сюрпризы не случились через 6 месяцев.
Выбор токен-стандарта
ERC-721 vs ERC-1155 vs ERC-721A
ERC-721 — стандарт для уникальных NFT. Каждый tokenId уникален, каждый имеет своего owner. Широко поддерживается маркетплейсами. Слабое место: _mint в loop — каждый mint это отдельная запись в _owners mapping, каждая запись = SSTORE = ~20k gas. Mint 100 NFT в одной транзакции = 2M gas.
ERC-721A (Azuki) решает именно это: batch mint записывает минимум данных — только запись для первого tokenId в batch, остальные вычисляются on-demand через ownerOf. Экономия при batch mint — 60-80% газа. Компромисс: ownerOf и transferFrom стоят дороже чем в ERC-721 из-за дополнительных вычислений. Для проектов, где после mint активно торгуют — взвесьте.
ERC-1155 — мультитокен: один контракт содержит несколько ID, каждый ID может иметь несколько copies (fungible или semi-fungible). Идеально для: edition NFT (1000 одинаковых), gaming items (1000 мечей одного типа), сертификаты. Маркетплейсы поддерживают ERC-1155, но UX иногда хуже чем у ERC-721 (не все агрегаторы показывают edition корректно).
| Стандарт | Лучше для | Gas на mint | Gas на transfer |
|---|---|---|---|
| ERC-721 | Уникальные PFP | Высокий | Низкий |
| ERC-721A | Batch mint PFP | Очень низкий | Средний |
| ERC-1155 | Edition, gaming | Низкий | Очень низкий |
Апгрейдаемость: нужна ли она
Для большинства NFT-коллекций — нет. Immutable контракт вызывает больше доверия у коллекционеров. Proxy добавляет attack surface: storage collision при апгрейде может corrupt _owners mapping — и все токены станут "ничьими".
Когда апгрейдаемость оправдана: gaming NFT с evolving mechanics, протокольные NFT в рамках DeFi системы. В этом случае — UUPS с timelock: любой апгрейд имеет delay 48-72 часа, community может отреагировать.
Хранение метаданных
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 metadata
Для полностью 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 (стейкинг, governance, доступ к контенту).
Архитектурный документ (1-2 дня). Выбор стандарта с обоснованием, схема хранения метаданных, mint механика, royalty подход, roadmap апгрейдов если нужны.
Технический аудит архитектуры. Проверяем совместимость с целевыми маркетплейсами (OpenSea, Blur, LooksRare), потенциальные газ-проблемы, attack surface.
Deliverable. Markdown-документ с архитектурными решениями, ER-диаграмма контрактов, storage layout, список рисков. На основе документа — разработка.
Ориентиры по срокам
Архитектурное проектирование NFT-проекта — 3-5 дней. Включает документ с решениями, схемы, ревью рисков.
Стоимость рассчитывается после первичного брифинга о проекте.