Практическое применение блокчейна как распределенного хранилища данных

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

Задача


Регистрация на площадке по государственным закупкам процесс достаточно бюрократизированный. Исполняя требования законодательства и реализуя принцип Know your customer (KYC), площадкам и удостоверяющим центрам приходиться собирать множество документов, подтверждающих личность клиента и происхождение средств. У компании-заказчика возникла идея, создать сервис единовременной аккредитации на всех площадках по государственным закупкам регулируемых разными законами — создать единый профиль контрагента (это позволило бы собрать необходимые документы только 1 раз). Такой сервис был бы полезен всем – пользователи после регистрации на любой площадке получили бы возможность работать со всеми остальными без дополнительной волокиты; площадки получили бы новых пользователей, за счёт упрощения регистрации. В дальнейшем, к этой платформе можно было бы привлечь конкурирующие площадки и другие смежные организации.

Решение


По сути перед нами встала задача создать децентрализованную систему обмена данными (далее Платформа) в рамках консорциума — т.е. закрытого сообщества участников. Хотя в нашем случае, речь шла о системе, в которой доступ к данным предоставляется всем участникам, мы решили подойти к задаче шире и создать систему, в рамках которой пользователи могли бы сами решать, кому из участников системы они хотят предоставить доступ к данным, а кому нет.

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

Основные характеристики разработанного решения:

  • Данные распределяются между всеми узлами системы, ни один из участников системы не может сфальсифицировать или удалить данные, однажды выданные другому участнику, а также отсутствует единая точка отказа. Даже при физическом отключении узла участника от сети, данные, полученные до момента отключения, остаются на этом узле и доступны для работы с ними, а при восстановлении подключения происходит получение данных, появившихся во время отсутствия узла в сети.
  • Используется закрытый блокчейн (консорциум) – т.е. для подключения к нему требуется либо согласование узлом-координатором, либо, если выбрана консенсусная модель администрирования – всеми участниками сети.
  • После подключения, участник консорциума может создавать как публичные (доступные всем участникам), так и закрытые (доступные выбранному кругу участников) коллекции данных. Безопасность закрытых данных обеспечивается посредством криптозащиты данных с помощью ГОСТовских алгоритмов.
  • Управлять доступом к коллекции может лишь ее создатель.
  • При добавлении к списку доступа уже существующей коллекции нового участника, опубликованные ранее данные становятся ему доступны автоматически.
  • При удалении участника из списка доступа новые опубликованные данные будут ему недоступны.
  • Платформа поддерживает структурирование данных в коллекции в формате JSON и валидацию формата документа в ней по JSON-схеме.
  • Платформа предоставляет АПИ, изолирующий пользователя от деталей реализации самого блокчейна и позволяющий работать с понятиями более высокого уровня («документ» и «коллекция»).
  • Платформа не предусматривает удаления данных, таким образом, ни один участник не может удалить документ из коллекции, доступной другим участникам.
  • При обновлении документа, сохраняется полная история его изменений, и есть возможность получения любой из версий документа.
  • Платформа поддерживает отправку внешним системам участника настраиваемых уведомлений об изменении/обновлении данных в интересующей коллекции, таким образом, информационные системы одного участника могут оперативно реагировать на обновления данных, сделанные информационными системами другого участника.

Как видите список довольно внушительный. Конечно, у системы есть и некоторые недостатки, о которых мы знаем: например, если мы один раз дали кому-то доступ к данным, можно предположить, что эти данные он уже скопировал и может отдать кому-либо еще, но это уже вне контроля нашей системы. Однако, такого рода риски есть у любой системы. Еще одним недостатком системы, обусловленным использованием блокчейна и необходимостью операций шифрования/дешифрования данных на лету, является общая пропускная способность, составившая ~30 транзакций в секунду, что оказалось более чем достаточно для конкретной задачи, но может являться ограничивающим фактором для применения Платформы в ряде других сценариев.

Что касается принципа работы механизма управления доступом к данным, то он основан на гибридной схеме шифрования:

  1. Зарегистрированный участник системы получает публичный и приватный ключ. Публичный ключ каждого участника является общедоступным и публикуется в блокчейне.
  2. Участник №1 создаёт новую коллекцию и определяет, с кем из участников системы он хотел бы поделиться её содержимым (Участник №2 и №3), затем добавляет в эту коллекцию документ.
  3. Платформа шифрует документ сгенерированным симметричным ключом (это значит, что для расшифровки потребуется тот же ключ, что и для шифрования). Такой ключ имеет значительно меньший объем, чем, сам зашифрованный документ.
  4. Платформа извлекает из блокчейна публичные ключи участников №2 и №3 и шифрует ими симметричный ключ, и помещает результаты в блокчейн.
  5. Участники №2 и №3 входят в систему и пытаются просмотреть содержимое коллекции. Платформа расшифровывает приватными ключами участников №2 и №3 симметричный ключ, после чего этим ключом расшифровывает документ. Таким образом участники №2 и №3 получают доступ к его содержимому.

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

  1. Участник проходит регистрацию в Учётном центре (далее УЦ№1), подавая все необходимые документы и данные.
  2. Учётный центр выдаёт участнику электронную подпись и привязывает к ней все подданные им данные, складывая всё это в блокчейн.
  3. Когда участник заходит на площадку по государственным закупкам (далее Площадка №1), она извлекает его регистрационные данные из Коллекции, созданной УЦ№1.
  4. Возможна ситуация, когда площадке не хватит этих данных и она запросит дополнительные или же захочет хранить другую информацию (например, историю участия в торгах) по конкретному клиенту, чтобы поделиться ей с другой дружественной площадкой. В этом случае, она создаёт в блокчейне новую коллекцию с этими дополнительными данными.
  5. Когда Участник решает зарегистрироваться на Площадке №2 она также берёт его регистрационные данные из коллекции УЦ №1 или же из коллекции созданной Площадкой №1

Итог


На данный момент наше решение внедрено и успешно работает. Если у вас есть вопросы или замечания – пишите в комментарии, будем рады ответить или подискутировать.
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 47
  • 0
    Участник №1 создаёт новую коллекцию и определяет, с кем из участников системы он хотел бы поделиться её содержимым (Участник №2 и №3), затем добавляет в эту коллекцию документ.

    Что делать с участниками, которые появятся после создания коллекции? Нет ничего похожего на группы, теги, или более комфортные аналоги в рамках такой задачи, если такие существуют?
  • 0
    При добавлении нового пользователя доступ к коллекции ему предоставляет её владелец. По сути он свои приватным ключом расшифровывает симметричный ключ и шифрует его публичным ключом нового пользователям, которому предоставляет доступ. Тот уже своим приватным ключом расшифровывает симметричный ключ и получает доступ к содержимому коллекции.
    На уровне ядра системы мы не оперируем такими понятиями как «Группа», возможно это будет добавлено в будущем
    • 0
      У меня нескромный вопрос. В рамках блокчейна все транзакции, по идее, должны быть видны всем участникам (пусть и зашифрованные). То есть каждый, вступивший в систему, получит в своё хранилище не только «свои» транзакции, а вообще все.
      Или у Вас как-то не так?
      • 0
        Естественно, все транзакции видны, но данные в них — зашифрованы, таким образом получить доступ к ним не получится, пока Вам не выдадут ключ для дешифровки данных.
        • 0
          Т.е. фактически не решен вопрос прозрачности гос. закупок? Ведь мы можем всё равно скрыть данные о том, кто что выполнил, и насколько качественно, если эти данные видны лишь им двоим. А захочет третий заказчик иметь дело с ними, но их история им недоступна. Тут должно быть как раз таки всё прозрачно, видеть кто, когда и что именно выполнил, в каких масштабах. Разве нет?
          • 0
            Решение задачи прозрачности госзакупок — вне скоупа данной системы, более того — эта задача уже давно решена на гос. уровне — существует ЕИС (http://zakupki.gov.ru/epz/main/public/home.html) где публикуются все данные о госзакупках. Данная система была разработана для решения задачи KYC (Know Your Customer) между различными, в том числе — конкурирующими друг с другом — площадками. Т.е. речь идет не о хранении данных о закупках, а об обмене данными о клиентах площадок между этими площадками.
      • 0
        Какая производительность получается? Сколько времени занимает фиксация транзакции?
        • 0
          Все зависит от железа. На стенде (Core i5, 8Gb, SSD) если «напрямую» с блокчейном через RPC-call то получается порядка 250 записей в секунду на чтение и 160 записей в секунду на запись. Если через API с применением шифрования на той же конфигурации, получаем цифры 32 и 12 записи в секунду соответственно. Да, это немного, есть над чем поработать, главным образом — над оптимизацией работы с json объектами.
        • 0
          Планируем делать похожий проект, но для производства, собираем команду. Какой набор скилов нужен, какие роли, какими силами вы проект запустили, без коммерческой информации, в-общем если можно?
          • 0
            Мы эту Платформу реализовали довольно небольшой командой — архитектор и 2 разработчика — примерно за полгода. Скиллы — зависит от того, какую блокчейн-платформу и целевую платформу Вашего решения Вы выберете, но в целом — кроме общих скиллов разработчиков необходимо хорошо понимать детали работы выбранной блокчейн-платформы и иметь опыт работы с криптосредствами.
            • 0
              Спасибо за ответ. Посмотрим на Multichain, о котором вы пишите.
              • 0
                Еще момент, а не думали хранить в блокчейне только хэш конфиденциальной информации, а саму инфу хранить только в тех нодах, у которых есть доступ?
                • 0
                  Целью было распределенно хранить саму информацию, а не только производные данные, способные подтвердить сам факт наличия этой информации, поэтому такой вариант не рассматривался.
            • +2
              Прочитал и подумал, а причем тут блокчейн? Ну вот реально, вы по-моему просто используете этот хайповый термин. Судя по описанию обычное серверное приложение со своими рюшечками.
              • 0
                Не могу согласиться. Наше решение поддерживает децентрализованность, достоверность и версионность данных. Можно конечно задаться целью и реализовать всё это в обычном серверном приложении, но зачем, если в технологии блокчейн эти вопросы уже решены?
              • 0
                Какие мы молодцы! Даешь блокчейн в массы!:)
                • 0
                  Подскажите, если не секрет, на каком технологическом стеке вы реализовали блокчейн?
                  • +1
                    Сам блокчейн как таковой мы не реализовывали, использовали Multichain — это производный от биткойновского ядра продукт, специально заточенный под консорциумы.
                  • 0
                    Вы указали, что система продолжает работать при обрывах связи, разъясните, а что будет при сплите сети?
                    Как я понял платформ-узлов в сети не так много. Представьте ситуацию, что одна платформа засинкалась, потом ее узел перестал общаться с внешним миром, но не утерял возможности работать с клиентами. Тогда после некоторой небольшой работы с данной платформой, пользователь уверен, что все данные сохраняются. Однако блочейн же выберет самую длинную цепь подтвержденную большинством без всяких мержей, соответственно, все что было сделано на этом отдленном узле будет потеряно. Как с этим боретесь?
                    Аналогично как решаются следующие вопросы в случае, когда нода ушла в отрыв:
                    — предоставления актуальной информации
                    — считает ли нода себя потерянной и всячески сигналит, не давая менять данные, что она отвалилась, или просто продолжает работать
                    — есть ли минимальнео количество нод для «кворума»
                    • 0
                      Спасибо за Ваш вопрос.
                      Для нас решение этих задач является приоритетным. В настоящее время реализовано через проверку подключения ноды к системе. Если подключения нет — запись не возможна.
                      С другой стороны, специфика хранения данных (в Multichain это потоки) при восстановлении подключения позволяет смержить данные. А в виду того, что это не платежные транзакции, то угрозы двойного расхода нет. К тому же все тот же поток позволяет хранить историю изменений по уникальному ключу документа.
                      Что касается минимального количество нод для «кворума», то этот параметр настраивается при создании блокчейна в зависимости от требований.
                    • 0

                      Как обрабатывается ситуация с компрометацией приватного ключа агента (участника)?

                      • 0
                        Для подобных случаев разработан механизм версионности. Т.е. если нам надо у участника забрать права доступа, то владелец коллекции выпускает новый ключ шифрования и раздает его тем участникам, у которых доступ остался. Т.о. все записи, которые были сделаны ранее, участнику, лишенного прав, будут доступны как и ранее, а новые уже нет.
                      • 0
                        Какие объемы в вашем блокчейне и что планируете делать когда он(блокчейн) разрастется?
                      • 0
                        На данный момент не так много порядка нескольких ГБ (в тестах было до 500ГБ). Блокчейн сторится в файловой системе в виде файлов. Поэтому и масштабируеться как файловый datastore.
                        • 0
                          И в перспективе сколько? 500 гигов на каждую машину это уж слишком перебор. По сути своей это и плюс и минус блокчейна.
                          • 0
                            Конкретно у нас для конкретно этого сценария получается за год около 10ГБ.
                          • 0
                            Вопрос как раз в том, когда он разрастется до 500Гб, а произойдет это, как мне кажется гораздо быстрее чем у простой криптовалюты. И что делать когда он на столько сильно разрастется? Не бомба ли это замедленного действия?
                            • 0
                              Однозначно быстрее, ведь мы храним информацию о бизнес объектах, а их размер зависит только от требований к структуре данных.А делать только одно — добавлять диски :) Мы же понимаем с вами, что это решение enterprise уровня.
                              • 0
                                А причем здесь диски то? У вас разве нет копии на каждой локальной машине? Это же суть блокчейна, независимость от единого источника.
                                • 0
                                  На каждой машине, где развернута нода блокчейна добавляем диски по мере того, как заканчивается свободное место. Относитесь к этому как к datastorage
                                  • 0
                                    Ничего что эта копия должна быть на каждом клиенте так то, в этом суть.
                                    А если этого нет, если у вас все ноды контролируются вами, то у вас просто зеркалирование базы данных, это не блокчейн т.к. вы нарушаете ее основной принцип.
                                    В общем вернувшись к моему первому комментарию — у вас обычное распределенное приложение, блокчейн здесь просто красивое модное слово.
                                    Рекомендую перечитать, если не читали
                                    habrahabr.ru/company/kaspersky/blog/336036
                                    • 0
                                      Давайте еще раз поясню, если это необходимо.

                                      Данные хранятся именно в блокчейне, реализованном на базе Multichain, детали его реализации — не вижу смысла повторять, они описаны на www.multichain.com, в общем, классический блокчейн, за базе того же биткойновского ядра. Но работать с голым блокчейном для хранения данных не слишком удобно, поэтому поверх блокчейна нами реализован слой доступа к данным, который дает:
                                      1) удобный интерфейс доступа к данным, а-ля документ-ориентированная БД
                                      2) шифрование/дешифрование информации православными ГОСТовыми алгоритмами (это было важно для нашего клиента)
                                      3) механизм подписки на обновления данных.
                                      Именно это расширение и есть наша разработка, сам Мультичейн — открыто распространяемая опенсорсная блокчейн-платформа, мы к его созданию отношения не имеем, мы его используем. По этому странно видеть Ваше негодование, что это не блокчейн — ну ОК, исходные коды этого «неблокчейна» открыты, приведите, что именно в них заставляет Вас так думать?

                                      По поводу контроля за нодами — наша система представляет собой не открытый блокчейн, а консорциум, что и оговорено в статье. Соответственно, контроль за узлами — в руках администраторов этих узлов, в нашем случае — ряда организаций. Но круг этих организаций — ограничен, и каждый новый узел должен получить разрешение других узлов, либо одного уполномоченного узла(в зависимости от настроек чейна), на подключение к системе. Опять же, если интересны детали — могу посоветовать обратиться к документации Мультичейна, там все подробно изложено.
                                      • 0
                                        Если в названии продукта который вы используете есть частичка chain и они себя чем-то называют это не делает их тем чем они являются.
                                        У вас модифицированное что-то там как-то там и пусть называется chain, но оно не соответствует критериям блокчейна, в статье которую я привел все предельно понятно изложено.
                                        Основная претензия в том что вы пишите «Практическое применение блокчейна как распределенного хранилища данных», но это лукавство и игра слов на тренде. Распределенная система — Да, но не классический блокчейн.
                                        • 0
                                          Простите, мне сложно с Вами дискутировать не понимая вашего профессионального бэкграунда. Если вы разработчик — то вот вам исходные коды системы — github.com/MultiChain/multichain — скажите, что именно в них наводит вас на мысль, что это НЕ блокчейн?

                                          Если Вы не разработчик — «то начнем издалека» (с). Что, по-вашему, блокчейн?
                          • 0
                            Подскажите, а что с лицензированием/сертификацией криптографии, Multichain вряд ли имеет лицензии/сертификацию от ФСБ/ФСТЭК?
                            • 0
                              Вот это как раз один из моментов, почему нам пришлось реализовывать «тяжелые» api. Вся работа с шифрованием данных происходит в бизнеслогике по ГОСТ с использованием CryptoPro.
                              • 0
                                а может тогда опишите чуть подробнее как удалось подружить Multichain и CryptoPro? с какими проблемами столкнулись, и как разрешили?
                                • 0
                                  Нет, не совсем так. Multichain и CryptoPro мы между собой не дружили. Multichain вообще про CryptoPro ничего не знает. На уровне транзакций он (Multichain) как работал со своей криптографией, так и работает (secp256k1). Мы же на уровни бизнес логике перед записью в Multichain данные зашифровываем, а после чтения из него — расшифровываем.
                                  Изначально мы думали над тем, чтоб реализовать поддержку crypto.pro на уровне ядра в Multichain, но тут дрогнула рука у нас.
                                  • 0
                                    Получается у вас используется двойное шифрование? сначала по ГОСТу, а потом сверху secp256k1? Юридически такой вариант прорабатывали?
                                    P.S. Понимаю вопросы не очень технические и не очень приятные, но они по сути без их решения в бизнес задачах вряд ли как то будут решаться…
                                    • 0
                                      Да, именно так. Если мы хотим получить блокчейн с гостовой криптографией — у нас есть 3 пути:
                                      1) запилить все с нуля — очевидно, это долго, дорого и не очень надежно, т.к. вряд ли получится быстро набрать такую пользовательскую базу (читай, халявных тестировщиков), как популярные открытые проекты. Поэтому примеров таких решения я даже и не вспомню сейчас.
                                      2) попробовать адаптировать готовую популярную платформу под православную криптографию — этим путем пошел Центробанк в своем проекте Мастерчейн (http://fintechru.org/Masterchain_whitepaper_11_08.pdf)
                                      3) Перейти на уровень выше и рассматривать блокчейн просто как специфичный слой хранения данных, со всеми его преимуществами и недостатками, с которым обмениваться уже шифрованными/подписанными данными.

                                      Мы в решили попробовать третий подход.
                            • 0
                              дрогнула рука
                              • 0
                                Коллеги, если Вам интересна наша система или есть вопросы которые Вы хотели бы обсудить тет-а-тет — у меня в профиле указаны контакты — пишите, будем рады сотрудничеству.
                                • 0
                                  Если все полностью децентрализовано, то как участник блокчейн находит остальные сервера, чтобы распространить им информацию о записи в блокчейн?
                                  хотелось бы подробнее узнать алгоритм поиска соседних нод.
                                • 0
                                  Первое и обязательное условие, чтобы новая нода начала работать в системе, необходимо при первом ее запуске указать адрес ноды администратора (помните, у нас PoA), после чего на ноде администратора дать права подключаемой ноде. А дальше каждая нода «знает» об остальных нодах системы и вход вступает p2p.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.