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

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

Классическая проблема supply chain: сертификаты происхождения подделываются, данные о цепочке поставок хранятся в разрозненных ERP-системах разных участников и не верифицируемы третьими сторонами, а потребитель не имеет возможности проверить что "органический продукт" действительно органический. Блокчейн сам по себе не решает эту проблему — данные в смарт-контракт вносит человек, и если человек вносит неверные данные, блокчейн лишь гарантирует их неизменность, но не достоверность. Правильная архитектура системы сертификации — это понимание где blockchain реально помогает, а где нет.

Архитектурные решения

Выбор сети

Для supply chain систем с корпоративными участниками подходят два класса решений:

Публичные сети (Polygon, Avalanche, Base) — прозрачность для конечного потребителя. Любой может верифицировать данные через block explorer. Минус — все данные публичны, что может быть неприемлемо для B2B данных о контрагентах и ценах.

Permissioned сети (Hyperledger Besu, Quorum, Fabric) — приватность участников, высокая производительность, фиксированный набор валидаторов. Подходит для consortium участников. Минус — теряется trustless гарантия, характерная для публичных сетей.

Гибридный подход: приватная сеть для операционных данных + якорение хешей на публичный блокчейн для аудируемости. Оптимальный вариант для большинства enterprise-случаев.

Идентификаторы продуктов

Стандарт — GS1 EPCIS 2.0 для событий в цепочке поставок. Каждый физический объект получает уникальный идентификатор (EPC — Electronic Product Code), привязанный к on-chain записи:

contract ProductRegistry {
    struct ProductBatch {
        bytes32 batchId;          // хэш от GS1 GTIN + lot number + expiry
        address certifiedBy;       // аккаунт сертифицирующего органа
        bytes32 documentHash;      // IPFS CID документов в bytes32
        uint256 certifiedAt;
        CertificationLevel level;
        bool revoked;
    }
    
    enum CertificationLevel { 
        ORIGIN_DECLARED,    // продавец задекларировал происхождение
        AUDITOR_VERIFIED,   // независимый аудитор верифицировал
        LAB_TESTED,         // лабораторные анализы подтверждены
        CERTIFIED           // полная сертификация пройдена
    }
    
    mapping(bytes32 => ProductBatch) public batches;
    mapping(bytes32 => bytes32[]) public batchEvents; // цепочка событий
    
    // только аккредитованные сертификаторы
    mapping(address => bool) public certifiers;
    
    modifier onlyCertifier() {
        require(certifiers[msg.sender], "Not authorized certifier");
        _;
    }
    
    function certifyBatch(
        bytes32 batchId,
        bytes32 documentHash,
        CertificationLevel level
    ) external onlyCertifier {
        batches[batchId] = ProductBatch({
            batchId: batchId,
            certifiedBy: msg.sender,
            documentHash: documentHash,
            certifiedAt: block.timestamp,
            level: level,
            revoked: false
        });
        emit BatchCertified(batchId, msg.sender, level);
    }
    
    function revokeCertification(bytes32 batchId, string calldata reason) 
        external onlyCertifier 
    {
        require(batches[batchId].certifiedBy == msg.sender, "Not your cert");
        batches[batchId].revoked = true;
        emit CertificationRevoked(batchId, reason);
    }
}

NFT vs. SFT vs. fungible token

Для сертификации батчей продуктов:

• ERC-721 (NFT) — каждый батч уникален. Хорошо для высокоценных товаров (wine, luxury), где каждая партия имеет уникальные характеристики
• ERC-1155 (Semi-fungible) — оптимален для большинства случаев: внутри батча единицы одинаковы, между батчами — нет. Позволяет передавать часть батча
• ERC-20 — для сыпучих/жидких товаров без фиксированных партий (зерно, нефть)

Цепочка событий (трансфер custody)

Каждое перемещение товара в цепочке поставок записывается как событие. События образуют auditable trail:

contract SupplyChainEvents {
    struct CustodyEvent {
        bytes32 batchId;
        address from;       // предыдущий владелец / производитель
        address to;         // следующий владелец / дистрибьютор
        bytes32 locationHash; // хэш GPS-координат или адреса склада
        bytes32 conditionsHash; // хэш данных IoT (температура, влажность)
        uint256 timestamp;
        EventType eventType;
    }
    
    enum EventType {
        PRODUCED,
        QUALITY_CHECKED,
        PACKAGED,
        SHIPPED,
        CUSTOMS_CLEARED,
        RECEIVED,
        RETAIL_LISTED,
        SOLD
    }
    
    event CustodyTransferred(
        bytes32 indexed batchId,
        address indexed from,
        address indexed to,
        EventType eventType
    );
}

Хранить сырые данные о местоположении и условиях хранения on-chain дорого. Правильная схема: данные → IPFS/Arweave → хэш данных on-chain. Верификатор скачивает данные с IPFS и проверяет что хэш совпадает с on-chain записью.

Интеграция с IoT

Физические сенсоры (температура при транспортировке, влажность на складе) — важная часть системы для food & pharma. Проблема: IoT-устройство не может самостоятельно подписывать Ethereum транзакции в условиях ограниченных вычислительных ресурсов.

Архитектурное решение — oracle pattern:

IoT Device → Edge Gateway → Oracle Service → Smart Contract

Edge Gateway собирает данные с устройств, агрегирует их и через защищённый канал передаёт в oracle service (Chainlink, API3, или кастомный). Oracle записывает данные on-chain с подписью доверенного оператора.

Для повышения доверия к IoT-данным: TEE (Trusted Execution Environment) на edge gateway — Intel SGX или ARM TrustZone. Данные подписываются внутри изолированной среды, и proof выполнения в TEE может быть верифицирован on-chain.

Верификация потребителем

QR-код на продукте кодирует batchId. Потребитель сканирует QR и видит:

• Статус сертификации (уровень, орган, дата)
• Полную цепочку custody от производителя до полки
• Документы (сертификаты, лабораторные анализы) на IPFS
• Был ли сертификат отозван

Это реализуется как статический сайт или мобильное приложение, которое читает данные напрямую с блокчейна через JSON-RPC или через The Graph (для более сложных запросов).

Управление доступом и аккредитация

Критически важный компонент — система управления тем, кто имеет право вносить сертификационные записи. Варианты:

Для regulated industries (organic food, pharma) оптимальна модель где национальные органы аккредитации управляют on-chain списком авторизованных сертификаторов. Это создаёт bridge между традиционной regulatory системой и блокчейном.