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

Большинство клиентов приходят к нам с одной и той же проблемой: их системы трассировки поставок — это просто база данных с веб-интерфейсом. Проблема не в технологии, а в архитектуре доверия: данные записывает одна сторона, другие вынуждены ей верить. Когда в цепочке участвуют пять сторон из трёх стран — это неработающая модель. Именно здесь блокчейн решает реальную задачу: обеспечение неизменности записей и публичной верифицируемости без центрального арбитра. Наша команда имеет многолетний опыт в блокчейн-разработке и реализовала более 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, инструкция по развертыванию. Обучение: тренинг для ключевых участников цепочки. Поддержка: гарантийное обслуживание и опциональное продление.

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