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

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розробка системи відстеження вантажів на блокчейні
Складний
від 1 тижня до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1284
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1196
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    901
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1119
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    586
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    853

Розробка системи відслідковування вантажів на блокчейні

Системи відслідковування вантажів існують десятиліттями — TMS, WMS, EDI. Проблема не у відсутності систем, а в тому що вони не розговорюють друг з одним. Грузовідправник у Китаї використовує одну систему, фрахтовий брокер — другу, таможня — третю, кінцевий одержувач бачить тільки то, що йому волів розповісти перевозник. Блокчейн тут — не про технологію, а про нейтральну платформу, якій довіряють всі сторони, тому що ніхто з них її не контролює.

Специфіка вантажних операцій: що потрібно відслідковувати

Учасники та їхні ролі

Типова міжнародна перевозка задіює:

  • Shipper (грузовідправник) — створює Bill of Lading, ініціює shipment
  • Freight Forwarder — організовує перевозку, документацію
  • Carrier (перевозник) — фізично везе вантаж (морський, авіа, ж/д, авто)
  • Port/Terminal Operator — прийом та видача контейнерів
  • Customs Broker — таможенне оформлення
  • Consignee (грузополучатель) — кінцевий одержувач
  • Bank/Financier — фінансування під Letter of Credit або документарний акредитив
  • Inspector/Surveyor — незалежна інспекція вантажу

Кожен учасник має свою систему, своє представлення про статус вантажу. On-chain система дає єдиний source of truth.

Ключові документи та события

Bill of Lading (B/L) — центральний документ у морських перевозках. Це одночасно розписка перевозчика, договір перевозки та товаророзпорядчувальний документ. Tokenization B/L — це окрема тема (electronic B/L, eBL), регульована стандартами BIMCO та DCSA.

События жизненного цикла вантажу:

Booking → Cargo Received at Origin Port → Loaded on Vessel → 
Departed → In Transit → Arrived at Destination Port → 
Customs Cleared → Available for Pickup → Delivered

Для авіаперевозок: Air Waybill замість B/L, інші checkpoint события. Для ж/д: Consignment Note (CIM/SMGS).

Архітектура системи

Дані: що on-chain, що off-chain

On-chain:

  • Унікальний ідентифікатор вантажу (shipment ID → хеш)
  • Хеші документів (B/L, invoice, customs declaration, сертифікати)
  • Переходи custody з часовими мітками
  • Milestone события з координатами (хеш) та підписами учасників
  • Умови платежу та їх виконання

Off-chain (IPFS/Arweave):

  • Самі документи (PDF, XML)
  • Детальні логи даних датчиків
  • Фотографії вантажу

Off-chain (традиційна БД для швидких запитів):

  • Поточний статус всіх shipments для конкретного учасника
  • Аналітика, звіти
  • Індекс за tracking number / container number

Shipment NFT

Вантаж як NFT — це правильна абстракція для унікальних shipments. Передача NFT = передача права власності на вантаж (для Documentary Collection / Letter of Credit операцій).

contract ShipmentRegistry is ERC721, AccessControl {
    struct Shipment {
        bytes32 shipmentId;         // унікальний ID
        bytes32 bookingReference;   // номер бронювання
        ShipmentType shipmentType;  // FCL, LCL, Air, Rail, Road
        address shipper;
        address consignee;
        bytes32 originPortHash;
        bytes32 destinationPortHash;
        bytes32 blHash;             // хеш Bill of Lading
        ShipmentStatus status;
        uint64 estimatedDeparture;
        uint64 estimatedArrival;
    }

    mapping(bytes32 => Shipment) public shipments;
    mapping(bytes32 => MilestoneEvent[]) public milestones;
    mapping(bytes32 => bytes32[]) public documentHashes;

    function createShipment(
        bytes32 shipmentId,
        ShipmentType shipmentType,
        address consignee,
        bytes32 blHash,
        bytes32 originPortHash,
        bytes32 destinationPortHash,
        uint64 estimatedDeparture,
        uint64 estimatedArrival
    ) external onlyRole(FREIGHT_FORWARDER_ROLE) returns (uint256 tokenId) {
        // Mint NFT грузовідправникові, який може його передавати
        tokenId = _nextTokenId++;
        _mint(msg.sender, tokenId);

        shipments[shipmentId] = Shipment({
            shipmentId: shipmentId,
            bookingReference: bytes32(0),
            shipmentType: shipmentType,
            shipper: msg.sender,
            consignee: consignee,
            originPortHash: originPortHash,
            destinationPortHash: destinationPortHash,
            blHash: blHash,
            status: ShipmentStatus.Booked,
            estimatedDeparture: estimatedDeparture,
            estimatedArrival: estimatedArrival
        });

        emit ShipmentCreated(shipmentId, msg.sender, consignee, shipmentType);
    }
}

Milestone Events та мультиподписи

Критичні milestone события вимагають підтвердження кількома сторонами. Загрузка на судно повинна бути підтверджена і перевозником, і терміналом:

struct PendingMilestone {
    bytes32 shipmentId;
    MilestoneType milestoneType;
    bytes32 locationHash;
    bytes32 evidenceHash;
    uint64 timestamp;
    mapping(address => bool) confirmations;
    uint256 confirmationCount;
    bool executed;
}

function confirmMilestone(bytes32 milestoneId) external {
    PendingMilestone storage milestone = pendingMilestones[milestoneId];
    require(hasRole(getMilestoneRole(milestone.milestoneType), msg.sender),
        "Unauthorized confirmer");
    require(!milestone.confirmations[msg.sender], "Already confirmed");

    milestone.confirmations[msg.sender] = true;
    milestone.confirmationCount++;

    if (milestone.confirmationCount >= REQUIRED_CONFIRMATIONS[milestone.milestoneType]) {
        executeMilestone(milestoneId);
    }
}

IoT Integration: real-time позиція та стан

Для контейнерних перевозок критичні:

  • GPS позиція — оновлення кожні N годин через спутниковий трекер
  • Температура / вологість — для рефрижераторних контейнерів (reefer)
  • Вібрація / удари — для хрупких вантажів
  • Тамперні сенсори — несанкціоноване вскриття

Дані з IoT пристроїв не можна писати напрямки в блокчейн — занадто дорого. Схема агрегації:

IoT Device → Satellite/Cellular Gateway → Data Aggregation Server →
→ Oracle → Smart Contract (aggregated alerts + checkpoints)

Oracle записує не raw stream, а: поточну позицію кожні 6 годин, аномальні события (температура вийшла за діапазон), arrival/departure port события.

Payment Automation: Letter of Credit on-chain

Традиційний Letter of Credit (LC) — один з найскладніших фінансових інструментів, з затримками 7–30 днів на обробку документів. On-chain автоматизація:

contract LetterOfCredit {
    enum LCStatus { Issued, DocumentsPresented, Verified, PaymentReleased, Rejected }

    struct LC {
        address applicant;       // покупець
        address beneficiary;     // продавець
        address issuingBank;
        uint256 amount;
        address paymentToken;    // stablecoin (USDC/USDT)
        bytes32 shipmentId;      // привʼязка до конкретного вантажу
        bytes32[] requiredDocHashes;  // хеші необхідних документів
        uint64 expiryDate;
        LCStatus status;
    }

    function presentDocuments(
        bytes32 lcId,
        bytes32[] calldata documentHashes,
        bytes32 shipmentId
    ) external {
        LC storage lc = lcs[lcId];
        require(msg.sender == lc.beneficiary, "Not beneficiary");
        require(block.timestamp <= lc.expiryDate, "LC expired");

        // Верификація що вантаж доставлен (on-chain milestone)
        require(
            shipmentRegistry.getMilestoneStatus(shipmentId, MilestoneType.Delivered),
            "Delivery not confirmed"
        );

        // Верификація хешів документів
        for (uint i = 0; i < lc.requiredDocHashes.length; i++) {
            require(
                isDocumentPresented(documentHashes, lc.requiredDocHashes[i]),
                "Missing required document"
            );
        }

        lc.status = LCStatus.DocumentsPresented;
        emit DocumentsPresented(lcId, msg.sender);
    }

    function releasePayment(bytes32 lcId) external onlyRole(BANK_ROLE) {
        LC storage lc = lcs[lcId];
        require(lc.status == LCStatus.DocumentsPresented, "Documents not presented");

        lc.status = LCStatus.PaymentReleased;
        IERC20(lc.paymentToken).safeTransfer(lc.beneficiary, lc.amount);
        emit PaymentReleased(lcId, lc.beneficiary, lc.amount);
    }
}

Таможенна інтеграція

Таможенні органи в різних країнах починають приймати blockchain-верифіковані дані. Ключові стандарти:

WCO Data Model — стандарт World Customs Organization для таможенних даних. Дані в блокчейні повинні відповідати цій моделі для можливої інтеграції з ACS (Automated Customs Systems).

Single Window системи — багато країн мають або будують national single window. Інтеграція через API з зберіганням хешів on-chain.

Реалістична інтеграція з таможнею: система записує таможенні документи в IPFS, хеші — в блокчейн, таможенний брокер з акредитованим ключем підписує "таможня пройдена" milestone. Прямо взаємодія державних систем з blockchain — можливо в Сингапурі, ОАЕ, Швейцарії, у інших юрисдикціях — складно.

Вибір сети та інфраструктура

Для consortium (обмежене число учасників): Polygon CDK або Arbitrum Orbit — приватний L2 з EVM сумісністю. Низький gas, контроль над валідаторами, можливість налаштувати permissioned доступ.

Для відкритої платформи: Polygon PoS або Base — доступність для будь-яких учасників, хороша ліквідність для stablecoin платежів, низькі комісії.

Не рекомендуємо: Hyperledger Fabric — без strong enterprise причини. EVM інфраструктура значно зріліша для інтеграції з DeFi платіжними системами.

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

Фаза Вміст Тривалість
Business mapping Учасники, документи, milestone события, інтеграції 2–3 тижні
Architecture Data model, on/off-chain розділення, сеть 2–3 тижні
Core contracts ShipmentRegistry, milestones, roles 4–5 тижнів
Payment layer Escrow, LC автоматизація 3–4 тижні
IoT pipeline Gateway, oracle, aggregation 3–5 тижнів
Participant interfaces Web app / mobile для кожної ролі 5–7 тижнів
ERP integration TMS/WMS коннектори 3–4 тижні
Pilot with carriers Тестування на реальних рейсах 4–8 тижнів

Основний технічний ризик — IoT надійність на судні (покриття, батарея, суворі умови). Основний операційний ризик — онбординг учасників: убедити фрахтового брокера в Гонконгу та таможенного брокера в Роттердамі працювати з однією системою.