Задача
Регистрация на площадке по государственным закупкам процесс достаточно бюрократизированный. Исполняя требования законодательства и реализуя принцип Know your customer (KYC), площадкам и удостоверяющим центрам приходиться собирать множество документов, подтверждающих личность клиента и происхождение средств. У компании-заказчика возникла идея, создать сервис единовременной аккредитации на всех площадках по государственным закупкам регулируемых разными законами — создать единый профиль контрагента (это позволило бы собрать необходимые документы только 1 раз). Такой сервис был бы полезен всем – пользователи после регистрации на любой площадке получили бы возможность работать со всеми остальными без дополнительной волокиты; площадки получили бы новых пользователей, за счёт упрощения регистрации. В дальнейшем, к этой платформе можно было бы привлечь конкурирующие площадки и другие смежные организации.
Решение
По сути перед нами встала задача создать децентрализованную систему обмена данными (далее Платформа) в рамках консорциума — т.е. закрытого сообщества участников. Хотя в нашем случае, речь шла о системе, в которой доступ к данным предоставляется всем участникам, мы решили подойти к задаче шире и создать систему, в рамках которой пользователи могли бы сами решать, кому из участников системы они хотят предоставить доступ к данным, а кому нет.
В качестве технологической базы проекта был выбран Multichain так как данная платформа изначально спроектирована с поддержкой консорциума как основного режима работы и содержит удобные средства работы с блокчейном как хранилищем данных. Сама Платформа, реализующая интерфейс обмена данными и средства разграничения доступа к данным, разработана на платформе .NET.
Основные характеристики разработанного решения:
- Данные распределяются между всеми узлами системы, ни один из участников системы не может сфальсифицировать или удалить данные, однажды выданные другому участнику, а также отсутствует единая точка отказа. Даже при физическом отключении узла участника от сети, данные, полученные до момента отключения, остаются на этом узле и доступны для работы с ними, а при восстановлении подключения происходит получение данных, появившихся во время отсутствия узла в сети.
- Используется закрытый блокчейн (консорциум) – т.е. для подключения к нему требуется либо согласование узлом-координатором, либо, если выбрана консенсусная модель администрирования – всеми участниками сети.
- После подключения, участник консорциума может создавать как публичные (доступные всем участникам), так и закрытые (доступные выбранному кругу участников) коллекции данных. Безопасность закрытых данных обеспечивается посредством криптозащиты данных с помощью ГОСТовских алгоритмов.
- Управлять доступом к коллекции может лишь ее создатель.
- При добавлении к списку доступа уже существующей коллекции нового участника, опубликованные ранее данные становятся ему доступны автоматически.
- При удалении участника из списка доступа новые опубликованные данные будут ему недоступны.
- Платформа поддерживает структурирование данных в коллекции в формате JSON и валидацию формата документа в ней по JSON-схеме.
- Платформа предоставляет АПИ, изолирующий пользователя от деталей реализации самого блокчейна и позволяющий работать с понятиями более высокого уровня («документ» и «коллекция»).
- Платформа не предусматривает удаления данных, таким образом, ни один участник не может удалить документ из коллекции, доступной другим участникам.
- При обновлении документа, сохраняется полная история его изменений, и есть возможность получения любой из версий документа.
- Платформа поддерживает отправку внешним системам участника настраиваемых уведомлений об изменении/обновлении данных в интересующей коллекции, таким образом, информационные системы одного участника могут оперативно реагировать на обновления данных, сделанные информационными системами другого участника.
Как видите список довольно внушительный. Конечно, у системы есть и некоторые недостатки, о которых мы знаем: например, если мы один раз дали кому-то доступ к данным, можно предположить, что эти данные он уже скопировал и может отдать кому-либо еще, но это уже вне контроля нашей системы. Однако, такого рода риски есть у любой системы. Еще одним недостатком системы, обусловленным использованием блокчейна и необходимостью операций шифрования/дешифрования данных на лету, является общая пропускная способность, составившая ~30 транзакций в секунду, что оказалось более чем достаточно для конкретной задачи, но может являться ограничивающим фактором для применения Платформы в ряде других сценариев.
Что касается принципа работы механизма управления доступом к данным, то он основан на гибридной схеме шифрования:
- Зарегистрированный участник системы получает публичный и приватный ключ. Публичный ключ каждого участника является общедоступным и публикуется в блокчейне.
- Участник №1 создаёт новую коллекцию и определяет, с кем из участников системы он хотел бы поделиться её содержимым (Участник №2 и №3), затем добавляет в эту коллекцию документ.
- Платформа шифрует документ сгенерированным симметричным ключом (это значит, что для расшифровки потребуется тот же ключ, что и для шифрования). Такой ключ имеет значительно меньший объем, чем, сам зашифрованный документ.
- Платформа извлекает из блокчейна публичные ключи участников №2 и №3 и шифрует ими симметричный ключ, и помещает результаты в блокчейн.
- Участники №2 и №3 входят в систему и пытаются просмотреть содержимое коллекции. Платформа расшифровывает приватными ключами участников №2 и №3 симметричный ключ, после чего этим ключом расшифровывает документ. Таким образом участники №2 и №3 получают доступ к его содержимому.
Так выглядит схема работы в общем случае. Если же рассматривать конкретную реализацию, выполненную для нашего заказчика она выглядит так:
- Участник проходит регистрацию в Учётном центре (далее УЦ№1), подавая все необходимые документы и данные.
- Учётный центр выдаёт участнику электронную подпись и привязывает к ней все подданные им данные, складывая всё это в блокчейн.
- Когда участник заходит на площадку по государственным закупкам (далее Площадка №1), она извлекает его регистрационные данные из Коллекции, созданной УЦ№1.
- Возможна ситуация, когда площадке не хватит этих данных и она запросит дополнительные или же захочет хранить другую информацию (например, историю участия в торгах) по конкретному клиенту, чтобы поделиться ей с другой дружественной площадкой. В этом случае, она создаёт в блокчейне новую коллекцию с этими дополнительными данными.
- Когда Участник решает зарегистрироваться на Площадке №2 она также берёт его регистрационные данные из коллекции УЦ №1 или же из коллекции созданной Площадкой №1
Итог
На данный момент наше решение внедрено и успешно работает. Если у вас есть вопросы или замечания – пишите в комментарии, будем рады ответить или подискутировать.
Комментарии (46)
Napitok Автор
04.09.2017 13:08При добавлении нового пользователя доступ к коллекции ему предоставляет её владелец. По сути он свои приватным ключом расшифровывает симметричный ключ и шифрует его публичным ключом нового пользователям, которому предоставляет доступ. Тот уже своим приватным ключом расшифровывает симметричный ключ и получает доступ к содержимому коллекции.
На уровне ядра системы мы не оперируем такими понятиями как «Группа», возможно это будет добавлено в будущем
a_shats
04.09.2017 13:26У меня нескромный вопрос. В рамках блокчейна все транзакции, по идее, должны быть видны всем участникам (пусть и зашифрованные). То есть каждый, вступивший в систему, получит в своё хранилище не только «свои» транзакции, а вообще все.
Или у Вас как-то не так?vpelipas
04.09.2017 14:17Естественно, все транзакции видны, но данные в них — зашифрованы, таким образом получить доступ к ним не получится, пока Вам не выдадут ключ для дешифровки данных.
SergeyGrigorev
04.09.2017 15:20Т.е. фактически не решен вопрос прозрачности гос. закупок? Ведь мы можем всё равно скрыть данные о том, кто что выполнил, и насколько качественно, если эти данные видны лишь им двоим. А захочет третий заказчик иметь дело с ними, но их история им недоступна. Тут должно быть как раз таки всё прозрачно, видеть кто, когда и что именно выполнил, в каких масштабах. Разве нет?
vpelipas
04.09.2017 15:27Решение задачи прозрачности госзакупок — вне скоупа данной системы, более того — эта задача уже давно решена на гос. уровне — существует ЕИС (http://zakupki.gov.ru/epz/main/public/home.html) где публикуются все данные о госзакупках. Данная система была разработана для решения задачи KYC (Know Your Customer) между различными, в том числе — конкурирующими друг с другом — площадками. Т.е. речь идет не о хранении данных о закупках, а об обмене данными о клиентах площадок между этими площадками.
vvromanov
04.09.2017 14:35Какая производительность получается? Сколько времени занимает фиксация транзакции?
Napitok Автор
04.09.2017 15:18Все зависит от железа. На стенде (Core i5, 8Gb, SSD) если «напрямую» с блокчейном через RPC-call то получается порядка 250 записей в секунду на чтение и 160 записей в секунду на запись. Если через API с применением шифрования на той же конфигурации, получаем цифры 32 и 12 записи в секунду соответственно. Да, это немного, есть над чем поработать, главным образом — над оптимизацией работы с json объектами.
GaasForever
04.09.2017 15:18Планируем делать похожий проект, но для производства, собираем команду. Какой набор скилов нужен, какие роли, какими силами вы проект запустили, без коммерческой информации, в-общем если можно?
vpelipas
04.09.2017 15:35Мы эту Платформу реализовали довольно небольшой командой — архитектор и 2 разработчика — примерно за полгода. Скиллы — зависит от того, какую блокчейн-платформу и целевую платформу Вашего решения Вы выберете, но в целом — кроме общих скиллов разработчиков необходимо хорошо понимать детали работы выбранной блокчейн-платформы и иметь опыт работы с криптосредствами.
GaasForever
04.09.2017 17:45Еще момент, а не думали хранить в блокчейне только хэш конфиденциальной информации, а саму инфу хранить только в тех нодах, у которых есть доступ?
vpelipas
04.09.2017 17:58Целью было распределенно хранить саму информацию, а не только производные данные, способные подтвердить сам факт наличия этой информации, поэтому такой вариант не рассматривался.
artemmityushov
04.09.2017 15:48+2Прочитал и подумал, а причем тут блокчейн? Ну вот реально, вы по-моему просто используете этот хайповый термин. Судя по описанию обычное серверное приложение со своими рюшечками.
Napitok Автор
04.09.2017 16:33Не могу согласиться. Наше решение поддерживает децентрализованность, достоверность и версионность данных. Можно конечно задаться целью и реализовать всё это в обычном серверном приложении, но зачем, если в технологии блокчейн эти вопросы уже решены?
mosinnik
04.09.2017 20:01Вы указали, что система продолжает работать при обрывах связи, разъясните, а что будет при сплите сети?
Как я понял платформ-узлов в сети не так много. Представьте ситуацию, что одна платформа засинкалась, потом ее узел перестал общаться с внешним миром, но не утерял возможности работать с клиентами. Тогда после некоторой небольшой работы с данной платформой, пользователь уверен, что все данные сохраняются. Однако блочейн же выберет самую длинную цепь подтвержденную большинством без всяких мержей, соответственно, все что было сделано на этом отдленном узле будет потеряно. Как с этим боретесь?
Аналогично как решаются следующие вопросы в случае, когда нода ушла в отрыв:
— предоставления актуальной информации
— считает ли нода себя потерянной и всячески сигналит, не давая менять данные, что она отвалилась, или просто продолжает работать
— есть ли минимальнео количество нод для «кворума»strogen
05.09.2017 11:20Спасибо за Ваш вопрос.
Для нас решение этих задач является приоритетным. В настоящее время реализовано через проверку подключения ноды к системе. Если подключения нет — запись не возможна.
С другой стороны, специфика хранения данных (в Multichain это потоки) при восстановлении подключения позволяет смержить данные. А в виду того, что это не платежные транзакции, то угрозы двойного расхода нет. К тому же все тот же поток позволяет хранить историю изменений по уникальному ключу документа.
Что касается минимального количество нод для «кворума», то этот параметр настраивается при создании блокчейна в зависимости от требований.
Regis
04.09.2017 20:30Как обрабатывается ситуация с компрометацией приватного ключа агента (участника)?
strogen
05.09.2017 10:46Для подобных случаев разработан механизм версионности. Т.е. если нам надо у участника забрать права доступа, то владелец коллекции выпускает новый ключ шифрования и раздает его тем участникам, у которых доступ остался. Т.о. все записи, которые были сделаны ранее, участнику, лишенного прав, будут доступны как и ранее, а новые уже нет.
strogen
05.09.2017 12:24На данный момент не так много порядка нескольких ГБ (в тестах было до 500ГБ). Блокчейн сторится в файловой системе в виде файлов. Поэтому и масштабируеться как файловый datastore.
artemmityushov
05.09.2017 13:50И в перспективе сколько? 500 гигов на каждую машину это уж слишком перебор. По сути своей это и плюс и минус блокчейна.
DuD
05.09.2017 14:29Вопрос как раз в том, когда он разрастется до 500Гб, а произойдет это, как мне кажется гораздо быстрее чем у простой криптовалюты. И что делать когда он на столько сильно разрастется? Не бомба ли это замедленного действия?
strogen
05.09.2017 14:56Однозначно быстрее, ведь мы храним информацию о бизнес объектах, а их размер зависит только от требований к структуре данных.А делать только одно — добавлять диски :) Мы же понимаем с вами, что это решение enterprise уровня.
artemmityushov
05.09.2017 15:08А причем здесь диски то? У вас разве нет копии на каждой локальной машине? Это же суть блокчейна, независимость от единого источника.
strogen
05.09.2017 15:12На каждой машине, где развернута нода блокчейна добавляем диски по мере того, как заканчивается свободное место. Относитесь к этому как к datastorage
artemmityushov
05.09.2017 15:29Ничего что эта копия должна быть на каждом клиенте так то, в этом суть.
А если этого нет, если у вас все ноды контролируются вами, то у вас просто зеркалирование базы данных, это не блокчейн т.к. вы нарушаете ее основной принцип.
В общем вернувшись к моему первому комментарию — у вас обычное распределенное приложение, блокчейн здесь просто красивое модное слово.
Рекомендую перечитать, если не читали
habrahabr.ru/company/kaspersky/blog/336036vpelipas
05.09.2017 16:17Давайте еще раз поясню, если это необходимо.
Данные хранятся именно в блокчейне, реализованном на базе Multichain, детали его реализации — не вижу смысла повторять, они описаны на www.multichain.com, в общем, классический блокчейн, за базе того же биткойновского ядра. Но работать с голым блокчейном для хранения данных не слишком удобно, поэтому поверх блокчейна нами реализован слой доступа к данным, который дает:
1) удобный интерфейс доступа к данным, а-ля документ-ориентированная БД
2) шифрование/дешифрование информации православными ГОСТовыми алгоритмами (это было важно для нашего клиента)
3) механизм подписки на обновления данных.
Именно это расширение и есть наша разработка, сам Мультичейн — открыто распространяемая опенсорсная блокчейн-платформа, мы к его созданию отношения не имеем, мы его используем. По этому странно видеть Ваше негодование, что это не блокчейн — ну ОК, исходные коды этого «неблокчейна» открыты, приведите, что именно в них заставляет Вас так думать?
По поводу контроля за нодами — наша система представляет собой не открытый блокчейн, а консорциум, что и оговорено в статье. Соответственно, контроль за узлами — в руках администраторов этих узлов, в нашем случае — ряда организаций. Но круг этих организаций — ограничен, и каждый новый узел должен получить разрешение других узлов, либо одного уполномоченного узла(в зависимости от настроек чейна), на подключение к системе. Опять же, если интересны детали — могу посоветовать обратиться к документации Мультичейна, там все подробно изложено.artemmityushov
05.09.2017 16:26Если в названии продукта который вы используете есть частичка chain и они себя чем-то называют это не делает их тем чем они являются.
У вас модифицированное что-то там как-то там и пусть называется chain, но оно не соответствует критериям блокчейна, в статье которую я привел все предельно понятно изложено.
Основная претензия в том что вы пишите «Практическое применение блокчейна как распределенного хранилища данных», но это лукавство и игра слов на тренде. Распределенная система — Да, но не классический блокчейн.vpelipas
05.09.2017 16:34Простите, мне сложно с Вами дискутировать не понимая вашего профессионального бэкграунда. Если вы разработчик — то вот вам исходные коды системы — github.com/MultiChain/multichain — скажите, что именно в них наводит вас на мысль, что это НЕ блокчейн?
Если Вы не разработчик — «то начнем издалека» (с). Что, по-вашему, блокчейн?
andreykour
05.09.2017 14:01Подскажите, а что с лицензированием/сертификацией криптографии, Multichain вряд ли имеет лицензии/сертификацию от ФСБ/ФСТЭК?
strogen
05.09.2017 14:44Вот это как раз один из моментов, почему нам пришлось реализовывать «тяжелые» api. Вся работа с шифрованием данных происходит в бизнеслогике по ГОСТ с использованием CryptoPro.
andreykour
05.09.2017 14:55а может тогда опишите чуть подробнее как удалось подружить Multichain и CryptoPro? с какими проблемами столкнулись, и как разрешили?
strogen
05.09.2017 15:06Нет, не совсем так. Multichain и CryptoPro мы между собой не дружили. Multichain вообще про CryptoPro ничего не знает. На уровне транзакций он (Multichain) как работал со своей криптографией, так и работает (secp256k1). Мы же на уровни бизнес логике перед записью в Multichain данные зашифровываем, а после чтения из него — расшифровываем.
Изначально мы думали над тем, чтоб реализовать поддержку crypto.pro на уровне ядра в Multichain, но тут дрогнула рука у нас.andreykour
05.09.2017 15:42Получается у вас используется двойное шифрование? сначала по ГОСТу, а потом сверху secp256k1? Юридически такой вариант прорабатывали?
P.S. Понимаю вопросы не очень технические и не очень приятные, но они по сути без их решения в бизнес задачах вряд ли как то будут решаться…vpelipas
05.09.2017 16:30Да, именно так. Если мы хотим получить блокчейн с гостовой криптографией — у нас есть 3 пути:
1) запилить все с нуля — очевидно, это долго, дорого и не очень надежно, т.к. вряд ли получится быстро набрать такую пользовательскую базу (читай, халявных тестировщиков), как популярные открытые проекты. Поэтому примеров таких решения я даже и не вспомню сейчас.
2) попробовать адаптировать готовую популярную платформу под православную криптографию — этим путем пошел Центробанк в своем проекте Мастерчейн (http://fintechru.org/Masterchain_whitepaper_11_08.pdf)
3) Перейти на уровень выше и рассматривать блокчейн просто как специфичный слой хранения данных, со всеми его преимуществами и недостатками, с которым обмениваться уже шифрованными/подписанными данными.
Мы в решили попробовать третий подход.
Napitok Автор
05.09.2017 18:54Коллеги, если Вам интересна наша система или есть вопросы которые Вы хотели бы обсудить тет-а-тет — у меня в профиле указаны контакты — пишите, будем рады сотрудничеству.
MaxxxZ
06.09.2017 17:20Если все полностью децентрализовано, то как участник блокчейн находит остальные сервера, чтобы распространить им информацию о записи в блокчейн?
хотелось бы подробнее узнать алгоритм поиска соседних нод.
strogen
06.09.2017 20:37Первое и обязательное условие, чтобы новая нода начала работать в системе, необходимо при первом ее запуске указать адрес ноды администратора (помните, у нас PoA), после чего на ноде администратора дать права подключаемой ноде. А дальше каждая нода «знает» об остальных нодах системы и вход вступает p2p.
Malligan0
Что делать с участниками, которые появятся после создания коллекции? Нет ничего похожего на группы, теги, или более комфортные аналоги в рамках такой задачи, если такие существуют?
Napitok Автор
Простите, не туда ответил