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

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

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

Проблема oracle gap и физической привязки

Центральная техническая проблема supply chain traceability — так называемый 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 строят системы на этом принципе. Алгоритм сводится к вычислению хеша от high-resolution снимка поверхности и хранению commitment в блокчейне при производстве. При верификации — повторное сканирование и сравнение признаков.

IoT-сенсоры в цепи поставок

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

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

Выбор сети и модель данных

Полный on-chain storage для enterprise supply chain избыточен и дорог. Стандартная гибридная модель:

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

Контракт реестра активов

Минимальная архитектура — ERC-721 с расширениями для supply chain:

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. Каждый участник может записывать события только для своего этапа.

Batching для снижения gas costs

При высоком объёме событий (тысячи единиц товара в день) прямая запись в блокчейн каждого события неэкономична. Решение — 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 costs в 100–1000x при сохранении cryptographic verifiability.

Интеграция с GS1 и отраслевыми стандартами

Для серьёзного enterprise-проекта нельзя изобретать идентификаторы с нуля. GS1 стандарты (EAN, GTIN, GLN, SGTIN) используются в большинстве supply chain систем глобально. Блокчейн-реестр должен поддерживать маппинг 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. Для supply chain: обработчики handleCustodyTransferred, handleVerificationEvent, handleBatchSubmitted. Данные агрегируются в entities Product, CustodyEvent, Participant.

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

Стек и сроки

Технологический выбор зависит от требований к децентрализации:

• Permissioned (consortium): Hyperledger Fabric или Besu private network. Меньше gas-проблем, контроль над участниками, нет публичной верифицируемости
• Public L2: Polygon PoS или Arbitrum для баланса стоимости и открытости
• Enterprise public: Ethereum mainnet для максимальной credibility (ювелирка, luxury)

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

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