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

У рубриці DOU Labs ми запрошуємо IT-компанії ділитися досвідом власних цікавих розробок і внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на [email protected] .

Про технології блокчейн багато говорять в рамках теми криптовалют, але її застосування для інших потреб зазвичай висвітлюється не так часто. У цій статті я розповім про особливості використання технології блокчейн для бізнесу і про фреймворку для децентралізованих рішень, який створює наша команда в 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 і т. д.) як модулів нижнього рівня.

Опубліковано: 19/07/18 @ 07:00
Розділ Різне

SEO Блог