DOU Labs: как в Provectus разрабатывают блокчейн-фреймворк для взаимодействия в среде без доверия
В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. .
О технологии блокчейн много говорят в рамках темы криптовалют, но ее применение для других потребностей обычно освещается не так часто. В этой статье я расскажу об особенностях использования технологии блокчейн для бизнеса и о фреймворке для децентрализованных решений, который создает наша команда в Provectus.
В конце статьи я приведу пример применения нашего фреймворка. Мы рассмотрим, как с помощью блокчейна можно решать актуальную сейчас проблему — соответствие требованиям GDPR. Это европейский закон о защите персональных данных.
Идея
Мы решили разработать фреймворк для децентрализованного управления данными, который поможет компаниям и людям взаимодействовать в среде без доверия. Технология блокчейн в силу своих особенностей отлично подходит для решения этой задачи. Отсутствие единой точки контроля в блокчейн-сетях дает ряд преимуществ.
В централизованных системах компании и люди, работая друг с другом через интернет-сервисы, обычно доверяют им как посредникам. Например, два пользователя общаются и обмениваются данными в социальной сети. Их профили, история переписки, факты передачи сообщений и файлов, привязка их к дате и времени хранятся на серверах под управлением одного администратора. Аналогично, один администратор управляет информацией, если это будет реестр прав на интеллектуальную собственность, недвижимость, реестр долговых обязательств, записи в цепочке поставок товаров... Во власти администратора отдать предпочтение записям от определенных участников, удалить или изменить запись задним числом, изменить баланс правил в чью-то пользу, сделать сервис недоступным в определенный момент. Администратор удобен внешним силам, заинтересованным в изменении правил. Оказывать давление на одного человека или компанию проще, чем на сообщество.
В блокчейн-сетях администратор отсутствует. Любой блокчейн можно воспринимать как базу данных с управляющей логикой (кодом) для этих данных. Наиболее частое название для управляющего кода — смарт-контракт. Его копия, также как и копия данных, распределенно хранится на каждом узле. Соответственно, каждый узел может и, как правило, независимо вычисляет результат каждой транзакции. Физическое владение и административные права на каждый отдельный узел принадлежат разным компаниям или людям. Транзакции объединяются и упорядочиваются в блоки. Каждый блок сформирован одним из участников, который, в свою очередь, динамически определяется децентрализованным алгоритмом консенсуса.
Вопрос аутентификации участников и верификации каждой транзакции решается при помощи алгоритмов цифровой подписи и криптосистем с открытым ключом. Для таких систем нет необходимости в центральном хранении паролей и учетных записей.
Получив такой тип базы данных в технологическом стеке, можно решать задачи взаимодействия, но уже через принципиально другой подход: доверие центральному узлу переносится на математику открытого алгоритма. В итоге доверие кому-либо не требуется в принципе.
Реализация и архитектура фреймворка
Блокчейн как технология имеет ряд серьезных недостатков по производительности, масштабируемости, управляемости и стоимости поддержки по сравнению с централизованными решениями. Однако, получая децентрализованные решения, бизнес, скорее всего, не будет готов к таким ограничениям по этим характеристикам.
Понимая это, в разработке мы руководствовались принципом использования блокчейна в той мере, которая необходима для достижения децентрализации, но не более того. Тот функционал решений, который нецелесообразно реализовывать через блокчейн, должен быть вынесен в другие технологии. Список и требования к этим технологиям могут меняться в зависимости от конкретного решения. Это касается и применения конкретного блокчейн-протокола и типа блокчейн-сети.
Таким образом, мы пришли к необходимости модульной и многоуровневой структуры узлов для децентрализованных решений.
Компоненты узла в базовом варианте
На нижнем уровне узла, в базовом варианте, находятся четыре модуля:
- Реализация Ethereum блокчейн-протокола в варианте geth. Выбор в пользу Ethereum был сделан из-за наличия большого сообщества, хорошей динамики развития, а также сильной команды и поддержки в лице организации Ethereum Foundation.
- База данных MongoDB c GridFS. Многие реализации потребуют хранения данных. Хоть блокчейн, по своей сути, и является децентрализованной и отказоустойчивой базой данных, но хранение многих данных в нем нецелесообразно с точки зрения как минимум производительности. Таким образом, мы остановили выбор на этой широко используемой базе данных.
- Менеджер очередей RabbitMQ. Записи во многие блокчейн-базы данных требуют существенного времени из-за особенностей механизмов консенсуса, что может не укладываться во время, необходимое для отклика на вызов API узла. Реакция на события, происходящие при записи компаниями-партнерами в блокчейн, также может потребовать обработки этих событий в нужном порядке. Понимая, что нам понадобится функционал очередей и отложенной работы, мы выбрали RabbitMQ как одно из наиболее популярных решений.
- Модуль для хранения криптографических ключей. Для работы с блокчейн-протоколом и шифрованием в базах данных нужно хранить и управлять криптографическими ключами разных типов. В данный момент мы поддерживаем опцию проприетарного менеджера ключей и завершаем работу над опцией альтернативного модуля, удовлетворяющего критерии свободного ПО. Первый вариант необходим там, где может понадобиться такая сертификация, как FIPS
140-2.
Модули могут заменяться на альтернативные, а фреймворк может содержать более одного модуля одного типа, если это необходимо для конкретного решения.
Над уровнем модулей находится нижний уровень API, которые поддерживают JSON-RPC интерфейс и работают с данными многих модулей посредством ORM-моделей.
Верхний уровень API представляет собой HTTP- и WebSocket-сервер, защищенный посредством TLS и предоставляющий публичные интерфейсы как для внешних приложений, так и для административного web UI. Запросы к интерфейсам валидируются в DMS-модуле и проксируются для запуска бизнес-логики. Она запускается в изолированной среде, легко кастомизируется под конкретного заказчика и работает с API нижнего уровня. При этом для разработки бизнес-логики не обязательно нужны экспертные знания блокчейн-технологии и других модулей самого нижнего уровня.
При необходимости избежать издержек верхнеуровнего API и запуска бизнес-логики, клиентскому приложению может быть предоставлен прямой доступ к API нижнего уровня.
Конечно, если речь идет о децентрализованном подходе, то система, как правило, не может ограничиваться единственным узлом. В нашем сценарии решений на базе фреймворка каждая компания-партнер получит возможность развернуть узел на сервере под своим полным контролем. Такой узел будет взаимодействовать с другими узлами сети на уровне блокчейн-протоколов и, возможно, через API вызовы между узлами (например, обмен данными между партнерами).
Пример взаимодействия двух узлов
Кроме того, в децентрализованных сетях с ограниченным кругом участников (что часто необходимо в бизнесе для ограниченного круга компаний-партнеров) процесс ввода и вывода новых узлов обычно предусматривает некие механизмы демократического голосования. Для этого, также как и для развертывания новых узлов, во фреймворке существует модуль System Manager, который представляет собой набор DevOps-скриптов и аналитическую систему реагирования на аварийные ситуации.
Децентрализованная сеть на базе фреймворка
Команда и технология для разработки
Основной технологией фреймворка стала NodeJS. Мы выбрали ее по двум причинам: достаточное количество разработчиков на рынке и большое профессиональное сообщество.
Команда формировалась на протяжении последнего года, и в ее состав сейчас входит шесть человек: Sales Manager, Tech Lead, Senior NodeJS и Junior NodeJS разработчики, тестер и блокчейн-эксперт.
Из-за небольшого состава команды, некоторым участникам приходится совмещать несколько ролей. Например, наш тестер выполняет некоторые функции Project Manager’a; техлид, кроме контроля стандартов разработки, выполняет задачи по Backend-разработке и DevOps; блокчейн-эксперт пишет смарт-контракты, тесты и API для взаимодействия с ними.
Также мы привлекаем на разовые работы Frontend-разработчиков, дизайнера и DevOps.
Пример применения фреймворка для GDPR
Говоря про фреймворк, нельзя не дать конкретные примеры решений на его базе. В этом году стал актуальным вопрос GDPR (General Data Protection Regulation) — это принятый в ЕС акт о защите персональных данных. Он вступил в силу 25 мая. Помимо прочих пунктов, положения GDPR обязывают компании использовать персональные данные пользователя только с его разрешения и прекращать их использование по его требованию.
Решение на базе нашего фреймворка позволяет создать неизменяемый журнал передачи прав на использование персональных данных от пользователя к определенной компании. Записи невозможно изменить или подделать, поэтому все стороны защищены от фальсификаций. Пользователи и компании получают достоверный механизм логирования, работу которого может проверить владелец, потребитель и аудитор данных. Это обезопасит стороны в случае разбирательств и споров.
Следует отметить, что в GDPR не прописаны требования ни к децентрализации, ни к использованию технологии блокчейн. Можно использовать и централизованные системы, но в них сложнее решить вопрос достоверности и неизменности записей.
Результаты и планы
Наш фреймворк вошел в стадию бета-тестирования, в которой мы интегрируемся с разными заказчиками, собираем обратную связь и вносим незначительные правки.
В наши ближайшие планы входит проведение нагрузочных тестов, реализация API для других блокчейн-протоколов, баз данных и систем хранения ключей, создание системы версионирования на разных уровнях, R&D работа по возможности использования децентрализованных баз данных (Swarm, IPFS и т. д.) как модулей нижнего уровня.
