Разработка блокчейн-решения для supply chain

Разработка блокчейн-решения для supply chain

Прежде чем проектировать систему, нужно честно ответить на вопрос: зачем здесь блокчейн? В большинстве корпоративных supply chain проектов ответ оказывается неубедительным — "чтобы все участники видели одну версию данных" решается обычной shared database с правильными правами доступа. Блокчейн оправдан когда: участники не доверяют друг другу и не доверяют единому оператору базы данных, нужна неизменяемость записей с верифицируемой историей, смарт-контракты автоматизируют расчёты между сторонами без посредника. Если эти условия выполнены — идём дальше.

Архитектурные паттерны для supply chain

Public vs Private blockchain: реальный trade-off

Public EVM (Ethereum/Polygon/Arbitrum) — данные публичны, смарт-контракты верифицируемы любым участником, не нужно договариваться о консенсусе. Минус: конкурентные данные (себестоимость, объёмы, поставщики) становятся публичными. Решение — хранить хэши данных on-chain, сами данные в зашифрованном хранилище.

Hyperledger Fabric — permissioned blockchain, данные видны только членам channel. Сложная настройка, требует выделенной инфраструктуры, высокий порог входа. Оправдан для enterprise консорциумов с чёткой governance моделью.

Polygon CDK / OP Stack (private instance) — EVM-compatible L2 с permissioned валидатором. Компромисс: EVM tooling и смарт-контракты, но контроль над составом участников. Данные можно публиковать в public DA layer (Ethereum, Avail) для верифицируемости без публичности содержимого.

Для большинства реальных supply chain проектов — public EVM с шифрованием чувствительных данных или Polygon CDK. Hyperledger Fabric — если уже есть enterprise Java команда и нет планов интегрироваться с DeFi.

Модель данных: что и как хранить on-chain

Антипаттерн: хранить все данные о продукте on-chain. Вес товара, дата производства, температурный лог из 10,000 записей — всё это дорого и избыточно.

Правильный подход: 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 содержит: from, to, timestamp, location hash, condition hash, documents hash.

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 — датчики (температура, влажность, GPS) передают данные через IoT gateway в oracle. Oracle агрегирует и записывает в контракт. Для холодовой цепи (фармацевтика, продукты питания) это критично.

QR/NFC + мобильное приложение — каждый участник цепочки сканирует метку при приёмке и передаче. Транзакция подписывается ключом сотрудника. Аудит-след создаётся от каждого участника.

Proof of Inspection — аккредитованный инспектор (физическое лицо) подписывает inspection report своим кастодиальным ключом. On-chain registry аккредитованных инспекторов с revocation.

ZK-proof для sensitive данных — поставщик хочет доказать что товар соответствует спецификации (температурный режим соблюдался), не раскрывая конкретные значения. ZK-proof позволяет сказать "температура всегда была в диапазоне 2–8°C" без публикации точных значений. Для supply chain применяется в premium food tracking и фармацевтике.

Смарт-контракты: ключевые компоненты

Registry контракты

ParticipantRegistry — on-chain реестр участников supply chain с ролями: 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 расчётов (импортёр платит таможенному брокеру, перевозчику, страховщику по разным milestone) — composable payment streams через Superfluid или кастомный escrow с multiple payees.

Интеграция с legacy ERP системами

Реальная supply chain не начинается с чистого листа — есть SAP, Oracle SCM, 1С. Интеграция:

Event-driven middleware — ERP публикует события (товар принят, накладная закрыта) в message bus (Kafka, RabbitMQ). Middleware транслирует в blockchain транзакции. Bidirectional: blockchain события уходят обратно в ERP.

API gateway с кэшированием — большинство ERP-запросов читают данные, а не пишут. Кэшировать blockchain данные в традиционную БД для быстрых запросов, синхронизировать событиями.

Identity mapping — ERP использует внутренние ID, blockchain использует адреса и хэши. Нужна таблица маппинга (off-chain, в традиционной БД) для синхронизации.

Governance и мультиподписи

Supply chain consortium требует governance:

• Добавление нового участника: multisig от существующих ключевых участников
• Изменение правил верификации: timelock + voting
• Emergency pause: 2/3 мультиподпись от core participants
• Разрешение споров: on-chain arbitration или off-chain арбитраж с on-chain enforcement

Gnosis Safe как базовый multisig + Governor contract от OpenZeppelin для голосования — стандартная комбинация.

Этапы разработки

Реалистичный срок от анализа до production — 6–10 месяцев. Основной риск не в блокчейне — в change management: убедить всех участников цепочки использовать новую систему.