Розробка системи відстеження вантажів на блокчейні
Ми — команда блокчейн-інженерів з досвідом у логістиці. За цей час реалізували 15+ проєктів з відстеження вантажів на Ethereum, Polygon та BNB Chain. Системи відстеження вантажів існують десятиліттями — TMS, WMS, EDI. Проблема не у відсутності систем, а в тому, що вони не розмовляють одна з одною. Відправник у Китаї використовує одну систему, фрахтовий брокер — іншу, митниця — третю, кінцевий отримувач бачить лише те, що йому сповістив перевізник. Блокчейн тут — не про технологію, а про нейтральну платформу, якій довіряють усі сторони, тому що ніхто з них її не контролює.
Що таке система відстеження вантажів на блокчейні?
Це єдиний простір, де кожен учасник бачить актуальний статус вантажу в реальному часі. Усі дії — створення заявки, завантаження на борт, проходження митниці, видача вантажу — фіксуються як транзакції. Ніхто не може їх підробити або видалити. Блокчейн замінює шквал email-листування та дзвінків одним джерелом правди.
Чому блокчейн кращий за традиційні TMS?
Традиційні TMS працюють в ізоляції. Зміна власника вантажу через електронний Bill of Lading займає в середньому 5–7 днів через банківські перевірки та паперовий обіг. На блокчейні зі смарт-контрактом передача володіння відбувається за 10 хвилин. Документообіг прискорюється на 80%, а кількість спірних ситуацій знижується на 90%. Це не теорія — ми перевірили на пілоті з одним із перевізників.
Що саме відстежується: учасники та документи
Які ролі та події критичні? — розробка системи відстеження
Типове міжнародне перевезення задіює: Shipper (вантажовідправник), Freight Forwarder, Carrier, Port/Terminal Operator, Customs Broker, Consignee, Bank/Financier, Inspector/Surveyor. Кожен учасник має свою систему — on-chain система дає єдиний source of truth.
Bill of Lading (B/L) — центральний документ у морських перевезеннях. Це одночасно розписка перевізника, договір перевезення та товаророзпорядчий документ. Токенізація B/L регулюється стандартами BIMCO та DCSA. Події життєвого циклу вантажу:
Booking → Cargo Received at Origin Port → Loaded on Vessel → Departed → In Transit → Arrived at Destination Port → Customs Cleared → Available for Pickup → Delivered
Архітектура: що on-chain, що off-chain
| Тип даних | Приклади | Де зберігається |
|---|---|---|
| Унікальні ідентифікатори, хеші документів, переходи custody, milestone-події | shipment ID, хеш B/L, підписи | On-chain (EVM) |
| Повні документи, логи сенсорів, фотографії | PDF, XML, CSV | IPFS / Arweave |
| Індекси для швидких запитів, аналітика | Статус всіх shipments, звіти | Традиційна БД (PostgreSQL) |
Shipment NFT: чому вантаж як токен?
Вантаж як NFT — правильна абстракція для унікальних shipments. Передача NFT = передача права власності. Приклад контракту:
contract ShipmentRegistry is ERC721, AccessControl {
struct Shipment {
bytes32 shipmentId;
bytes32 bookingReference;
ShipmentType shipmentType; // FCL, LCL, Air, Rail, Road
address shipper;
address consignee;
bytes32 originPortHash;
bytes32 destinationPortHash;
bytes32 blHash;
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) {
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 події?
Критичні події вимагають підтвердження кількох сторін. Завантаження на судно має бути підтверджено перевізником та терміналом:
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 без перевантаження блокчейну?
Для контейнерів критичні: GPS позиція, температура (reefer), вібрація, тамперні сенсори. Дані з IoT пишуться не напряму — схема агрегації:
IoT Device → Satellite/Cellular Gateway → Data Aggregation Server → Oracle → Smart Contract (aggregated alerts + checkpoints)
Oraкла записує позицію кожні 6 годин та аномалії (температура поза діапазоном, arrival/departure).
Приклад агрегації даних з сенсорів
В одному контейнері може бути до 6 сенсорів: GPS, датчик температури, вібрації, відкриття дверей, вологості та освітленості. Кожен пристрій надсилає дані раз на 2–5 хвилин. Щоб не засмічувати блокчейн, ми агрегуємо їх на сервері та записуємо лише критичні події: відхилення температури більш ніж на 2°C, удар понад 10g, відкриття дверей поза заданим портом.Як автоматизувати 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
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");
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 та Single Window системи. Реалістична інтеграція: митні документи в IPFS, хеші в блокчейн, брокер підписує milestone "митниця пройдена". Пряма взаємодія з держорганами можлива в Сінгапурі, ОАЕ, Швейцарії.
Яку мережу обрати і чому?
| Параметр | Polygon CDK / Arbitrum Orbit (приватний L2) | Polygon PoS / Base (публічна мережа) | Hyperledger Fabric |
|---|---|---|---|
| Контроль доступу | Повний (permissioned) | Відкритий | Permissioned |
| Gas | Низький, оплачується вами | Низький | Безкоштовно (свої валідатори) |
| Екосистема | EVM-сумісні інструменти | EVM + DeFi | Немає DeFi, своя інфра |
| Рекомендація | Для консорціуму з обмеженим колом | Для відкритої платформи з платежами | Тільки якщо сувора enterprise-вимога |
Ми не рекомендуємо Hyperledger Fabric без strong enterprise причини — EVM інфраструктура значно зріліша.
Етапи розробки
| Фаза | Зміст | Термін |
|---|---|---|
| Business mapping | Учасники, документи, milestone-події, інтеграції | 2–3 тиж |
| Architecture | Data model, on/off-chain розділення, вибір мережі | 2–3 тиж |
| Core contracts | ShipmentRegistry, milestones, ролі | 4–5 тиж |
| Payment layer | Escrow, LC автоматизація | 3–4 тиж |
| IoT pipeline | Gateway, oracle, агрегація | 3–5 тиж |
| Participant interfaces | Web-/mobile-додатки для кожної ролі | 5–7 тиж |
| ERP integration | TMS/WMS конектори | 3–4 тиж |
| Pilot with carriers | Тестування на реальних рейсах | 4–8 тиж |
Основний технічний ризик — IoT надійність на судні (покриття, батарея). Основний операційний — онбординг учасників.
Що входить в роботу
У вартість під ключ входить: аналіз бізнес-процесів, проектування смарт-контрактів, створення дашборду для кожної ролі, інтеграція з IoT-провайдерами, розгортання в тестовій мережі, навчання команди, 3 місяці гарантійної підтримки. Документація та доступи до вихідників.
Отримайте консультацію інженера — оцінимо ваш проект за 2 дні. Зв'яжіться з нами для оцінки вашого проекту. Підберемо архітектуру під ваш масштаб.