Розробка системи антибот-захисту при мінтингу

Розробка системи антибот-захисту при мінтингу

Одна з гучних колекцій втратила 2/3 об'єму за перші хвилини — боти змінтили майже все, поки реальні користувачі не встигли натиснути "Mint". Наша команда вирішує цю проблему, впроваджуючи багаторівневий захист, який пройшов перевірку на 20+ NFT-проєктах. За рахунок комбінації Merkle whitelist, per-address лімітів та часових batch-обмежень ми знижуємо частку ботів до 5% і економимо користувачам до 30% газу (економія до $0.50 на транзакцію). Інвестиція в $500 окупається, запобігаючи втратам до $10 000. Ми враховуємо газ-ефективність, опір до реентрансі та сибіл-атак. Нижче — реальні механізми, які ми використовуємо, щоб ваш мінтинг залишався справедливим. Вартість базової системи починається від $500, повна багатофазна — від $1500.

Основні механізми захисту

Merkle whitelist: найпоширеніший захист

Merkle tree з адрес whitelist. Кожна адреса з листа може довести своє членство, надавши proof з O(log n) хешів. Контракт зберігає лише один root (32 байти), не весь список. Ми використовуємо бібліотеку OpenZeppelin (див. документацію MerkleProof). За нашими даними, Merkle whitelist знижує частку ботів у 10 разів порівняно з простим per-address лімітом.

bytes32 public merkleRoot;

function whitelistMint(uint256 quantity, bytes32[] calldata proof) external payable {
    bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
    require(MerkleProof.verify(proof, merkleRoot, leaf), "Not whitelisted");
    require(!_whitelistClaimed[msg.sender], "Already claimed");
    _whitelistClaimed[msg.sender] = true;
    _mint(msg.sender, quantity);
}

Генерація Merkle tree — off-chain TypeScript скрипт через merkletreejs. Root оновлюється перед мінтом через setMerkleRoot() (onlyOwner). Proofs користувачі отримують через API або заздалегідь публікуються в IPFS.

Уразливість: якщо frontend скомпрометований, атакуючий може запросити proof для будь-якої адреси з листа через API. Захист: proof видається тільки wallet, який його запитує (signature-gated API), або публікується весь список заздалегідь (повна відкритість).

Commit-reveal: захист від frontrunning при random mint

Без commit-reveal: бот аналізує mempool, бачить транзакцію з параметрами, робить точну копію з вищим gas — frontrunning. З commit-reveal: користувач спочатку публікує keccak256(secret + address), потім через N блоків розкриває secret. За ці N блоків копіювати безглуздо — невідомий secret. Колізійна стійкість хеш-функції Keccak256 гарантує неможливість підробки proof.

Двоетапний процес незручний для користувачів. Використовуємо тільки там, де random distribution критична і користувачі готові до двох транзакцій.

Per-address ліміти: необхідний мінімум

Найбазовіший захист — ліміт на адресу:

mapping(address => uint256) public mintedByAddress;
uint256 public constant MAX_PER_ADDRESS = 3;

function mint(uint256 quantity) external {
    require(mintedByAddress[msg.sender] + quantity <= MAX_PER_ADDRESS, "Limit exceeded");
    mintedByAddress[msg.sender] += quantity;
    _mint(msg.sender, quantity);
}

Не захищає від Sybil — один бот створює тисячі адрес. Але підвищує вартість атаки: потрібно більше гаманців, gas на переміщення ETH між ними. У комбінації з іншими методами — ефективно.

Чому proof-of-work рідко застосовується?

Ідея: перед мінтом потрібно вирішити обчислювальну задачу — знайти nonce такий, що keccak256(address + nonce) < difficulty. Це CPU/GPU робота, яку бот робить швидше, але вона створює resource constraint.

uint256 public mintDifficulty = type(uint256).max / 1000; // 0.1% хешів проходять

function mint(uint256 nonce) external {
    bytes32 hash = keccak256(abi.encodePacked(msg.sender, nonce, block.number / 100));
    require(uint256(hash) < mintDifficulty, "Invalid proof of work");
    _mint(msg.sender, 1);
}

block.number / 100 — вікно в ~100 блоків (~20 хвилин). Nonce валідний тільки в цьому вікні, не можна обчислити заздалегідь. Складність налаштовується через mintDifficulty.

Проблема: мобільні користувачі витрачають 10-30 секунд на обчислення. Боти з GPU — 0.1 секунди. Асиметрія не на користь звичайних користувачів. Proof-of-work ефективний лише в поєднанні з whitelist, де боти спочатку не в листі.

Час очікування та batch limits

Додаткова механіка проти ботів: максимальний mint в перші N блоків від початку — 1 токен. Після N блоків — до MAX_PER_ADDRESS. Бот, який б'є в першу секунду, отримує лише 1 токен. Користувачі, що прийшли через хвилину, можуть взяти більше.

uint256 public publicMintStartBlock;

function maxMintForBlock(uint256 _block) public view returns (uint256) {
    if (_block < publicMintStartBlock + 50) return 1;  // перші ~10 хв
    return MAX_PER_ADDRESS;
}

Порівняння механізмів

Per-address ліміт у 5 разів дешевший за Merkle whitelist, але в 10 разів менш ефективний. Merkle whitelist у 2 рази ефективніший за proof-of-work, але вимагає більше підготовки.

Вибір комбінації для своєї колекції

Маленька колекція (<1000), закрита спільнота: Merkle whitelist + per-address limit 2-3.

Середня колекція (1000-10000), відкритий mint: Whitelist фаза (Merkle) → public фаза з batch limit по часу + per-address limit.

Велика колекція (>10000), високий попит: Whitelist фаза + public фаза з proof-of-work або раффл через VRF.

Який механізм найкращий для вашої колекції?

Найкращий — це комбінація, що відповідає вашим цілям: закритий sale з whitelist, відкритий з часовими обмеженнями. Для максимального захисту додайте commit-reveal, але враховуйте UX.

Покрокова інструкція впровадження

1. Визначте механізми: whitelist, ліміти, час.
2. Розробіть смарт-контракт з цими механізмами (Solidity, Foundry).
3. Згенеруйте Merkle tree для whitelist (TypeScript, merkletreejs).
4. Розгорніть контракт та налаштуйте API для выдачі proof.
5. Затестуйте та проведіть аудит (fuzz, формальна верифікація).
6. Запустіть мінтинг з моніторингом.

Процес розробки

Що входить у роботу

• Смарт-контракт з обраними механізмами (Solidity, Foundry)
• Off-chain скрипт генерації Merkle tree (TypeScript)
• API для видачі proofs (Node.js)
• Документація для інтеграції
• Консультація з налаштування frontend (wagmi, RainbowKit)
• Технічна підтримка на етапі запуску

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

Система з Merkle whitelist + per-address limit — від 1 до 2 днів. Повна багатофазна система з proof-of-work та commit-reveal — від 3 до 5 днів.

Наша команда має 5 років досвіду в Web3 та 20+ запущених NFT-колекцій. Зв'яжіться з нами для оцінки вашого проєкту. Замовте розробку системи антибот-захисту — отримайте консультацію та точний кошторис. Кожен смарт-контракт проходить аудит безпеки.

Чому розробка NFT маркетплейсів потребує комплексного підходу?

Ми бачимо, що на перший погляд NFT-контракт виглядає просто: ERC-721, mint(), IPFS для метаданих, і все. На практиці саме в цій «простоті» ховається більшість проблем — від ботів, які скуповують весь mint у першому блоці, до зламаних роялті на вторинному ринку. Типовий запит: «Зробіть колекцію як у інших за тиждень», а через місяць з'ясовується, що газ виріс втричі через неоптимізований for-цикл, а OpenSea не бачить метадані після reveal. Ми знаємо кожні з цих граблів і будуємо процеси так, щоб їх уникнути.

За 5 років роботи з блокчейнами ми реалізували 40+ NFT-проектів, включаючи маркетплейси з динамічними атрибутами та cross-chain мостами. Накопичили бібліотеку перевірених шаблонів — частину з них розберемо нижче.

Який стандарт вибрати: ERC-721 чи ERC-1155?

ERC-721 — кожен токен унікальний, один owner. Підходить для колекцій, де кожен NFT має індивідуальні атрибути та пряму прив'язку owner → tokenId.
ERC-1155 — multi-token стандарт: один контракт зберігає і fungible, і non-fungible токени. Використовує balanceOf(address, tokenId) замість ownerOf(tokenId). Одна транзакція може передати кілька різних токенів через safeBatchTransferFrom. Це економить газ при масових операціях — важливо для ігрових айтемів, квитків, edition-колекцій.

Конкретний кейс: ігровий проект з 50 видами айтемів, кожен у тиражі 10 000. ERC-721 — 500 000 унікальних токенів, величезний overhead на маппінги. ERC-1155 — 50 tokenId, balanceOf на кожного гравця. Газ на transfer нижче в 2–3 рази, деплой контракту дешевший. Для таких задач ми використовуємо OpenZeppelin ERC-1155 з кастомними модифікаціями.

Метадані: on-chain vs IPFS vs centralized

Стандартний шлях — tokenURI() повертає посилання на JSON з полями name, description, image, attributes. Три варіанти зберігання:

• Centralized server — найдешевший і гнучкий. Ризик: сервер падає, компанія закривається — NFT втрачає метадані. Не підходить для колекцій з претензією на довгострокову цінність.
• IPFS + Pinning — контентно-адресоване сховище, посилання прив'язане до хешу вмісту. Pinata або NFT.Storage забезпечують pіннінг. Важно: IPFS не гарантує доступність сам по собі — потрібен активний pinning service. Якщо він закриється, дані можуть зникнути, якщо ніхто не зберігає копію.
• On-chain metadata — base64-encoded SVG або JSON прямо в tokenURI. Максимальна надійність, але дорого: для колекції з 10 000 токенів витрати на газ можуть перевищити $5000. Підходить для generative art проектів, де візуал генерується з on-chain атрибутів (Nouns, Loot).

Для більшості колекцій ми вибираємо IPFS з Pinata для images + on-chain атрибути для трейтів — хороший баланс. Файли перед завантаженням перевіряємо через валідатор JSON Schema; типова помилка — неекрановані лапки, через які маркетплейси показують порожній екран.

Dynamic NFT: метадані, які змінюються

Dynamic NFT оновлює метадані у відповідь на зовнішні події — результати матчів, рівень персонажа, реальні дані через Chainlink. Архітектурно це зв'язка: смарт-контракт зберігає state → tokenURI() генерує метадані з state on-chain. Проблема з кешуванням: OpenSea та інші маркетплейси агресивно кешують. Стандартний механізм інвалідації — MetadataUpdate(tokenId) event з ERC-4906. OpenSea слухає цей event і скидає кеш. Без нього оновлені метадані можуть не відображатися тижнями.

Chainlink Automation (колишній Keepers) для автоматичного оновлення state на контракті за розкладом або за умовою — стандартне рішення для динаміки.

Як захистити mint від ботів?

Allowlist через merkle tree — стандарт. Список адрес хешується в merkle root, зберігається в контракті. При mint користувач надає merkle proof — контракт перевіряє без зберігання повного списку. Використовуємо OpenZeppelin MerkleProof library.

Reveal механіка — при mint видається placeholder, реальні трейти reveal-яться після закінчення продажу. Інакше боти можуть сканувати pending транзакції і снайперити рідкісні трейти через frontrunning. Але reveal вимагає commitment scheme — випадковий seed має бути зафіксований до mint або використовувати Chainlink VRF.

Chainlink VRF для чесної рандомізації трейтів. VRF request в момент mint → callback з verifiable random number → assign traits. Це додає ~2 транзакції та latency, але гарантує чесність. Посилання на Chainlink VRF v2.5.

Rate limiting — require(mintedPerWallet[msg.sender] < maxPerWallet). Не захищає від мульти-гаманців, але піднімає вартість атаки. Для преміум-проектів часто додаємо proof-of-work прямо в контракт (через EIP-2612 signatures).

Royalties: реальний стан ринку

ERC-2981 — on-chain стандарт роялті. Контракт повертає (recipient, amount) для будь-якої sale price через royaltyInfo(tokenId, salePrice). Маркетплейси опитують це при кожному продажу. Проблема: дотримання роялті — добровільне рішення маркетплейсу. Blur запустився з нульовими роялті, що викликало хвилю інших платформ. Зараз ситуація частково стабілізувалася: OpenSea підтримує ERC-2981, Blur додав опціональні.

Спроби enforce роялті on-chain через обмеження transfers тільки на approved маркетплейси (operator filtering) OpenSea пропонував через OperatorFilterRegistry. Це ламає composability — не можна передати NFT через кастомний контракт. Більшість серйозних проектів відмовилися від цього підходу. Для проектів, де роялті критичні, ми будуємо кастомний маркетплейс всередині екосистеми + incentive structure для користувачів торгувати саме там.

Lazy minting та gas-free mint

Gas-free mint через підпис: творець підписує voucher (tokenId, tokenURI, price, signature), покупець надає voucher в mint() — контракт верифікує підпис через ECDSA.recover() і минтить. Працює на OpenSea через їх Seaport протокол. Seaport — оптимізований контракт з мінімальним gas usage. Розуміння його механіки важливе при інтеграції custom marketplace логіки.

Стек для NFT-проектів

• Контракти: Solidity 0.8.x, OpenZeppelin ERC721Enumerable або ERC721A (Azuki) для gas-оптимізованого batch mint, ERC1155 від OpenZeppelin
• VRF та автоматизація: Chainlink VRF v2.5, Chainlink Automation
• Зберігання: Pinata (IPFS pinning), NFT.Storage, Arweave для постійного зберігання
• Маркетплейс: OpenSea Seaport protocol, кастомна інтеграція
• Фронтенд: wagmi v2 + viem, RainbowKit для wallet connection, React + TypeScript

Процес розробки

1. Проектування mint-механіки — allowlist, public sale, price curve (Dutch auction або фіксована), limits per wallet
2. Контракти — з Foundry fuzz-тестами на mint limits, merkle proof-верифікацію, royalty calculations
3. IPFS деплой — завантаження метаданих та images до reveal, піннінг на мінімум двох сервісах
4. Reveal — якщо використовується Chainlink VRF, тест на testnet обов'язковий: VRF subscription має бути funded LINK токенами
5. Маркетплейс-інтеграція — верифікація колекції на OpenSea, налаштування роялті, тест MetadataUpdate events
6. Деплой та моніторинг — Tenderly для відлову reentrancy, Etherscan API для верифікації контракту, налаштування оповіщень за подіями

Що входить в роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, Rust для Solana) з коментарями
• Тест-сьют (Foundry/Hardhat) з покриттям ≥90%
• Документація розгортання та інструкції з інтеграції
• Доступи до pinning-сервісів (Pinata/Pinfluence)
• Скрипти для генерації метаданих (Python/JS)
• Підтримка при верифікації на маркетплейсах
• 30 днів технічної підтримки після деплою

Строки

Вартість розраховується індивідуально після аудиту вашого завдання. Надішліть brief з описом проекту — оцінимо прозоро протягом 3 робочих днів. Для постійних клієнтів діє гнучка система знижок на пакетні замовлення. Зв'яжіться з нами для детального обговорення вашого NFT-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.