Інтеграція блокчейну з системою управління ланцюгами постачання

Інтеграція блокчейну в систему управління ланцюгом поставок

Компанії роками будували EDI-інтеграції, ERP-системи, портали для постачальників — і все рівно стикаються з однією проблемою: коли груз втрачений, пошкоджений чи доставлений з затримкою, неможливо швидко встановити, на якій ланці ланцюга сталася збій. Кожен учасник веде свою базу даних, дані розходяться, відповідальність розмивається. Blockchain не розв'язує логістику — але створює єдиний верифіковуваний реєстр, в якому кожна подія підписана учасником, який її створив, і не може бути змінена задним числом.

Архітектурне рішення: що саме писати в блокчейн

Перше питання при проектуванні — не "який блокчейн", а "що конкретно потрібно верифікувати". Блокчейн дорогий для зберігання даних і повільний для складної логіки. Правильна архітектура: off-chain зберігання, on-chain верифікація.

Модель даних

Кожен фізичний об'єкт отримує цифрову близнюк — запис у смарт-контракті, прив'язану до унікального ідентифікатора. Ідентифікатор може бути:

• QR-код / RFID — для серійних продуктів. RFID читається автоматично на воротах складу, транзакція створюється без участі людини.
• EPC (Electronic Product Code) — стандарт GS1, сумісний з більшістю існуючих WMS систем.
• NFT (ERC-721) — для унікальних активів: партія ліків, дороговартісне обладнання, твір мистецтва. Token ID = ID фізичного предмета.

Сам контракт зберігає лише хеші та метадані, не сирі дані:

struct ShipmentEvent {
    bytes32 dataHash;        // keccak256 від повних даних події
    address actor;           // хто створив подію
    uint64 timestamp;
    EventType eventType;     // CREATED, DEPARTED, ARRIVED, INSPECTED, DELIVERED
    bytes32 locationId;      // ID локації з реєстру
}

Повні дані (температура, вага, фото) зберігаються в IPFS або корпоративному S3, у блокчейн йде лише хеш. У разі суперечки будь-яка сторона може подати оригінальні дані та довести їх відповідність on-chain хешу.

Вибір мережі

Для корпоративних проектів у ланцюзі поставок реальні три варіанти:

Більшість enterprise-клієнтів вибирають Polygon PoS або приватний Besu-вузол з періодичним анкоруванням у Ethereum mainnet. Анкоринг: раз на N блоків корінь Merkle tree всіх подій записується в публічний блокчейн — це дає публічну верифіковуваність без повної прозорості.

Інтеграція з існуючими ERP та WMS

Це найтрудомісткіша частина. Типовий стек у enterprise-клієнта: SAP S/4HANA або Oracle SCM, власний WMS, EDI-шлюзи з контрагентами, IoT-датчики (температура, вологість) від різних вендорів.

Шар інтеграції

Між legacy системами та блокчейном потрібен Event Bridge — сервіс, який:

1. Слухає подій з ERP (webhook / polling через SAP BAPI / JMS чергу)
2. Нормалізує дані в канонічний формат
3. Підписує транзакцію ключем учасника
4. Відправляє в блокчейн
5. Записує transaction hash назад у ERP для аудиту

Технічно це мікросервіс на Node.js або Go з чергою (Kafka / RabbitMQ) для надійності. Блокчейн-транзакція асинхронна, ERP не повинен очікувати її confirmation — ключовий момент для UX операторів.

SAP → BAPI Event → Kafka topic → Event Bridge → Sign & Submit → Blockchain
                                     ↓
                              Confirmation listener → TxHash → SAP Custom Field

Проблема ідентичності учасників

Кожен учасник ланцюга (постачальник, транспортна компанія, таможня, отримувач) повинен мати on-chain ідентичність. Два підходи:

Centralized registry — смарт-контракт з маппінгом address → ParticipantInfo. Швидко, але потребує довіри до реєстратора.

DID (Decentralized Identifiers) — стандарт W3C. Кожен учасник контролює свій DID, верифіковані credentials (сертифікати, ліцензії) прикріплюються як verifiable credentials. Складніше у реалізації, але правильно для inter-company сценаріїв. Реалізації: Ceramic Network, did:ethr (uPort).

Смарт-контракт: життєвий цикл поставки

contract SupplyChainRegistry {
    mapping(bytes32 => ShipmentEvent[]) public history;
    mapping(bytes32 => address)         public custodian;   // поточний володілець
    mapping(address => bool)            public authorizedActors;

    event EventRecorded(
        bytes32 indexed shipmentId,
        EventType indexed eventType,
        address indexed actor,
        uint64 timestamp
    );

    function recordEvent(
        bytes32 shipmentId,
        bytes32 dataHash,
        EventType eventType,
        bytes32 locationId
    ) external onlyAuthorized {
        history[shipmentId].push(ShipmentEvent({
            dataHash:   dataHash,
            actor:      msg.sender,
            timestamp:  uint64(block.timestamp),
            eventType:  eventType,
            locationId: locationId
        }));

        if (eventType == EventType.DEPARTED) {
            custodian[shipmentId] = msg.sender;
        }

        emit EventRecorded(shipmentId, eventType, msg.sender, uint64(block.timestamp));
    }
}

Контракт навмисне мінімалістичний. Бізнес-логіка (розрахунок SLA, штрафи, умовні платежі) реалізується окремо і може читати історію подій. Це спрощує аудит контракту та дозволяє змінювати бізнес-логіку без міграції даних.

Умовні платежі та escrow

Для автоматичних виплат при доставці використовується escrow паттерн:

Покупець депонує оплату → смарт-контракт escrow
При EventType.DELIVERED + підпис отримувача → release платежу постачальнику
При просрочці SLA → автоматичний штраф з escrow

ERC-20 токен або стейблкоїн (USDC, USDT) використовується як розрахунковий інструмент. Для B2B-розрахунків у рублях або євро потрібна додаткова off-ramp через ліцензований процесинг.

IoT-інтеграція та оракули

Дані з IoT-датчиків (температурні логери, GPS-трекери) не можуть напрямки потрапити в блокчейн — потрібен довірений посередник. Два варіанти:

Centralized oracle — ваш власний сервер підписує дані з датчика і відправляє транзакцію. Швидко і дешево, але створює single point of trust. Прийнятно для внутрішнього ланцюга поставок однієї компанії.

Chainlink CCIP / Chainlink Any API — децентралізована мережа оракулів. Дані з датчика через HTTPS запит до Chainlink node operator, агрегація кількох нод, on-chain запис. Дороже, але верифіковано для зовнішніх аудиторів.

Для cold chain (ліки, продукти): температурні порушення автоматично створюють on-chain подію CONDITION_BREACH і можуть блокувати подальший трансфер опіки до перевірки інспектором.

Етапи реалізації

Реалістичний timeline від початку до production: 6–9 місяців. Проекти, які обіцяють "блокчейн у ланцюзі поставок за 3 місяці", зазвичай будують централізовану базу даних з blockchain-маркетингом.