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

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

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