Розробка системи прив'язки фізичного товару до NFT

Розробка системи привязки фізичного товара до NFT

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

Способи фізичної привязки: що працює на практиці

NFC-чипи з криптографічною підписом — найпоширеніший підхід для luxury goods, кроссовок, арту. Чипи типу NTAG424 DNA (NXP) або Kong Halo генерують унікальну підпис при кожному сканованні (CMAC-based). Підпис верифікується on-chain через ecrecover — контракт перевіряє, що підпис відповідає зареєстрованому публічному ключу чипу.

Проблема: чип можна фізично витягнути та перевставити в інший товар. Рішення — інтеграція в важкодоступні елементи (внутрішня підошва, сердцевина пробки, спеціальні деструктивні наклейки). Ще варіант: PUF (Physically Unclonable Function) — чипи, фізичні характеристики яких унікальні та не піддаються клонуванню.

QR-коди з підписаними URL — дешевше, але значно слабше. QR можна скопіювати. Годится тільки для масових товарів з низькою вартістю, де спроба мошенництва не окупається.

RFID з шифруванням — використовується в fashion (Louis Vuitton, Prada працюють з Aura Blockchain Consortium на базі ConsenSys). Дорожче NFC, але краща дальність считування.

Біометричні мітки — для творів мистецтва: спектральний аналіз, мікроскопічні маркери, ДНК-мітки (так, це існує — компанії типу Tagsmart). Верифікація вимагає спеціалізованого обладнання, але підробити практично неможливо.

Архітектура on-chain компонентів

Контракт реєстрації зберігає маппинг між ідентифікатором фізичного об'єкта та token ID. Але деталі мають значення:

contract PhysicalBacking {
    struct PhysicalAsset {
        bytes32 chipPublicKeyHash;   // keccak256 від публічного ключа NFC
        uint256 tokenId;
        address collection;
        uint64 registeredAt;
        bool verified;               // пройшов ли останню верифікацію
        uint64 lastVerifiedAt;
    }
    
    // chip public key -> asset data
    mapping(bytes32 => PhysicalAsset) public assets;
    
    function verifyChip(
        bytes32 chipPublicKey,
        bytes calldata chipSignature,
        bytes32 challengeHash
    ) external returns (bool) {
        // ecrecover перевіряє підпис чипа
        address recovered = ECDSA.recover(challengeHash, chipSignature);
        require(recovered == address(uint160(uint256(chipPublicKey))), "Invalid signature");
        
        PhysicalAsset storage asset = assets[keccak256(abi.encode(chipPublicKey))];
        asset.lastVerifiedAt = uint64(block.timestamp);
        asset.verified = true;
        
        emit ChipVerified(chipPublicKey, asset.tokenId, block.timestamp);
        return true;
    }
}

Challenge-response для запобігання replay атак — сервер генерує випадковий challenge, користувач прикладає телефон до чипа, чип підписує challenge + nonce. Без цього зловмисник може перехопити валідну підпис та переиспользовать.

Lifecycle: від мінту до перепродажі

Найскладніший момент — що відбувається при передачі фізичного товара? Три моделі:

Linked transfer — NFT та фізичний товар невідокремлені. При продажу NFT покупач повинен отримати й фізичний об'єкт, інакше угода невалідна. Реалізується через escrow: NFT блокується в контракті, при підтвердженні отримання фізичного товара (через oracle або multisig верифікаторів) — звільняється.

Decoupled — NFT та фізичний об'єкт можуть існувати незалежно. NFT представляє право власності, але фізичний об'єкт може бути у кастодіана (vault, warehouse). Популярно для gold-backed токенів, вин, предметів колекціонування.

Redeemable — NFT можна «спалити» для отримання фізичного об'єкта. Onboarding дорогий (EIP-2981 royalties не працюють після redeem), зато модель юридично зрозуміла.

Oracle проблема та trust minimization

Верифікація фізичного стану об'єкта неможлива повністю on-chain. Варіанти зниження ризику:

Decentralized oracle network — кілька незалежних верифікаторів підтверджують фізичний стан. Використовуємо Chainlink Functions або кастомний multisig верифікаторів з reputation stake. Зловмисник потрібно підкупити >50% верифікаторів.

Insurance bond — верифікатори ставлять залог, який срізується при доказаному мошенництві. Механізм аналогічний slashing в PoS.

Zero-knowledge proofs для верифікації — експериментально: ZK-proof що NFC-чип сканувався пристроєм з визначеними характеристиками, без розкриття локації та особистих даних. Реалізується через zkVM (Risc0, SP1).

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

Для роботи з OpenSea, Blur, Rarible потрібно правильно структурувати metadata. Фізично-обеспечені NFT повинні:

• Мати physical_attributes в metadata з верифіцюємими характеристиками
• Підтримувати ERC-5169 (scriptURI) — стандарт для executable scripts, дозволяє маркетплейсу показати кнопку «Verify Physical Item»
• Реалізувати ERC-7401 (nestable NFTs) якщо фізичний товар складається з компонентів

Додатково для luxury goods рекомендуємо інтеграцію з Arianee Protocol — open-source стандарт для digital product passports, вже прийнятий рядом люксових брендів.

Юридична сторона

Технічна привязка NFT до фізичного товара не створює автоматично юридичних прав. Необхідно:

• Terms of Service з явним указанням, що NFT представляє право власності на фізичний об'єкт
• Механізм dispute resolution (арбітраж або Kleros для on-chain спорів)
• Відповідність нормам про transfer of title в юрисдикції покупця/продавця
• Для цінних об'єктів — інтеграція з традиційними реєстрами (страхові поліси, Certificate of Authenticity)

Stack реалізації