Розробка системи відслідковування вантажів на блокчейні
Системи відслідковування вантажів існують десятиліттями — 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 надійність на судні (покриття, батарея, суворі умови). Основний операційний ризик — онбординг учасників: убедити фрахтового брокера в Гонконгу та таможенного брокера в Роттердамі працювати з однією системою.







