Розробка NFT-маркетплейсу: смарт-контракти, фронтенд, деплой

Чому розробка NFT-маркетплейсу ламається на старті

Розробка NFT-маркетплейсу ламається не на вітрині, а на стику смарт-контрактів маркетплейсу та реального стану мережі. Комісії мережі плавають: транзакція, яка пройшла на тестовому стенді, у живій мережі висить у мемпулі годинами, а користувач бачить «підтверджується» і йде.

Якщо контракт не закладає запас на оплату газу і не вміє перевідправляти завислі транзакції, кожна така заявка перетворюється на ручний розбір і втрачений лот.

Друга міна — реорганізації блокчейну. Подія Transfer вже оброблена, баланс у базі оновлено, а ланцюг відкотився на пару блоків назад.

Без підтверджень потрібної глибини і без ідемпотентної обробки подій маркетплейс починає показувати власників, яких немає, і приймати ставки на вже продані токени.

Індексація блокчейну тут не «фонова задача», а ядро: якщо індексатор відстає або падає на наздоганянні історії, фронт тихо віддає застарілі дані, і це виглядає як баг продукту, хоча проблема в конвеєрі.

Третій клас відмов — комісії та розрахунки всередині самого маркетплейсу. Роялті, комісія платформи, спліт між автором і продавцем: якщо логіка розмазана між контрактом і бекендом, при першій же зміні схеми виплат частина грошей застрягає.

Ми виносимо розрахунки в контракт з явними правилами і покриваємо їх перевірками до деплою, а не після інциденту.

Розбираємо, як це закривається: глибина підтверджень і повторна відправка транзакцій, відмовостійкий індексатор з наздоганянням історії, детерміновані розрахунки комісій і зрозумілий відкат при збої.

Що дає правильно спроєктований торговий майданчик

Правильно спроєктований майданчик відрізняється від «працюючого демо» тим, що його поведінка передбачувана на піках.

Ключові метрики тут інженерні: час від подання заявки до підтвердження угоди, частка транзакцій, що відкочуються на етапі підпису або мінту, і те, як система поводиться, коли одночасно приходять сотні покупців на один дроп.

Швидкість підтвердження угоди визначається не лише пропускною здатністю мережі, а й тим, як побудований шлях користувача до неї.

Якщо підпис, перевірка прав і запис до реєстру рознесені по різних кроках із ручними підтвердженнями, кожна зайва ітерація додає секунди очікування й провокує відмову.

Ми зводимо шлях до мінімуму: підготовка даних і перевірки йдуть до звернення до мережі, а сама транзакція надсилається один раз із уже розрахованими параметрами.

Вартість операцій у мережі — керована величина, а не даність. Батчинг мінтів, винесення важких обчислень за межі ланцюжка, акуратна робота зі сховищем метаданих — усе це знижує витрати на дію й прибирає ситуації, коли комісія з'їдає маржу на вторинних продажах.

Окремо проєктуємо клас відмов: що відбувається, якщо транзакція не пройшла, зависла в мемпулі або мережа перевантажена. Користувач має бачити зрозумілий статус і можливість повторити дію, а не втрачати актив.

Стійкість до навантаження закладається на рівні архітектури: черга на запис, кеш метаданих і зображень, окремий контур для читання каталогу. Тоді пік на дроп не роняє вітрину, а розтягується в часі.

Саме цей шар відрізняє майданчик, який переживає реліз, від того, що ламається на першому сплеску. Ми проєктуємо й супроводжуємо такі системи на Ethereum і сумісних мережах, де ціна помилки в контракті максимальна.

Варіанти архітектури: on-chain, гібрид, off-chain

Вибір архітектури визначає не лише вартість транзакцій, а й те, як маркетплейс переживе зростання навантаження. На практиці чистих схем дві з половиною: повністю on-chain, повністю off-chain і гібрид, де критичне живе в блокчейні, а важке — поза ним.

Нижче — порівняння за трьома осями: де зберігаються дані, хто платить за газ і що відбувається при десятикратному зростанні обсягу.

Гібридна схема виграє за сукупністю: мінт і передача прав фіксуються в контракті, а медіа та рідко змінювані атрибути лежать поза мережею, і газові витрати не зростають разом із розміром колекції.

Ключова умова — хеш метаданих записаний у токені: тоді підміна файлу на боці сховища виявляється, а перевірка залишається публічною.

Off-chain зберігання дає кращу пропускну здатність, але потребує власного шару довіри: підписані оператором події, регулярна звірка стану бази з мережею та зрозумілий регламент відкату.

Без цього масштабування перетворюється на накопичення розходжень, які спливають на першій же спірній угоді.

Як ми ведемо розробку NFT-маркетплейсу: етапи

Розробка NFT-маркетплейсу — це не «написати контракт і прикрутити вітрину». Тут три незалежні шари: смарт-контракти, які тримають активи та комісії, індексер, який збирає події мережі в зручні для інтерфейсу дані, і фронтенд з гаманцевою авторизацією.

Помилка в будь-якому з них коштує дорожче, ніж у звичайному веб-застосунку: контракт після публікації не відкотиш, а розбіжність між станом мережі та тим, що бачить користувач, ламає довіру до майданчика. Тому процес будуємо так, щоб кожне рішення перевірялося до того, як стане незворотним.

Як влаштований процес

1. Аудит вимог. Розбираємо модель торгівлі: фіксована ціна, аукціон, частки роялті, вторинні продажі. Фіксуємо, які дії платні, хто платить комісію і що відбувається при скасуванні лоту. На виході — узгоджена схема ролей і сценаріїв, а не список побажань.
2. Проєктування контрактів. Розділяємо логіку: окремо стандарт токена, окремо маркетплейс, окремо виплати. Продумуємо оновлюваність і права адміністратора, щоб не зашивати майданчик у незмінний код без виходу.
3. Розробка та локальна перевірка. Контракти збираємо і проганяємо на локальній мережі з реальними сценаріями: мінт, виставлення, купівля, скасування, виведення коштів. Паралельно піднімаємо індексер і API.
4. Тестування. Юніт-тести на кожну функцію контракту, сценарії на граничні суми та повторні виклики, перевірка прав доступу. Окремо — тести фронтенду на підключення гаманця і підпис транзакцій.
5. Аудит перед публікацією. Незалежна перевірка контрактів і розбір знайдених зауважень до деплою, а не після.
6. Деплой і запуск. Публікація в основній мережі, налаштування індексера, моніторинг подій і алерти на аномальні операції.
7. Передача документації. Схеми контрактів, опис ролей і прав, інструкції з оновлення та розбір інцидентів.

Кожен етап закінчується артефактом, який можна перевірити: специфікація, схема, звіт тестів, чек-ліст аудиту. Це дозволяє повернутися на крок назад без переписування всього проєкту.

Що замовник отримує на руки після здачі проєкту

Здача проєкту — це не «доступ до репозиторію та прощальний дзвінок».

Ми передаємо комплект, за яким ваша команда або інший підрядник зможе розвивати маркетплейс без нас: контракти розгортаються з вихідних кодів, права та ролі описані, інциденти розбираються за регламентом, а не по пам'яті.

• Вихідний код смарт-контрактів — контракти випуску токенів, торгів, роялті та аукціонів, з тестами та скриптами розгортання. Будь-який аудитор відтворює збірку та перевіряє логіку без доступу до наших внутрішніх напрацювань.
• Схеми взаємодії — як фронтенд спілкується з контрактами, гаманцями та індексером: потоки даних, точки відмови, поведінка при відхиленій транзакції. За ними новий інженер входить у проєкт за дні, а не тижні.
• Політики доступу — ролі адміністратора, модератора колекцій, оператора виплат; що кожна може та які дії потребують підтвердження другої особи. Права видаються за принципом мінімальної необхідності.
• Регламенти обслуговування — порядок оновлення контрактів, план відкату до попередньої версії, реакція на завислі транзакції та зростання вартості операцій у мережі.
• Документація та інструкції — опис архітектури, змінні середовища, порядок локального запуску, чек-ліст релізу та приймання.
• Доступи та передача інфраструктури — репозиторії, середовища, ключі розгортання та моніторинг переводяться на ваші акаунти з ротацією секретів.
• Журнал відомих обмежень — чесний список того, що свідомо не увійшло в обсяг і які місця варто посилити при зростанні навантаження.

Такий комплект знімає головний ризик: маркетплейс перестає залежати від однієї людини, яка «знає, як тут усе влаштовано». Опишіть задачу — повернемося з оцінкою та планом передачі.

Кейс: маркетплейс з оборотом 40 000 угод на місяць

Замовник прийшов із готовим продуктом на OpenSea-подібній моделі: вітрина, гаманці, мінт і торги працювали, але на піку навантаження площадка «сипалася».

Індексатор не встигав за блокчейном, вітрина віддавала застарілі дані про власників, а користувач дізнавався про успішну покупку через хвилини. Частка невдалих транзакцій сягала 18% — люди платили комісію мережі за відхилений мінт і йшли.

Що змінили

Ми переписали контракти так, щоб перевірки прав і лімітів виконувалися до відправки транзакції, а не в момент виконання — це прибрало основну масу відмов.

Індексатор перевели на чергу з ідемпотентною обробкою подій: повторна доставка блоку більше не створює дублів у базі, а вітрина читає стан із кешу, який оновлюється в міру підтвердження блоків.

Фронтенд отримав оптимістичний відгук: інтерфейс показує результат одразу, а фон дораховує фінальний стан. Якщо транзакція все ж відхиляється, користувач бачить причину людською мовою, а не код помилки.

Метрики до і після

Зростання обороту втричі площадка витримала без розширення команди підтримки: інциденти з розсинхроном даних зникли, а навантаження на індексатор перестало бути вузьким місцем. Окремо залишили метрики в моніторингу — за ними видно деградацію до того, як її помітять користувачі.

Чим відрізняється смарт-контракт маркетплейсу від звичайного токена

Токен ERC-20 або ERC-721 — це, по суті, реєстр володіння: хто чим володіє і як актив передається. Смарт-контракт маркетплейсу вирішує інше завдання — він керує угодою між двома сторонами, які не довіряють одна одній, і утримує актив до виконання умов.

Тому його логіка на порядок складніша: тут з'являються стани лота, ескроу, розподіл комісій і розмежування ролей.

Логіка торгів — це скінченний автомат, а не одна функція. Лот проходить стани: виставлено, є ставка, аукціон закрито, угоду виконано або скасовано.

Контракт зобов'язаний коректно обробляти кожен перехід: продовження аукціону при ставці в останні хвилини, скасування за відсутності покупців, відхилення ставок нижче резерву. Помилка в одному переході — і лот зависає, а актив блокується.

Ескроу — ключова відмінність від токена. Покупець не надсилає кошти продавцю напряму: контракт утримує і актив, і оплату, а обмін відбувається атомарно — або обидві сторони отримують своє, або ніхто. Це прибирає довіру з рівняння: жодна сторона не може забрати чуже, навіть якщо друга зникне.

Комісії та ролі доступу — те, чого у звичайного токена немає взагалі. Контракт розподіляє плату платформи та роялті автора при кожному перепродажі, а ролі розділені: власник задає параметри, оператор керує лотами, казначейство виводить кошти.

Розділення прав не дає одному обліковому запису змінювати все одразу — це обмежує збитки при компрометації ключа.

Саме тому аудит маркетплейсу завжди дорожчий і довший, ніж перевірка токена: перевіряти потрібно не зберігання балансів, а економіку угоди та всі гілки переходів станів.

Часті технічні сумніви перед стартом

Перед стартом розробки NFT-маркетплейсу замовники найчастіше ставлять одні й ті самі запитання — і це правильні запитання. Нижче — короткі відповіді щодо кожного з технічних ризиків, які ми закриваємо на етапі проєктування, а не після запуску.

З якими мережами маркетплейс буде сумісний?

Архітектуру будуємо так, щоб основна мережа була одна, а підключення другої не вимагало переписування логіки. Контракти та індексація подій ізольовані за шарами, тому додавання мережі — це конфігурація та окремий деплой, а не новий проєкт. Сумісність гаманців і стандартів токенів перевіряємо до старту розробки.

Що буде при міграції або оновленні контрактів?

Використовуємо проксі-патерн: логіку можна оновлювати, зберігаючи адресу контракту та всі дані — колекції, історію угод, баланси. Міграція проходить за заздалегідь прописаним регламентом з перевіркою на тестовій мережі та планом відкату. Користувачі не втрачають доступ до активів, а маркетплейс не йде на простій.

Як влаштована підтримка після запуску?

Після релізу залишаємося на зв'язку: моніторинг транзакцій і помилок, реакція на інциденти, оновлення контрактів і фронтенду. Окремо ведемо журнал змін і тримаємо резервні копії конфігурацій. Підтримка — це не «полагодити, коли впало», а планові перевірки та оновлення за регламентом.

Опишіть задачу — повернемося з оцінкою, планом робіт і схемою архітектури під ваш сценарій.

Обговоримо ваше завдання і повернемося з планом

Щоб розмова була предметною, а не «розкажіть про NFT», опишіть завдання в термінах вашого бізнесу: які активи токенізуєте, хто ваші автори та покупці, чи потрібен первинний випуск колекцій або вторинний ринок із роялті, чи плануєте власний гаманець або вхід через зовнішні. Цього достатньо, щоб запропонувати архітектуру маркетплейсу, а не типовий шаблон.

Далі ми повертаємося з планом робіт: розбивкою на етапи впровадження, схемою взаємодії блокчейну, бекенду та фронтенду, варіантами зберігання метаданих і медіа, моделлю прав і комісій.

Оцінку даємо за етапами, щоб ви могли запускати частинами — спочатку ядро торгів, потім аукціони, дропи та аналітику.

Що увійде в першу відповідь на ваше завдання:

• розбір сценаріїв: мінт, лістинг, купівля, аукціон, роялті, скасування угоди;
• пропозиція щодо архітектури: смарт-контракти, індексер подій, API, фронтенд;
• вибір мережі та стандарту токенів під ваші вимоги до комісій і швидкості;
• схема кастодіального та некастодіального зберігання ключів користувача;
• план етапів впровадження з точками приймання на кожному;
• перелік ризиків: газ, реорганізації мережі, скам-колекції, навантаження на дропах;
• попередня оцінка термінів і складу команди під ваш обсяг.

Опишіть завдання у вільній формі — що за маркетплейс, для кого, які активи та який очікуваний потік угод. Ми повернемося з оцінкою та планом, а не із загальними обіцянками.