Блокчейн – технология о которой сейчас говорят все вплоть до домохозяек, пишут газеты и журналы. Если забыть о хайпе и не добавлять в проект блокчейн ради блокчейна, то оправданным его применение будет далеко не всегда. Нам посчастливилось столкнуться именно с такой ситуацией. К нам обратился один из наших крупных заказчиков – компания, предоставляющая услуги площадки по электронным госзакупкам.
Регистрация на площадке по государственным закупкам процесс достаточно бюрократизированный. Исполняя требования законодательства и реализуя принцип Know your customer (KYC), площадкам и удостоверяющим центрам приходиться собирать множество документов, подтверждающих личность клиента и происхождение средств. У компании-заказчика возникла идея, создать сервис единовременной аккредитации на всех площадках по государственным закупкам регулируемых разными законами — создать единый профиль контрагента (это позволило бы собрать необходимые документы только 1 раз). Такой сервис был бы полезен всем – пользователи после регистрации на любой площадке получили бы возможность работать со всеми остальными без дополнительной волокиты; площадки получили бы новых пользователей, за счёт упрощения регистрации. В дальнейшем, к этой платформе можно было бы привлечь конкурирующие площадки и другие смежные организации.
По сути перед нами встала задача создать децентрализованную систему обмена данными (далее Платформа) в рамках консорциума — т.е. закрытого сообщества участников. Хотя в нашем случае, речь шла о системе, в которой доступ к данным предоставляется всем участникам, мы решили подойти к задаче шире и создать систему, в рамках которой пользователи могли бы сами решать, кому из участников системы они хотят предоставить доступ к данным, а кому нет.
В качестве технологической базы проекта был выбран Multichain так как данная платформа изначально спроектирована с поддержкой консорциума как основного режима работы и содержит удобные средства работы с блокчейном как хранилищем данных. Сама Платформа, реализующая интерфейс обмена данными и средства разграничения доступа к данным, разработана на платформе .NET.
Основные характеристики разработанного решения:
Как видите список довольно внушительный. Конечно, у системы есть и некоторые недостатки, о которых мы знаем: например, если мы один раз дали кому-то доступ к данным, можно предположить, что эти данные он уже скопировал и может отдать кому-либо еще, но это уже вне контроля нашей системы. Однако, такого рода риски есть у любой системы. Еще одним недостатком системы, обусловленным использованием блокчейна и необходимостью операций шифрования/дешифрования данных на лету, является общая пропускная способность, составившая ~30 транзакций в секунду, что оказалось более чем достаточно для конкретной задачи, но может являться ограничивающим фактором для применения Платформы в ряде других сценариев.
Что касается принципа работы механизма управления доступом к данным, то он основан на гибридной схеме шифрования:
Так выглядит схема работы в общем случае. Если же рассматривать конкретную реализацию, выполненную для нашего заказчика она выглядит так:
На данный момент наше решение внедрено и успешно работает. Если у вас есть вопросы или замечания – пишите в комментарии, будем рады ответить или подискутировать.
Задача
Регистрация на площадке по государственным закупкам процесс достаточно бюрократизированный. Исполняя требования законодательства и реализуя принцип 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
Итог
На данный момент наше решение внедрено и успешно работает. Если у вас есть вопросы или замечания – пишите в комментарии, будем рады ответить или подискутировать.
