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

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

Системы отслеживания грузов существуют десятилетиями — 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, certificates)
• Переходы custody с временными метками
• Milestone события с координатами (хэш) и подписями участников
• Payment conditions и их исполнение

Off-chain (IPFS/Arweave):

• Сами документы (PDF, XML)
• Detailed sensor data logs
• Фотографии груза

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 shipper-у, который может его передавать
        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 events.

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 системы — многие страны имеют or строят national single window. Интеграция через API с хранением хэшей on-chain.

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

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

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

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

Не рекомендуем: Hyperledger Fabric — если нет strong enterprise причины. EVM инфраструктура значительно зрелее для интеграции с DeFi платёжными системами.

Этапы разработки

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