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

Большинство клиентов приходят к нам с одной и той же проблемой: их системы трассировки поставок — это просто база данных с веб-интерфейсом. Проблема не в технологии, а в архитектуре доверия: данные записывает одна сторона, другие вынуждены ей верить. Когда в цепочке участвуют пять сторон из трёх стран — это неработающая модель. Именно здесь блокчейн решает реальную задачу: обеспечение неизменности записей и публичной верифицируемости без центрального арбитра. Наша команда имеет многолетний опыт в блокчейн-разработке и реализовала более 15 проектов в сфере supply chain. Для примера, запись одного трекинг-события на Polygon обходится примерно в $0.005, что несопоставимо дешевле $5–10 на Ethereum mainnet. По стоимости транзакций Polygon выигрывает у Ethereum более чем в 1000 раз, а по скорости финализации — в десятки раз. Газ для записи на приватной сети Hyperledger Fabric — доли цента, например $0.0001 за транзакцию.

Как блокчейн решает проблему доверия в цепочке поставок?

Выбор сети — первый шаг. Для корпоративных 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 обеспечивает децентрализованное хранение с верификацией по хешу.

// Событие трекинга: лёгкое 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, инструкция по развертыванию. Обучение: тренинг для ключевых участников цепочки. Поддержка: гарантийное обслуживание и опциональное продление.

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