Більшість клієнтів приходять до нас з однією і тією ж проблемою: їхні системи трасування поставок — це просто база даних з веб-інтерфейсом. Проблема не в технології, а в архітектурі довіри: дані записує одна сторона, інші змушені їй вірити. Коли в ланцюзі беруть участь п'ять сторін з трьох країн — це непрацююча модель. Саме тут блокчейн вирішує реальну задачу: забезпечення незмінності записів і публічної верифікованості без центрального арбітра. Ми займаємось трасуванням поставок на блокчейні понад 5 років і реалізували 15+ проєктів. Для прикладу, запис однієї трекінг-події на Polygon коштує приблизно $0.005, що у 1000 разів дешевше ніж на Ethereum mainnet ($5–10). Газ для запису на приватній мережі Hyperledger Fabric — частки цента, наприклад $0.0001 за транзакцію. Економія на транзакціях сягає 99% при використанні L2 порівняно з Ethereum. Hyperledger Fabric фіналізує транзакції за <1 секунди, що у 100 разів швидше ніж публічний Ethereum (15 секунд).
Як блокчейн вирішує проблему довіри в ланцюгу поставок?
Вибір мережі — перший крок. Для корпоративних supply chains з відомим колом учасників краще підходить permissioned мережа Hyperledger Fabric або Besu в IBFT-режимі. Публічний блокчейн через L2 (Polygon, Base) виправданий, коли важлива публічна верифікованість, наприклад, для QR-сканування споживачами.
Що зберігати on-chain, а що off-chain?
Головна помилка початківців — намагатися зберігати все on-chain. Результат: дорого, повільно, надлишково. Правило: on-chain зберігаються лише хеші документів, ідентифікатори акторів (адреси), часові мітки, статуси (enum) та merkle root партій даних. Off-chain зберігаються фото, PDF-сертифікати, детальні sensor readings, великі JSON-об'єкти. Посилання на сховище (IPFS CID) та хеш вмісту записуються on-chain. IPFS забезпечує децентралізоване зберігання з верифікацією за хешем. Чому саме IPFS, а не хмара? Хмарні сховища прив'язані до одного провайдера — єдина точка відмови. IPFS децентралізований: дані дублюються на безліч вузлів, доступні за хешем, і цілісність перевіряється криптографічно. Для supply chain це гарантує, що жоден учасник не зможе підмінити історію продукту заднім числом.
// Подія трекінгу: легка on-chain, деталі в IPFS
struct TrackingEvent {
bytes32 batchId; // ID партії/лота
bytes32 dataHash; // keccak256 від повного JSON події
string ipfsCid; // CID повних даних в IPFS
address actor; // хто записує (верифікований учасник)
EventType eventType; // PRODUCED, SHIPPED, RECEIVED, INSPECTED, SOLD
uint256 timestamp;
bytes32 locationHash; // хеш від GPS координат (для приватності)
}
enum EventType { PRODUCED, SHIPPED, RECEIVED, INSPECTED, CERTIFIED, SOLD }
mapping(bytes32 => TrackingEvent[]) public batchHistory;
mapping(bytes32 => bool) public authorizedActors;
event BatchEvent(
bytes32 indexed batchId,
EventType indexed eventType,
address indexed actor,
bytes32 dataHash,
string ipfsCid
);
function recordEvent(
bytes32 batchId,
bytes32 dataHash,
string calldata ipfsCid,
EventType eventType
) external {
require(authorizedActors[keccak256(abi.encode(msg.sender, eventType))],
"Not authorized for this event type");
TrackingEvent memory evt = TrackingEvent({
batchId: batchId,
dataHash: dataHash,
ipfsCid: ipfsCid,
actor: msg.sender,
eventType: eventType,
timestamp: block.timestamp,
locationHash: bytes32(0)
});
batchHistory[batchId].push(evt);
emit BatchEvent(batchId, eventType, msg.sender, dataHash, ipfsCid);
}
Управління доступом учасників через DID
У supply chain є кілька типів акторів: виробник, логіст, митниця, ритейлер, інспектор. Простий Ownable не підходить — потрібна рольова система з делегуванням. W3C DID Core — стандарт для децентралізованої ідентичності. Кожен учасник має DID, прив'язаний до своїх смарт-контрактних адрес. Верифікація учасника (KYB) відбувається off-chain через акредитованих верифікаторів, які видають Verifiable Credentials (VC).
// Верифікація VC при реєстрації учасника
import { Resolver } from 'did-resolver'
import { getResolver as ethrResolver } from 'ethr-did-resolver'
import { verifyCredential } from 'did-jwt-vc'
async function verifyParticipantCredential(
vcJwt: string,
participantAddress: string
): Promise<boolean> {
const resolver = new Resolver({
...ethrResolver({ infuraProjectId: process.env.INFURA_ID })
})
const result = await verifyCredential(vcJwt, resolver)
// Перевіряємо, що VC видано акредитованим верифікатором
const trustedIssuers = await getTrustedIssuers() // з смарт-контракту
if (!trustedIssuers.includes(result.issuer)) {
return false
}
// Перевіряємо, що VC відноситься до даної адреси
return result.verifiableCredential.credentialSubject.ethereumAddress
.toLowerCase() === participantAddress.toLowerCase()
}
Role-based access з часовими вікнами
Учасник може мати право записувати події лише в певний період (наприклад, час у дорозі вантажу):
struct ActorPermission {
bytes32 role; // PRODUCER_ROLE, SHIPPER_ROLE, etc.
uint256 validFrom;
uint256 validUntil;
bytes32[] allowedBatches; // порожній масив = всі партії
}
mapping(address => ActorPermission[]) public permissions;
function isAuthorized(
address actor,
bytes32 role,
bytes32 batchId
) public view returns (bool) {
ActorPermission[] storage perms = permissions[actor];
for (uint i = 0; i < perms.length; i++) {
if (perms[i].role == role &&
perms[i].validFrom <= block.timestamp &&
perms[i].validUntil >= block.timestamp) {
if (perms[i].allowedBatches.length == 0) return true;
for (uint j = 0; j < perms[i].allowedBatches.length; j++) {
if (perms[i].allowedBatches[j] == batchId) return true;
}
}
}
return false;
}
Як інтегрувати IoT з блокчейном?
Sensor data повинен потрапляти on-chain автоматично та незмінно. Це архітектурна проблема: IoT пристрій не може підписувати Ethereum транзакції безпосередньо (немає RAM, немає battery для криптографії EVM-класу). Використовується паттерн Gateway + Oracle: Edge-шлюз агрегує дані сенсорів, підписує їх, публікує в IPFS, а Oracle-сервіс відправляє транзакцію в смарт-контракт.
# Oracle service: верифікація та запис sensor події
from web3 import Web3
from eth_account import Account
import ipfshttpclient
async def process_sensor_reading(gateway_id: str, payload: dict, signature: str):
# 1. Верифікуємо підпис gateway
message = encode_defunct(text=json.dumps(payload, sort_keys=True))
recovered = w3.eth.account.recover_message(message, signature=signature)
gateway_address = await get_registered_gateway(gateway_id)
if recovered.lower() != gateway_address.lower():
raise ValueError("Invalid gateway signature")
# 2. Публікуємо в IPFS
async with ipfshttpclient.connect() as ipfs:
cid = ipfs.add_json(payload)
# 3. Записуємо on-chain
data_hash = Web3.keccak(text=json.dumps(payload, sort_keys=True))
tx = tracking_contract.functions.recordSensorEvent(
payload['batch_id'].encode(),
data_hash,
cid,
EventType.SENSOR_READING
).build_transaction({
'from': oracle_account.address,
'nonce': w3.eth.get_transaction_count(oracle_account.address),
'maxFeePerGas': await get_gas_price(),
})
signed = oracle_account.sign_transaction(tx)
tx_hash = w3.eth.send_raw_transaction(signed.rawTransaction)
return tx_hash.hex()
Для високих вимог до довіри застосовують HSM (Hardware Security Module) безпосередньо в пристрої. Microchip ATECC608 — недорогий чіп з ECC-ключовою парою, яку неможливо витягти. Пристрій підписує дані ключем, фізично захищеним від компрометації.
Приклад: фармацевтичний ланцюг поставок
Розглянемо фармацевтичну supply chain (FDA DSCSA compliance вимагає електронний трекінг). Основні події:
- Подія 1: Виробництво — запис ID серії, дати, складу, хеша CoA. Генерується QR-код з batchId.
- Подія 2: Відвантаження — логіст сканує QR, записує carrier ID, tracking number, температурний діапазон.
- Подія 3: Митне очищення — запис декларації, статусу, інспектора ID.
- Подія 4: Отримання — дата, фізичний огляд, розбіжність. Верифікація хеша.
- Подія 5: Продаж споживачеві — споживач сканує QR і бачить повну історію.
Як ми це робимо: 5 кроків
- Аналіз бізнес-процесів — виявляємо ключові події, ролі учасників та точки введення даних.
- Проектування моделі on/off-chain — визначаємо, що зберігати в блокчейні, що в IPFS.
- Розробка смарт-контрактів — реалізуємо трекінг, рольову систему та управління доступом.
- Інтеграція з IoT та ERP — налаштовуємо gateway, oracle та API для ERP/WMS.
- Пілот та впровадження — тестуємо на реальних даних, навчаємо учасників.
Вибір мережі
| Параметр | Публічний L2 (Polygon/Base) | Hyperledger Fabric | Besu (IBFT) |
|---|---|---|---|
| Публічна верифікованість | Так | Ні | Ні |
| Вартість запису | ~$0.001–$0.01/tx | Майже 0 | Майже 0 |
| Швидкість фіналізації | 2–5 сек | < 1 сек | 2–5 сек |
| Контроль доступу | Smart contracts | Native channel/MSP | Smart contracts |
| Регуляторні вимоги | Публічний блокчейн | Приватна мережа | Приватна мережа |
Етапи розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Design | 2–3 тиж | Аналіз бізнес-процесів, модель даних on/off-chain |
| Smart contracts | 3–4 тиж | Контракти трекінгу, рольова система, тести |
| Oracle + IoT | 3–4 тиж | Gateway integration, oracle service, IPFS pipeline |
| API & Dashboard | 3–4 тиж | REST/GraphQL API, admin panel, consumer верифікатор |
| Integration & Pilot | 2–4 тиж | Інтеграція з ERP/WMS, пілот |
Найбільш трудомісткий етап — інтеграція з legacy ERP-системами учасників ланцюга, а не розробка блокчейн-частини.
Що входить у роботу
Смарт-контракти: трекінг подій, рольова система, управління правами доступу. Backend: API для інтеграції з ERP/WMS, oracle service для обробки IoT-даних. Dashboard: панель адміністратора та consumer-facing модуль верифікації продукту. Документація: архітектурна схема, специфікація API, інструкція з розгортання. Навчання: тренінг для ключових учасників ланцюга. Підтримка: гарантійне обслуговування та опціональне продовження.
Зв'яжіться з нами для оцінки вашого проєкту. Замовте розробку трасування поставок під ключ.