Розробка системи верифікації автентичності через NFT

Фізичний товар з QR-кодом «підтвердженим блокчейном» — це маркетинг, не безпека. Справжня проблема в тому, що NFT зберігає посилання на щось, але не саме це щось. Підробити фізичний предмет і переклеїти QR-код з оригінального на копію — тривіально, якщо система не вирішує задачу криптографічної прив'язки фізичного об'єкта до цифрового токена. Наша система верифікації автентичності через NFT забезпечує надійний захист з використанням NFC-чіпів, on-chain реєстру та gasless верифікації. Маємо понад 5 років досвіду в блокчейн-розробці та більше 20 успішних проєктів з NFT-верифікації. Гарантуємо відповідність стандартам безпеки. NFC-чіпи з ECC в 1000 разів надійніші, ніж прості QR-коди без криптографії. Економія на логістиці — до 60%.

Як забезпечити криптографічну прив'язку фізичного об'єкта до NFT?

NFC-чіпи з криптографією

Найнадійніший підхід для фізичних товарів — NFC-чіпи з підтримкою ECC підписів (NTAG 424 DNA від NXP або аналоги Kong Halo). Чіп містить приватний ключ, який не може бути вилучений з пристрою фізично. При скануванні чіп підписує challenge-відповідь приватним ключем.

Схема верифікації:

1. При виробництві товару чіп генерує keypair. Публічний ключ записується в NFT метадані та в контракт верифікації.
2. Для верифікації користувач сканує NFC → чіп підписує keccak256(randomChallenge || timestamp) → підпис відправляється в backend або прямо в контракт.
3. Контракт перевіряє підпис через ecrecover — якщо recovered_address == chip_public_key і chip_public_key зареєстрований як належний конкретному tokenId — товар справжній.

function verifyChip(
    uint256 tokenId,
    bytes32 challenge,
    bytes memory signature
) external view returns (bool) {
    address chipAddress = _chipAddresses[tokenId];
    require(chipAddress != address(0), "Token not registered");

    bytes32 messageHash = keccak256(
        abi.encodePacked("\x19Ethereum Signed Message:\n32", challenge)
    );
    address recovered = ECDSA.recover(messageHash, signature);
    return recovered == chipAddress;
}

Протокол Kong (ERC-7015 / Kong Halo) стандартизує саме цю схему. Для люксових товарів, годинників, кросівок — це production-ready рішення.

QR-код без фізичної криптографії

Якщо NFC не підходить (паперові документи, упаковка), використовується інша схема. Виробник створює пару (publicId, secretKey) — publicId вшивається в QR-код і зберігається в NFT, secretKey друкується всередині упаковки під захисним шаром. При перевірці користувач відкриває упаковку, вводить secretKey — backend перевіряє що keccak256(secretKey) == storedHash.

Це одноразова схема: після першої перевірки секрет розкрито. Для повторних верифікацій потрібен інший механізм. Підходить для предметів колекціонування, алкоголю, фармацевтики.

Чому важливий on-chain реєстр автентичності?

Структура контракту

Реєстр зберігає маппінг tokenId → AuthRecord:

struct AuthRecord {
    address chipAddress;      // публічний ключ NFC чіпа або нульовий адрес
    bytes32 secretHash;       // keccak256 від secret для QR схеми
    uint256 mintedAt;         // timestamp створення
    uint256 verificationCount; // скільки разів верифікували
    bool activated;           // активований чи (для одноразових)
    string productSku;        // SKU виробника
}

mapping(uint256 => AuthRecord) private _authRecords;

verificationCount — корисна аналітика. Товар, який верифікували 500 разів — або дуже популярний, або хтось намагається брутфорсити. Threshold alert на backend при аномальній кількості верифікацій.

Статуси життєвого циклу

Для більш складних сценаріїв додається статус:

Історія передач прозора через стандартні ERC-721 Transfer events — не потрібно зберігати окремо.

Як реалізувати верифікацію без газу для користувача?

Верифікація не повинна вимагати gas від користувача — це бар'єр для adoption. Два підходи:

Off-chain з on-chain доказом. Backend робить eth_call до контракту верифікації (безкоштовно), результат повертає користувачеві. Джерело істини — блокчейн, але gas не платиться.

Gasless верифікація через signature. Користувач підписує запит верифікації (EIP-712), backend перевіряє підпис чіпа та підпис користувача, записує подію верифікації в off-chain лог (з cryptographic proof). Для критичних верифікацій (страхові, юридичні) — періодичний on-chain запис Merkle root від batch верифікацій.

Інтеграція з маркетплейсами та ролі доступу

Стандарт ERC-721 + додаткові метадані. В tokenURI JSON додаються поля:

{
  "name": "Product #12345",
  "attributes": [
    {"trait_type": "Authenticity", "value": "Verified"},
    {"trait_type": "Manufacturer", "value": "Brand XYZ"},
    {"trait_type": "SKU", "value": "PROD-001"},
    {"trait_type": "Chip Type", "value": "NXP NTAG 424 DNA"}
  ],
  "verification_contract": "0x...",
  "chip_public_key": "0x..."
}

OpenSea та інші маркетплейси відображають ці атрибути. Покупець на вторинному ринку може верифікувати товар перед покупкою.

Контракт використовує OpenZeppelin AccessControl:

• MANUFACTURER_ROLE — право мінтити нові токени та реєструвати чіпи
• VERIFIER_ROLE — право записувати результати верифікації on-chain (для enterprise клієнтів)
• FLAGGING_ROLE — право позначати токени як спірні (антипідробна служба бренду)
• DEFAULT_ADMIN_ROLE — управління ролями

Виробник може делегувати авторизованим дистриб'юторам право реєструвати продукти в своєму сегменті.

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

Орієнтовні терміни та вартість

Система з QR-кодами та on-chain реєстром без NFC — від 1 тижня, вартість від $5,000. З підтримкою NFC-чіпів (Kong/NTAG 424 DNA), рольовою моделлю, mobile SDK для сканування та аналітичним dashboard — від 2 до 3 тижнів, вартість від $15,000. Вартість розраховується індивідуально за обсягом робіт.

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

Чому розробка 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-проекту. Отримайте консультацію з архітектури маркетплейсу — залиште заявку, і ми оцінимо проект за три дні.