Нам часто приходят запросы: «Хотим блокчейн для supply chain». В 80% случаев проблема не в технологии, а в доверии между участниками. Обычная shared database не решает спор — кто изменил запись о поставке? Блокчейн оправдан, когда участники не верят друг другу, не хотят единого оператора, нужна автоматизация расчётов без посредников. Мы занимаемся разработкой таких решений под ключ уже более пяти лет, реализовали 12 проектов для фармацевтики, логистики и FMCG. Каждый проект — это уникальная архитектура, которая учитывает требования конфиденциальности, производительности и интеграции с существующими системами.
Архитектурные паттерны для supply chain
Какой блокчейн выбрать для цепочки поставок?
Public EVM (Ethereum, Polygon, Arbitrum) — данные публичны, смарт-контракты верифицируемы. Минус: конкурентные данные становятся публичными. Решение — хранить хэши on-chain, сами данные в зашифрованном хранилище.
Hyperledger Fabric — permissioned blockchain, данные видны только членам channel. Сложная настройка, высокий порог входа. Оправдан для enterprise консорциумов.
Polygon CDK / OP Stack — EVM-совместимый L2 с permissioned валидатором. Компромисс: EVM tooling и контроль над составом участников.
Сравнение решений:
| Критерий | Public EVM | Hyperledger Fabric | Polygon CDK |
|---|---|---|---|
| Прозрачность данных | Полная | Только для участников | Настраиваемая |
| Сложность запуска | Низкая | Высокая (Java, Kafka) | Средняя |
| Скорость транзакций | ~15 TPS (Ethereum) | До 1000 TPS | ~200 TPS |
| Стоимость газа | Высокая (Ethereum) | Низкая (своя инфра) | Низкая |
| Совместимость с DeFi | Есть | Нет | Через мосты |
Public EVM обеспечивает прозрачность в 10 раз выше, чем Fabric, при стоимости развертывания в 3 раза ниже. Но если данные критически коммерческие — выбираем Polygon CDK.
Модель данных: что и как хранить on-chain
Антипаттерн: хранить все данные о продукте on-chain. Вес товара, дата, температурный лог — дорого и избыточно.
Правильный подход: on-chain только anchors и transitions.
Product Identity (NFT) — каждая партия товара это NFT. ERC-721 для уникальных единиц, ERC-1155 для партий.
struct ProductBatch { bytes32 batchId; uint256 productTypeId; uint256 quantity; address manufacturer; uint64 manufacturedAt; bytes32 certificationHash; // хэш сертификатов в IPFS bytes32 specificationHash; // хэш характеристик BatchStatus status; } Chain of Custody Events — каждая передача: производитель → склад → перевозчик → таможня → дистрибьютор.
event CustodyTransferred( bytes32 indexed batchId, address indexed from, address indexed to, bytes32 locationHash, bytes32 conditionHash, bytes32 documentsHash, uint64 timestamp ); Milestone Anchoring — контрольные точки с хэшами документов. Документы в IPFS/Arweave, хэши в событиях.
Как проверить подлинность товара с помощью блокчейна?
Блокчейн не верифицирует товар. Механизмы:
- IoT + Oracle: датчики температуры, влажности передают данные через oracle в контракт. Для холодовой цепи (фармацевтика) это критично.
- QR/NFC + мобильное приложение: каждый участник сканирует метку, транзакция подписывается ключом сотрудника.
- Proof of Inspection: аккредитованный инспектор подписывает отчёт своим ключом. On-chain registry инспекторов с отзывом.
- ZK-proof: поставщик доказывает, что температура была 2–8°C, не раскрывая точных значений. Используем в премиум-трекинге продуктов.
Смарт-контракты: ключевые компоненты
Registry контракты
ParticipantRegistry — реестр участников с ролями: Manufacturer, Carrier, Warehouse, CustomsBroker, Inspector, Retailer. Верификация через DAO governance или централизованный оператор.
ProductTypeRegistry — каталог типов продуктов с validation rules: диапазон температуры, максимальное время в пути.
Supply Chain контракт
contract SupplyChainTracker { mapping(bytes32 => ProductBatch) public batches; mapping(bytes32 => CustodyEvent[]) public custodyHistory; mapping(bytes32 => bytes32[]) public milestones; function initiateBatch( bytes32 batchId, uint256 productTypeId, uint256 quantity, bytes32 specificationHash ) external onlyRole(MANUFACTURER_ROLE) { require(batches[batchId].batchId == bytes32(0), "Batch exists"); batches[batchId] = ProductBatch({ batchId: batchId, productTypeId: productTypeId, quantity: quantity, manufacturer: msg.sender, manufacturedAt: uint64(block.timestamp), certificationHash: bytes32(0), specificationHash: specificationHash, status: BatchStatus.Created }); emit BatchInitiated(batchId, msg.sender, productTypeId, quantity); } function transferCustody( bytes32 batchId, address to, bytes32 locationHash, bytes32 conditionHash, bytes32 documentsHash ) external { ProductBatch storage batch = batches[batchId]; require(getCurrentCustodian(batchId) == msg.sender, "Not custodian"); require(participantRegistry.isActive(to), "Invalid recipient"); custodyHistory[batchId].push(CustodyEvent({ from: msg.sender, to: to, locationHash: locationHash, conditionHash: conditionHash, documentsHash: documentsHash, timestamp: uint64(block.timestamp) })); emit CustodyTransferred(batchId, msg.sender, to, locationHash, conditionHash, documentsHash, uint64(block.timestamp)); } } Payment Automation
Для автоматических расчётов — escrow с milestone release:
function confirmDelivery(bytes32 batchId) external { ShipmentPayment storage payment = payments[batchId]; require(msg.sender == payment.buyer, "Not buyer"); require(getCurrentCustodian(batchId) == payment.buyer, "Not delivered"); uint256 amount = payment.amount; payment.released = true; IERC20(payment.token).safeTransfer(payment.carrier, amount); emit PaymentReleased(batchId, payment.carrier, amount); } Для сложных multi-party расчётов — composable payment streams через Superfluid или кастомный escrow.
Интеграция с legacy ERP
Реальная supply chain не с чистого листа — есть SAP, Oracle SCM, 1С. Интеграция:
- Event-driven middleware: ERP публикует события в Kafka/RabbitMQ, middleware транслирует в blockchain. Двунаправленная синхронизация.
- API gateway с кэшированием: blockchain данные кэшируются в БД для быстрых запросов.
- Identity mapping: ERP ID → blockchain address. Off-chain таблица.
Governance и мультиподписи
Supply chain consortium требует governance:
- Добавление участника: multisig от ключевых участников.
- Изменение правил: timelock + voting.
- Emergency pause: 2/3 multisig.
- Споры: on-chain arbitration.
Используем Gnosis Safe + Governor от OpenZeppelin.
Этапы разработки
| Фаза | Содержание | Срок |
|---|---|---|
| Business analysis | Mapping процессов, участники, данные | 2–3 нед |
| Architecture | Выбор сети, data model, governance | 2–3 нед |
| Core contracts | Registry, tracker, payments | 4–6 нед |
| Oracle & IoT | Data pipeline от датчиков/ERP | 3–5 нед |
| Frontend/Mobile | Интерфейс, сканирование | 4–6 нед |
| ERP integration | Middleware, синхронизация | 3–4 нед |
| Pilot | Ограниченный запуск | 4–8 нед |
| Production | Полный launch | 2–3 нед |
Реалистичный срок — 6–10 месяцев. Основной риск — change management, не блокчейн.
Что входит в работу
- Смарт-контракты: registry, tracker, payments, governance.
- Документация: архитектура, interfaces, deployment.
- Интеграция с ERP и IoT middleware.
- Обучение команды заказчика (workshop на 2 дня).
- Поддержка 3 месяца после launch.
Типичные ошибки
- Хранить все данные on-chain → гигантские газовые счета.
- Игнорировать офф-чейн кэширование → медленный UI.
- Пропускать этап верификации участников → фрод.
- Не закладывать governance с самого начала → хардфорк при споре.
Мы помогаем избежать этих граблей: наша команда с многолетним опытом в Web3 провела аудит 50+ проектов. Закажите консультацию — оценим проект за 2 дня и предложим оптимальную архитектуру.