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