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

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

Класична проблема 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) — кожен батч унікален. Добре для високовартісних товарів (вино, люкс), де кожна партія має унікальні характеристики
• 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 системою й блокчейном.

Економічні інцентиви

Для участі заінтересованих сторін:

• Споживачі довіряють on-chain верифікованим даним
• Виробники заробляють преміум за верифіковане походження
• Сертифікатори заробляють комісії за сертифікаційні послуги
• Платформи беруть відсоток від преміуму виробника

DAO токени можуть управляти оновленнями політики — додавання нових прийнятних сертифікаторів, зміна стандартів, тощо.

Тайм-лайн й зусилля

Итого: 19–27 тижнів. Основні невідомі: час на переконання учасників індустрії до адоптації, регуляторні затвердження якщо потрібні.

Ключовий фактор успіху: досягнення критичної маси учасників. Система цінна тільки якщо великі сертифікатори й виробники це використовують.