×Закрыть

DOU Labs: как в Provectus разрабатывают блокчейн-фреймворк для взаимодействия в среде без доверия

В рубрике DOU Labs мы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

О технологии блокчейн много говорят в рамках темы криптовалют, но ее применение для других потребностей обычно освещается не так часто. В этой статье я расскажу об особенностях использования технологии блокчейн для бизнеса и о фреймворке для децентрализованных решений, который создает наша команда в 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 и т. д.) как модулей нижнего уровня.

LinkedIn

9 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Коли хтось почне це використовувати, було б прикольно про це дізнатись.
Якщо ще дійдуть руки, можна бути спробувати переписати блокчейн виділивши більше потужності для PoW.

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

Как вы планируете решать вопрос,

GDPR Right to erasure (‘right to be forgotten’)

---- ---- ---- ---- ----

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

<сарказм>но вы же по сути привязались к Ethereum Clique<сарказм>

---- ---- ---- ---- ----

Записи невозможно изменить или подделать, поэтому все стороны защищены от фальсификаций.

Даже PoA дает возможность переписать цепочку блоков и 100% гарантии блокчейн решения не дают.

Поддержка Right to erasure в системе может обеспечиваться через логирование требований пользователя быть забытым. Как вариант, пользователю можно высылать подтверждение принятия запроса «забудь меня» с цифровой подписью компании, владеющей узлом и хранящей данные подлежащие удалению. Хеш от этих данных опускаем на блокчейн, обеспечивая неизменную цифровую метку. С тем же блокчейном и системой смарт контрактов также работают аудиторы, через которых можно решать спорные вопросы. Конечно этот процесс должен быть поддержан еще и юридически.
Привязки к Ethereum и тем более конкретному типу консенсуса на самом деле нет. Использование Ethereum mainnet, например, технически решается сменой настроек запуска geth github.com/...​eum/go-ethereum/wiki/geth как нижнего модуля. В случае же необходимости использования совершенно другого протокола и реализации блокчейна, к примеру Hyperledger Fabric , задача сводится к разработке адаптера для API нижнего уровня и автоматизации развертывания, что не затронет ядро системы работающее с блокчейном на абстракциях. Опять же, тут мы говорим про выбор модуля блокчена для фреймворке до старта реализации решения. В случае уже работающего решения такая смена типа блокчейна может оказаться намного сложнее или нецелесообразной по соотношению цена/выгода.

По поводу утверждения что PoA дает возможность переписать цепочку блоков, зависит от какую ситуацию мы рассматриваем. Если все владельцы узлов в сети договорятся изменить историю задним числом, то это возможно. Но это скорее всего только в том случае, если они хотят обмануть внешних пользователей (что, кстати, минимизируется через тот же анкоринг на криптовалютные сети или подключения публичных узлов только для чтения). Одному же из узлов переписать цепочку в свою пользу по прежнему практически невозможно.

Интересная тема!

Спасибо, очень интересная статья.

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

Скажите, пожалуйста, какой механизм консенсуса вы использовали? Этот момент, похоже, важен, так как этот алгоритм позволяет осуществлять взаимодействия в среде без доверия, объединить не доверяющие друг другу узлы в среду.

Добрый день. Текущем базовом варианте модуль блокчейн пира это Ethereum, который использует механизм консенсуса Clique Proof-of-Authority github.com/ethereum/EIPs/issues/225. В нем не подбираются хеши (нет майнинга, поскольку он не обязателен в этом случае). Решается поочередной подписью блоков участниками, входящими в список так называемых силлеров. В данный момент все это разворачивается как приватная сеть между узлами, но достаточно легко можно, например, развернуть те же смарт контракты на модификации Ethereum с другим типом консенсуса или даже публичной сети.

Интересный проект, так держать, молодцы. Архитектурно — вы используете собственную сеть Ethereum, приватную? Или mainnet? И второй вопрос — не кажется ли вам, что такая архитектура слишком сложная (много компонент, разные языки и т.п.). Можно было, наверное, взять тот же Exonum и дописать туда модули, взамен получив все его фишки. И да, у вас нет анкоринга в другой блокчейн, чтобы предотвратить коррекцию задним числом?

Добрый день, Александр. По типу сети ответил выше. Закладывая архитектуру мы не хотели привязываться к определенному типу блокчейна, поскольку сложно предсказать будущие продукты и их потребности на основе фреймворка. Кому-то из клиентов может принципиально не подойти Exonum по техническим или другим причинам. Однако это не мешает нам сейчас добавить/заменить Exonum как модуль. По поводу же анкоринга — это хорошая идея в Exonum. Мы тоже рассматривали ее еще более года назад. При необходимости можем реализовать на уровне бизнес-логики при потребности в юз кейсе, имея на нижнем уровне комбинацию модулей приватного и публичного блокчейна.

Подписаться на комментарии