← Вернуться в центр знаний

Блокчейн в компании: когда распределённый реестр действительно нужен

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

И
Инженерная редакция ВирТЭКСистемная интеграция и эксплуатация

Начните с конфликта доверия, а не с платформы

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

Полезный вопрос для совещания: что именно перестанет работать, если единый оператор сможет незаметно изменить историю? Если убедительного ответа нет, блокчейн, вероятно, не нужен.

Проверьте четыре обязательных условия

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

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

Выберите модель управления до выбора технологии

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

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

Не помещайте в реестр всё подряд

В цепочке обычно достаточно хранить идентификатор события, хеш документа, подписи, время и подтверждённое состояние. Коммерческие документы, персональные данные и большие файлы лучше оставлять в контролируемом хранилище, связывая их с реестром криптографическим доказательством. Так проще выполнять требования доступа, исправления, хранения и удаления.

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

Пилот должен проверять экономику процесса

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

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

Результат этапа выбора

До закупки платформы должны появиться карта участников, модель доверия, объект общего учёта, правила подтверждения, перечень данных on-chain и off-chain, модель ключей, юридический регламент и измеримый эффект. Такой пакет позволяет честно сравнить блокчейн с централизованной архитектурой и выбрать решение по задаче, а не по названию технологии.

Нужна архитектура
под вашу задачу?

Разберём исходные данные, риски и ограничения, затем предложим обоснованный вариант решения.

Обсудить с инженером↗︎