Архитектура DetalkiPro Chain: блокчейн как слой доверия в маркетплейсе запчастей

В российском e-commerce блокчейн часто внедряют как демонстрационную функцию, не связанную с бизнес-логикой. Проект DetalkiPro Chain выбрал иной путь: распределённый реестр здесь выступает специализированным слоем доверия, закрывающим конкретные операционные боли маркетплейса запчастей — спорные статусы заказов, непрозрачную историю бонусов, расхождения в остатках и фундаментальное недоверие между поставщиком и покупателем.

Проблема: почему маркетплейсу нужен не «блокчейн для галочки», а слой доверия

Классическая схема работы маркетплейса предполагает, что все факты сделки — статус товара, начисленные бонусы, перемещение партии между складами — хранятся в централизованной базе данных продавца или платформы. Это создаёт точку отказа: администратор с достаточными правами может изменить историю задним числом, стереть запись о списании бонусов или поменять статус гарантии со «рабочий» на «брак» без аудиторского следа. Для рынка запчастей, где стоимость ошибки высока, а составные части часто не имеют единого идентификатора, это порождает поток споров.

DetalkiPro Chain строит не просто торговую площадку, а «рынок доверия» или, в терминологии команды, «рынок истины». Каждая критическая сделка фиксируется в блокчейне, что делает её неизменяемой ретроспективно. Если в карточке товара указано, что модуль или плата рабочие, это утверждение становится частью зафиксированной истины, а не просто маркетинговым текстом. При возникновении претензии — например, клиент получил неисправную деталь — прозрачная цепочка статусов и гарантий позволяет быстро локализовать этап и момент изменения состояния, исключая долгие споры и ручную проверку логов. Ответственность становится понятной и привязанной к конкретным событиям в реестре.

Что пишется в цепочку: бонусы, гарантии, остатки и активность сообщества

Принцип минимальной достаточности лежит в основе политики записи данных: в блокчейн попадает только то, где критически важны неизменяемость и публичная верифицируемость. Объёмные каталоги, описания товаров, пользовательские профили и текущие корзины остаются в привычной инфраструктуре маркетплейса.

Бонусная система и скидки

Каждое начисление и списание бонусных баллов оформляется как отдельная транзакция. Клиент получает возможность самостоятельно пройтись по цепочке: проверить, за какое действие были начислены баллы, когда и в каком объёме они были списаны, какой лимит доступен на текущий момент. Это исключает «тихие» сгорания баллов или несанкционированные начисления менеджерами.

Гарантийные статусы и серийная трассировка

В реестр вносится факт продажи с привязкой к дате, серийному номеру (при наличии) и сроку гарантии. Статус гарантии не может быть откатан или изменён без следа. Это снимает класс спорных кейсов, когда продавец отрицает факт продажи или срок действия гарантии, а покупатель не может предъявить чек — фактура существует в независимом реестре.

Движение остатков между складами и ПВЗ

Фиксируются ключевые переходы товара: отгрузка со склада А, приёмка на пункте выдачи Б. Если позиция «зависла» в транзите, цепочка событий показывает точный этап и временную метку остановки. Это превращает логистику из «чёрного ящика» в аудируемый процесс без необходимости опрашивать курьеров и кладовщиков по телефону.

Активность сообщества во втором слое (L2)

Для целевой аудитории — радиолюбителей и инженеров — в L2 закрепляется участие в жизни сети и начисление за это бонусов. Экономика сообщества становится прозрачной: правила начислений не меняются задним числом, история активности видна всем участникам, что формирует устойчивую мотивацию без административного ресурса.

Архитектура «маркетплейс — оракулы — блокчейн»: роль валидаторов и точек выдачи

Система построена по классической схеме разделения ответственности: маркетплейс остаётся витриной и источником бизнес-логики, блокчейн выполняет функцию слоя доверия, а связующим звеном выступают оракулы и модуль валидации.

Оракул-сервис на точке (Лиговский проспект)

Независимый источник истины развёрнут на физической точке на Лиговском проспекте. Дешёвый ПК собирает телеметрию работы сети и передаёт её в блокчейн. Если какой-либо узел попытается исказить данные (например, подменить факт приёмки товара), оракул зафиксирует расхождение между локальным состоянием и данными, пришедшими от точки. Это аппаратный якорь доверия, не зависящий от серверной инфраструктуры платформы.

Модуль валидации вычислений

Отдельный компонент проверяет корректность вычислений для майнинга токенов на специализированном оборудовании ASIC Apollo. Без этого этапа сеть была бы уязвима к ошибкам в расчёте наград или целенаправленным манипуляциям со стороны держателей железа. Валидатор выступает арбитром математической честности перед записью в L1.

Интеграция через API и очередь событий

Маркетплейс не требует переписывания ядра. События — продажа, начисление бонуса, смена статуса гарантии, перемещение остатка — публикуются во внутреннюю очередь. Оттуда они асинхронно попадают в модуль валидации, а затем — в блокчейн. Существующая логика магазина при этом не ломается, а получает криптографически подтверждённый аудит-трейл.

Разделение L1 (ASIC Apollo) и L2: баланс безопасности и скорости для бытовых механик

Архитектурное решение о разделении на два слоя решает дилемму «безопасность против производительности» без компромиссов.

L1 — базовый слой на ASIC Apollo

Первый слой обеспечивается специализированными устройствами ASIC Apollo. Он отвечает за конечное подтверждение операций, распределение базовых наград и хранение самых критичных данных и правил протокола. Безопасность и целостность сети гарантируются именно здесь, на уровне аппаратно закреплённого консенсуса.

L2 — слой для радиолюбителей и повседневных механик

Второй слой предназначен для высокочастотных, но менее критических по безопасности операций: бонусные программы, акции, рейтинговые механики, голосования сообщества. L2 работает быстрее и гибче, позволяя менять параметры акций без хардфорков базового протокола, но криптографически привязан к L1 через периодические чеки или стейкинг-мосты. Таким образом, важные вещи (гарантии, остатки, базовые токены) защищены максимально, а бытовые механики (скидки, активность) работают с пользовательским UX.

Технологический стек: Go, Mac Mini как узлы, GitFlic и подход к отказоустойчивости

Инструментарий подобран под требования детерминизма, управляемости и физической распределённости.

Go — язык критических модулей

Модули валидации, майнинга и интеграции написаны на Go. Выбор обусловлен потребностью в предсказуемой производительности, отсутствии «stop-the-world» пауз, критичных для консенсуса, и качественной стандартной библиотеке для сетевого взаимодействия и криптографии.

Mac Mini — физические узлы сети в ПВЗ

Узлы валидации и оракулы развёрнуты на устройствах Mac Mini, установленных непосредственно в пунктах выдачи заказов и на торговых точках. Это архитектурное решение переносит децентрализацию из облака в физическое пространство: сеть держится не только на дата-центрах, но и на инфраструктуре бизнеса. Выход из строя одного ЦОД не останавливает консенсус, пока работают локальные узлы.

GitFlic — контроль версий и коллаборация

Для управления кодовой базой, включающей модули валидации, майнинга, парсеры и интеграционные адаптеры, используется платформа GitFlic. Это обеспечивает прозрачную историю изменений, код-ревью и CI/CD пайплайны, критичные для проекта с множеством независимых сервисов.

Ubuntu — среда выполнения и удалённая операция

Серверная часть инфраструктуры и рабочие станции команды работают на Ubuntu. Стабильная среда для скриптов автоматизации, мониторинга и удалённого управления узлами позволяет не зависеть от проприетарных ОС и поддерживать единый стандарт безопасности.

Масштабирование через ПВЗ-узлы и текущий статус: валидация майнинга и развёртывание сети

Стратегия горизонтального масштабирования заложена в бизнес-модель: каждый новый пункт выдачи — это потенциальный полноценный узел сети и оракул. Добавление точки автоматически увеличивает географическую распределённость консенсуса и количество независимых источников данных о логистике.

Отказоустойчивость обеспечивается регулярными бэкапами критических конфигураций и данных, а также практикой удалённой работы команды — потеря доступа к одному офису или серверной не парализует разработку и эксплуатацию.

Текущий фокус разработки

На данный момент готовится тестовая версия производственного приложения. Основные инженерные усилия сосредоточены на трёх векторах:

• Доработка модуля валидации вычислений для майнинга токенов на ASIC Apollo — завершение аппаратной привязки безопасности L1.
• Развёртывание сети узлов на новых торговых точках и подключение дополнительных оракулов — расширение физической топологии доверия.
• Масштабирование L2-слоя для радиолюбителей — реализация механик активности и прозрачных правил начисления бонусов сообществу.

Команда не декларирует «взрывной рост» или «революцию рынка» — текущий этап это план по доведению архитектуры до стабильной эксплуатационной готовности.

Исходный код модулей и история разработки доступны в репозиториях на GitFlic: github.com/paderinpavel?tab=repositories. Обсуждение архитектурных решений и обратная связь принимаются на странице ВКонтакте: vk.ru/paderinnpavel. Проект находится в стадии активной наработки к запуску, и предложения по улучшению учитываются в дорожной карте.

Вопросы и ответы

Какие именно данные маркетплейс записывает в блокчейн, а какие оставляет в своей базе?

В блокчейн попадают только критически важные для доверия события: транзакции бонусной системы (начисления и списания), факты продаж с привязкой к серийным номерам и срокам гарантии, ключевые логистические переходы товара между складами и ПВЗ, а также активность сообщества радиолюбителей в L2. Каталоги товаров, описания, профили пользователей и корзины остаются в централизованной инфраструктуре маркетплейса.

Как устроено взаимодействие маркетплейса с блокчейном и зачем нужны оракулы?

Маркетплейс публикует события (продажа, начисление бонуса, смена статуса) во внутреннюю очередь. Оттуда они асинхронно проходят через модуль валидации (проверка корректности вычислений для майнинга на ASIC Apollo) и записываются в блокчейн. Оракул-сервис на физической точке (Лиговский проспект) независимо собирает телеметрию сети и сверяет её с данными узлов, выступая аппаратным якорем доверия, который обнаруживает подмену фактов приёмки или статусов.

В чём разница между L1 и L2 в архитектуре DetalkiPro Chain?

L1 реализован на специализированных устройствах ASIC Apollo и отвечает за безопасность, конечное подтверждение операций, распределение базовых наград и хранение критических правил протокола. L2 — более быстрый и гибкий слой для повседневных механик: бонусов, акций, рейтингов и голосований радиолюбителей. L2 криптографически привязан к L1 (через чеки или мосты), что позволяет менять параметры акций без хардфорков базового протокола.