Розробка блокчейн-рішення для supply chain

Розробка блокчейн-рішення для supply chain

Перш ніж проектувати систему, потрібно чесно відповісти: зачем тут блокчейн? У більшості корпоративних supply chain проектів ответ виявляється неконвінцивним — "щоб всі учасники видели одну версію даних" вирішується звичайною shared database з правильними правами доступу. Блокчейн виправданий коли: учасники не довіряють один одному й не довіряють єдиному оператору бази даних, потрібна неізмінність записів з верифікованою історією, смарт-контракти автоматизують розрахунки між сторонами без посередника. Якщо ці умови виконані — йдемо далі.

Архітектурні паттерни для supply chain

Public vs Private blockchain: реальний trade-off

Public EVM (Ethereum/Polygon/Arbitrum) — дані публічні, смарт-контракти верифіковані будь-ким, не потрібно договаривватися про консенсус. Мінус: конкурентні дані (себестоимість, обсяги, поставщики) стають публічними. Рішення — хранить хеши даних on-chain, самі дані в зашифрованому хранилище.

Hyperledger Fabric — permissioned blockchain, дані видні тільки членам channel. Складна настройка, вимагає виділеної інфраструктури, високий поріг входу. Виправдан для enterprise консорціумів з чіткою governance моделлю.

Polygon CDK / OP Stack (private instance) — EVM-compatible L2 з permissioned валідатором. Компромісс: EVM tooling й смарт-контракти, але контроль над складом учасників. Дані можна публікувати до public DA layer (Ethereum, Avail) для верифіковності без публічності змісту.

Для більшості реальних supply chain проектів — public EVM з шифруванням чутливих даних або Polygon CDK. Hyperledger Fabric — якщо уже є enterprise Java команда й нема планів інтеграції з DeFi.

Модель даних: що й як хранить on-chain

Антипаттерн: хранить всі дані про продукт on-chain. Вага товару, дата виробництва, 10,000 записів температурного логу — все це on-chain дорого й надмірно.

Правильний підхід: on-chain зберігаються тільки anchors й transitions.

Product Identity (NFT) кожна одиниця товару або партія це NFT. ERC-721 для унікальних одиниць (твори мистецтва, ювелірка, дороге обладнання), ERC-1155 для партій взаємозамінних товарів.

struct ProductBatch {
    bytes32 batchId;
    uint256 productTypeId;
    uint256 quantity;
    address manufacturer;
    uint64 manufacturedAt;
    bytes32 certificationHash;  // хеш сертифікатів якості в IPFS
    bytes32 specificationHash;  // хеш технічних характеристик
    BatchStatus status;
}

Chain of Custody Events кожна передача прав: виробник → склад → перевізник → таможня → дистрибьютор → ритейлер. Кожен event містить: from, to, timestamp, location hash, condition hash, documents hash.

event CustodyTransferred(
    bytes32 indexed batchId,
    address indexed from,
    address indexed to,
    bytes32 locationHash,
    bytes32 conditionHash,
    bytes32 documentsHash,
    uint64 timestamp
);

Milestone Anchoring контрольні точки з хешами документів. Таможенна декларація, сертифікат походження, інспекційний звіт — документи в IPFS/Arweave, хеши в подіях контракту.

Верифікація фізичного світу

Блокчейн не може сам верифікувати що товар дійсно відповідає запису. Кілька механізмів:

IoT + Oracle датчики (температура, вологість, GPS) передають дані через IoT gateway до oracle. Oracle агрегує й записує в контракт. Для холодової ланцюга (фармацевтика, харчові продукти) це критично.

QR/NFC + мобільне приложение кожен учасник ланцюга сканує мітку при приёмці й передачі. Транзакція підписується ключем працівника. Аудит-слід створюється від кожного учасника.

Proof of Inspection аккредитований інспектор (фізична особа) підписує inspection report своїм кастодіальним ключем. On-chain реєстр аккредитованих інспекторів з revocation.

ZK-proof для чутливих даних поставщик хоче доказати що товар відповідає спецификації (температурний режим дотримувався), не розголошуючи конкретні значення. ZK-proof дозволяє сказати "температура завжди була в діапазоні 2–8°C" без публікації точних значень. Для supply chain застосовується у premium food tracking та фармацевтиці.

Смарт-контракти: ключові компоненти

Registry контракти

ParticipantRegistry on-chain реєстр учасників supply chain з ролями: Manufacturer, Carrier, Warehouse, CustomsBroker, Inspector, Retailer. Верифікація учасників через DAO governance або централізований оператор (залежить від моделі).

ProductTypeRegistry каталог типів продуктів з validation rules. Параметри контролю якості для кожного типу: допустимі діапазони температури, вологості, максимальний час у дорозі.

Supply Chain контракт

contract SupplyChainTracker {
    mapping(bytes32 => ProductBatch) public batches;
    mapping(bytes32 => CustodyEvent[]) public custodyHistory;
    mapping(bytes32 => bytes32[]) public milestones;

    function initiateBatch(
        bytes32 batchId,
        uint256 productTypeId,
        uint256 quantity,
        bytes32 specificationHash
    ) external onlyRole(MANUFACTURER_ROLE) {
        require(batches[batchId].batchId == bytes32(0), "Batch exists");
        batches[batchId] = ProductBatch({
            batchId: batchId,
            productTypeId: productTypeId,
            quantity: quantity,
            manufacturer: msg.sender,
            manufacturedAt: uint64(block.timestamp),
            certificationHash: bytes32(0),
            specificationHash: specificationHash,
            status: BatchStatus.Created
        });
        emit BatchInitiated(batchId, msg.sender, productTypeId, quantity);
    }

    function transferCustody(
        bytes32 batchId,
        address to,
        bytes32 locationHash,
        bytes32 conditionHash,
        bytes32 documentsHash
    ) external {
        ProductBatch storage batch = batches[batchId];
        require(getCurrentCustodian(batchId) == msg.sender, "Not custodian");
        require(participantRegistry.isActive(to), "Invalid recipient");

        custodyHistory[batchId].push(CustodyEvent({
            from: msg.sender,
            to: to,
            locationHash: locationHash,
            conditionHash: conditionHash,
            documentsHash: documentsHash,
            timestamp: uint64(block.timestamp)
        }));

        emit CustodyTransferred(batchId, msg.sender, to,
            locationHash, conditionHash, documentsHash, uint64(block.timestamp));
    }
}

Payment Automation

Для автоматичних розрахунків між учасниками ланцюга — escrow з milestone release:

// Оплата перевізнику при підтверджені доставки
function confirmDelivery(bytes32 batchId) external {
    ShipmentPayment storage payment = payments[batchId];
    require(msg.sender == payment.buyer, "Not buyer");
    require(getCurrentCustodian(batchId) == payment.buyer, "Not delivered");

    uint256 amount = payment.amount;
    payment.released = true;
    IERC20(payment.token).safeTransfer(payment.carrier, amount);

    emit PaymentReleased(batchId, payment.carrier, amount);
}

Для складних multi-party розрахунків (імпортер платить таможному брокеру, перевізнику, страховщику по різних milestone) — composable payment streams через Superfluid або кастомний escrow з multiple payees.

Інтеграція з legacy ERP системами

Реальна supply chain не починается з чистого листа — є SAP, Oracle SCM, 1С. Інтеграція:

Event-driven middleware ERP публікує события (товар прийнятий, накладна закривається) в message bus (Kafka, RabbitMQ). Middleware трансльрує в blockchain транзакції. Bidirectional: blockchain события уходять обратно в ERP.

API gateway з кешуванням більшість ERP запитів читають дані, не пишуть. Кешувати blockchain дані у традиційній БД для швидких запитів, синхронізувати события.

Identity mapping ERP використовує внутрішні ID, blockchain використовує адреси й хеши. Потрібна таблиця маппінгу (off-chain, у традиційній БД) для синхронізації.

Governance й мультисигні

Supply chain consortium вимагає governance:

• Додавання нового учасника: multisig від існуючих ключових учасників
• Зміна правил верифікації: timelock + voting
• Emergency pause: 2/3 мультисіг від core participants
• Розв'язання спорів: on-chain arbitration або off-chain з on-chain enforcement

Gnosis Safe як базовий multisig + Governor контракт від OpenZeppelin для голосування — стандартна комбінація.

Етапи розробки

Реалістичний тайм-лайн від аналізу до production — 6–10 місяців. Основний ризик не у блокчейні — у change management: убедити всіх учасників ланцюга використовувати нову систему.