Сертификаты происхождения подделываются. Данные о цепочке поставок хранятся в разрозненных ERP-системах разных участников и не верифицируемы третьими сторонами. Потребитель не может проверить, что «органический продукт» действительно органический. Мы решаем эту задачу с помощью архитектуры на блокчейне — разрабатываем систему под ключ, от проектирования до деплоя.
Блокчейн сам по себе не решает проблему достоверности данных — данные в смарт-контракт вносит человек. Если человек вносит неверные данные, блокчейн лишь гарантирует их неизменность, но не достоверность. Правильная архитектура системы сертификации — это понимание, где blockchain реально помогает, а где нет.
Какую проблему решает блокчейн в сертификации?
Блокчейн обеспечивает прозрачность и неизменность записей. В традиционной системе цепочка поставок состоит из множества участников, каждый ведёт свою ERP. При аудите или жалобе потребителя данные сверяются вручную — это недели и возможность мошенничества. Смарт-контракты автоматически фиксируют каждое событие: выпуск партии, перемещение, проверку качества, отзыв сертификата. Любой участник (в том числе потребитель) может независимо проверить историю. Верификация занимает секунды, а не недели — экономия времени на аудите до 70%.
Почему гибридный подход оптимален?
Для корпоративных участников часто требуется конфиденциальность коммерческих данных (цены, объёмы). Чисто публичный блокчейн раскрывает все данные, что неприемлемо. Приватные сети (Hyperledger Besu, Quorum) обеспечивают приватность, но теряют trustless-гарантию. Гибридный подход — приватная сеть для операционных данных + якорение хешей на публичный блокчейн — даёт лучшее из двух миров. Гибридная архитектура снижает затраты на хранение данных в 5 раз по сравнению с полностью публичной сетью. Мы используем такую архитектуру в большинстве enterprise-проектов.
Архитектурные решения
Выбор сети
Для supply chain систем с корпоративными участниками подходят два класса решений:
Публичные сети (Polygon, Avalanche, Base) — прозрачность для конечного потребителя. Любой может верифицировать данные через block explorer. Минус — все данные публичны, что может быть неприемлемо для B2B данных о контрагентах и ценах. Производительность таких сетей обычно до 200 TPS.
Permissioned сети (Hyperledger Besu, Quorum, Fabric) — приватность участников, высокая производительность (до 10 000 TPS, что в 50 раз выше публичных), фиксированный набор валидаторов. Подходит для consortium участников. Минус — теряется trustless гарантия, характерная для публичных сетей.
Гибридный подход: приватная сеть для операционных данных + якорение хешей на публичный блокчейн для аудируемости. Оптимальный вариант для большинства enterprise-случаев.
Идентификаторы продуктов
Стандарт — GS1 EPCIS 2.0 для событий в цепочке поставок. Каждый физический объект получает уникальный идентификатор (EPC — Electronic Product Code), привязанный к on-chain записи:
contract ProductRegistry {
struct ProductBatch {
bytes32 batchId; // хэш от GS1 GTIN + lot number + expiry
address certifiedBy; // аккаунт сертифицирующего органа
bytes32 documentHash; // IPFS CID документов в bytes32
uint256 certifiedAt;
CertificationLevel level;
bool revoked;
}
enum CertificationLevel {
ORIGIN_DECLARED, // продавец задекларировал происхождение
AUDITOR_VERIFIED, // независимый аудитор верифицировал
LAB_TESTED, // лабораторные анализы подтверждены
CERTIFIED // полная сертификация пройдена
}
mapping(bytes32 => ProductBatch) public batches;
mapping(bytes32 => bytes32[]) public batchEvents; // цепочка событий
// только аккредитованные сертификаторы
mapping(address => bool) public certifiers;
modifier onlyCertifier() {
require(certifiers[msg.sender], "Not authorized certifier");
_;
}
function certifyBatch(
bytes32 batchId,
bytes32 documentHash,
CertificationLevel level
) external onlyCertifier {
batches[batchId] = ProductBatch({
batchId: batchId,
certifiedBy: msg.sender,
documentHash: documentHash,
certifiedAt: block.timestamp,
level: level,
revoked: false
});
emit BatchCertified(batchId, msg.sender, level);
}
function revokeCertification(bytes32 batchId, string calldata reason)
external onlyCertifier
{
require(batches[batchId].certifiedBy == msg.sender, "Not your cert");
batches[batchId].revoked = true;
emit CertificationRevoked(batchId, reason);
}
}
NFT vs. SFT vs. fungible token
Для сертификации батчей продуктов используем разные типы токенов. Сравнение:
| Тип токена | Сценарий использования | Примеры товаров |
|---|---|---|
| ERC-721 (NFT) | Каждый батч уникален, требуется различение всех партий | Вино, предметы роскоши |
| ERC-1155 (Semi-fungible) | Внутри батча единицы одинаковы, между батчами различны; возможна частичная передача | Большинство товаров (organic, pharma) |
| ERC-20 (Fungible) | Сыпучие/жидкие товары без фиксации партий | Зерно, нефть |
Подробнее о стандартах — в документации Ethereum.
Цепочка событий (трансфер custody)
Каждое перемещение товара в цепочке поставок записывается как событие. События образуют auditable trail:
contract SupplyChainEvents {
struct CustodyEvent {
bytes32 batchId;
address from; // предыдущий владелец / производитель
address to; // следующий владелец / дистрибьютор
bytes32 locationHash; // хэш GPS-координат или адреса склада
bytes32 conditionsHash; // хэш данных IoT (температура, влажность)
uint256 timestamp;
EventType eventType;
}
enum EventType {
PRODUCED,
QUALITY_CHECKED,
PACKAGED,
SHIPPED,
CUSTOMS_CLEARED,
RECEIVED,
RETAIL_LISTED,
SOLD
}
event CustodyTransferred(
bytes32 indexed batchId,
address indexed from,
address indexed to,
EventType eventType
);
}
Хранить сырые данные о местоположении и условиях хранения on-chain дорого. Правильная схема: данные → IPFS/Arweave → хэш данных on-chain. Верификатор скачивает данные с IPFS и проверяет что хэш совпадает с on-chain записью.
Интеграция с IoT
Физические сенсоры (температура при транспортировке, влажность на складе) — важная часть системы для food & pharma. Проблема: IoT-устройство не может самостоятельно подписывать Ethereum транзакции в условиях ограниченных вычислительных ресурсов.
Архитектурное решение — oracle pattern:
IoT Device → Edge Gateway → Oracle Service → Smart Contract
Edge Gateway собирает данные с устройств, агрегирует их и через защищённый канал передаёт в oracle service (Chainlink, API3, или кастомный). Oracle записывает данные on-chain с подписью доверенного оператора.
Для повышения доверия к IoT-данным: TEE (Trusted Execution Environment) на edge gateway — Intel SGX или ARM TrustZone. Данные подписываются внутри изолированной среды, и proof выполнения в TEE может быть верифицирован on-chain.
Верификация потребителем
QR-код на продукте кодирует batchId. Потребитель сканирует QR и видит:
- Статус сертификации (уровень, орган, дата)
- Полную цепочку custody от производителя до полки
- Документы (сертификаты, лабораторные анализы) на IPFS
- Был ли сертификат отозван
Это реализуется как статический сайт или мобильное приложение, которое читает данные напрямую с блокчейна через JSON-RPC или через The Graph (для более сложных запросов).
Управление доступом и аккредитация
Критически важный компонент — система управления тем, кто имеет право вносить сертификационные записи. Варианты:
| Модель | Подходит для | Риски |
|---|---|---|
| Centralized whitelist | Пилотные проекты | Единая точка доверия |
| DAO governance | Открытые экосистемы | Медленное принятие решений |
| Accreditation body on-chain | Regulated industries | Требует off-chain legality |
| Multi-sig committee | Consortium | Координация участников |
Для regulated industries (organic food, pharma) оптимальна модель где национальные органы аккредитации управляют on-chain списком авторизованных сертификаторов. Это создаёт bridge между традиционной regulatory системой и блокчейном.
Как мы это делаем: пошаговый процесс
- Анализ требований: изучаем бизнес-процессы, количество участников, типы товаров. Определяем критичные точки, где блокчейн приносит максимальную пользу (снижение времени верификации на 70%, экономия на аудите до 40%).
- Проектирование архитектуры: выбираем сеть (гибридную или публичную), проектируем смарт-контракты, интеграцию с ERP и IoT.
- Разработка и аудит кода: пишем смарт-контракты на Solidity 0.8.x, тестируем в Foundry, проводим security audit (Slither, Mythril).
- Деплой и настройка: развёртываем в выбранной сети, настраиваем oracle, разрабатываем веб-интерфейс для потребителей.
- Поддержка и доработка: мониторинг, обновление смарт-контрактов, обучение команды.
Свяжитесь с нами для консультации — оценим ваш проект и предложим оптимальное решение.
Получите оценку проекта: опишите задачи, и мы подготовим коммерческое предложение.
Почему стоит выбрать нас?
Наш опыт — более 5 лет в блокчейн-разработке, свыше 50 проектов в DeFi и supply chain. Инженеры публиковали аудиты для открытых проектов и участвовали в разработке стандартов ERC. Каждый проект сопровождаем на всех этапах.