Розробка системи трасування товарів на блокчейні

Розробка системи відстеження товарів на блокчейні

Типова ситуація: виробник предметів розкоші хоче "блокчейн для автентичності". Приходять із запитом — QR-код на упаковці, клієнт сканує, бачить "автентичний". Проблема в тому, що така система нічого не гарантує: якщо дані про походження товару внесені в блокчейн самим виробником без верифікації фізичного прив'язування, запис на Ethereum нічим не відрізняється від запису в Excel. Блокчейн вирішує проблему незмінності даних після запису, а не проблему достовірності даних при записі. Це розрізнення визначає всю архітектуру чесної системи відстеження.

Проблема oracle gap та фізичного прив'язування

Центральна технічна проблема відстеження ланцюга поставок — так звана oracle gap: розрив між фізичним світом та on-chain даними. Товар можна підмінити, зберігши QR-код або RFID-мітку. Рішення існують, кожне зі своїми компромісами.

NFC з захистом від клонування

Чипи NXP NTAG424 DNA реалізують протокол з криптографічною challenge-response. При кожному скануванні чип генерує унікальний CMAC (Cipher-based Message Authentication Code), похідний від внутрішнього лічильника та AES-128 ключа, прошитого під час виробництва. Клонування чипа без знання ключа фізично неможливо. Верифікація:

Scan → Chip returns (UID, Counter, CMAC) → Backend verifies CMAC with stored key
→ Counter monotonically increasing? → Legit scan
→ Counter same as before? → Replay attack / counterfeit

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

Фізично невідтворювані функції (PUF)

Для високовартісних товарів (ювелірка, фармацевтика) — мікроструктурне сканування: унікальний "відбиток" матеріалу, невідтворюваний при виробництві. Компанії як Alitheon та Certilogo будують системи на цьому принципі. Алгоритм зводиться до обчислення хеша від високорозрізнювального знімку поверхні та зберігання commitment у блокчейні під час виробництва. При верифікації — повторне сканування та порівняння ознак.

IoT-датчики в ланцюгу поставок

Для швидкопсувних товарів (фарма, продукти): датчики температури/вологості з підписом даних на борту пристрою (Trusted Execution Environment або secure element). Дані публікуються через MQTT → Kafka → on-chain oracle. Стандарт де-факто — інтеграція з Chainlink Functions або кастомний oracle на базі Town Crier (TEE-based).

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

Вибір мережі та модель даних

Повне on-chain збереження для enterprise supply chain надлишкове та дороге. Стандартна гібридна модель:

Для зберігання хешів даних із доступністю — IPFS з закріпленням через Pinata або web3.storage. Контракт зберігає лише CID (Content Identifier) та хеш вмісту для верифікації цілісності.

Контракт реєстру активів

Мінімальна архітектура — ERC-721 з розширеннями для ланцюга поставок:

struct AssetRecord {
    bytes32 physicalId;      // хеш NFC UID або PUF fingerprint
    address currentCustodian;
    uint256 mintedAt;
    bytes32 metadataCID;     // IPFS CID пакету атрибутів
    uint8 status;            // enum: MANUFACTURED, IN_TRANSIT, CUSTOMS, DELIVERED
}

event CustodyTransferred(
    uint256 indexed tokenId,
    address indexed from,
    address indexed to,
    bytes32 locationHash,
    uint256 timestamp
);

event VerificationEvent(
    uint256 indexed tokenId,
    bytes32 indexed verifierHash,
    bool authentic,
    uint256 nfcCounter
);

Для ланцюгів з багатьма учасниками (виробник → експортер → логіст → таможня → роздріб) — ролі через AccessControl. Кожен учасник може записувати подій лише для свого етапу.

Батчинг для зниження gas витрат

При високому обсязі подій (тисячі одиниць товару на день) прямий запис у блокчейн кожної подій неекономічний. Рішення — Merkle tree batching: агрегуємо подій за період (5–15 хвилин), будуємо Merkle tree, публікуємо лише root у блокчейн. Окрема подія верифікується надання Merkle proof.

function submitBatch(bytes32 merkleRoot, uint256 eventCount, bytes32 batchCID) 
    external onlyRole(BATCH_SUBMITTER_ROLE) 
{
    batches[batchNonce] = BatchRecord(merkleRoot, eventCount, block.timestamp, batchCID);
    emit BatchSubmitted(batchNonce++, merkleRoot, eventCount);
}

function verifyEvent(uint256 batchId, bytes32 leaf, bytes32[] calldata proof) 
    external view returns (bool) 
{
    return MerkleProof.verify(proof, batches[batchId].merkleRoot, leaf);
}

Цей підхід знижує on-chain витрати в 100–1000x при збереженні криптографічної верифікованості.

Інтеграція з GS1 та галузевими стандартами

Для серйозного enterprise-проекту неможливо винаходити ідентифікатори з нуля. Стандарти GS1 (EAN, GTIN, GLN, SGTIN) використовуються в більшості систем ланцюга поставок у світі. Реєстр на блокчейні повинен підтримувати картування SGTIN → tokenId, GLN → адреси учасників мережі.

GS1 Digital Link (ISO/IEC 18975) — стандарт для структури URL QR-кодів, що дозволяє одному коду вести на різні ресурси залежно від контексту. Наша система реалізує Digital Link resolver, який для /01/{gtin}/21/{serial} повертає on-chain дані.

Для фармацевтики — дотримання DSCSA (Drug Supply Chain Security Act, США) та FMD (Falsified Medicines Directive, ЄС). Обидва вимагають серіалізації та верифікації на кожному етапі ланцюга. Компонент на блокчейні замінює (або доповнює) централізовані реєстри на кшталт NMVS.

Backend та індексування

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

The Graph subgraph — декларативне індексування подій у GraphQL API. Для ланцюга поставок: обробники handleCustodyTransferred, handleVerificationEvent, handleBatchSubmitted. Дані агрегуються в сутності Product, CustodyEvent, Participant.

Альтернатива для enterprise — власний індексер на Go/Rust з PostgreSQL. Більш передбачувана затримка, можливість кастомних агрегацій, відсутність залежності від TheGraph Network.

Стек та терміни

Вибір технології залежить від вимог децентралізації:

• Permissioned (consortium): Hyperledger Fabric або Besu приватна мережа. Менше проблем з газом, контроль над учасниками, немає публічної верифікованості
• Public L2: Polygon PoS або Arbitrum для балансу вартості та відкритості
• Enterprise public: Ethereum mainnet для максимальної credibility (ювелірка, люкс)

Типовий стек: Solidity + Hardhat/Foundry (контракти), Go (backend + indexer), React (портал верифікації), NFC SDK (iOS/Android), PostgreSQL + Redis.

Реалістичний MVP з NFC-верифікацією, двома-трьома ролями учасників та базовим порталом — 10–14 тижнів. Повна система з IoT-інтеграцією, GS1-сумісністю та enterprise SSO — від 6 місяців.