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

Більшість клієнтів приходять до нас з однією і тією ж проблемою: їхні системи трасування поставок — це просто база даних з веб-інтерфейсом. Проблема не в технології, а в архітектурі довіри: дані записує одна сторона, інші змушені їй вірити. Коли в ланцюзі беруть участь п'ять сторін з трьох країн — це непрацююча модель. Саме тут блокчейн вирішує реальну задачу: забезпечення незмінності записів і публічної верифікованості без центрального арбітра. Ми займаємось трасуванням поставок на блокчейні понад 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 кроків

1. Аналіз бізнес-процесів — виявляємо ключові події, ролі учасників та точки введення даних.
2. Проектування моделі on/off-chain — визначаємо, що зберігати в блокчейні, що в IPFS.
3. Розробка смарт-контрактів — реалізуємо трекінг, рольову систему та управління доступом.
4. Інтеграція з IoT та ERP — налаштовуємо gateway, oracle та API для ERP/WMS.
5. Пілот та впровадження — тестуємо на реальних даних, навчаємо учасників.

Вибір мережі

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

Найбільш трудомісткий етап — інтеграція з legacy ERP-системами учасників ланцюга, а не розробка блокчейн-частини.

Що входить у роботу

Смарт-контракти: трекінг подій, рольова система, управління правами доступу. Backend: API для інтеграції з ERP/WMS, oracle service для обробки IoT-даних. Dashboard: панель адміністратора та consumer-facing модуль верифікації продукту. Документація: архітектурна схема, специфікація API, інструкція з розгортання. Навчання: тренінг для ключових учасників ланцюга. Підтримка: гарантійне обслуговування та опціональне продовження.

Зв'яжіться з нами для оцінки вашого проєкту. Замовте розробку трасування поставок під ключ.