Краткое введение о том, как это началось
Некоторое время назад мне было предложено создать децентрализованное приложение на блокчейне, доступное для пользователей не только с их ноутбуков (устройства с высокой вычислительной мощностью), но и с их смартфонов (устройства с низкой вычислительной мощностью и флэш-памятью). требуется высокая вычислительная мощность, было нецелесообразно запускать узел Blockchain на устройстве пользователя. Итак, что мы сделали, так это изменили наш подход к созданию децентрализованных приложений, и я считаю, что это тоже будущее децентрализованных приложений. Потому что он масштабируемый, доступный и более удобный для пользователя.
Что такое гибридная архитектура?
Одним словом, это «архитектура децентрализованного приложения в сочетании с альтернативной централизованной архитектурой, которая является классической архитектурой клиент-сервер».
По сути, приложение, созданное с использованием этой архитектуры, будет использовать один и тот же внутренний код, который, скорее всего, будет умным контрактом, и пользователь будет взаимодействовать с этим внутренним интерфейсом через 2 интерфейса, которые будут обслуживать разные наборы клиентов следующим образом:
- Централизованная часть — это интерфейс, обеспечиваемый классическим клиент-серверным подходом. Здесь создается сервер, который действует как переводчик между клиентом и блокчейном. Роль сервера заключается в предоставлении интерфейса REST, который преобразует веб-транзакцию в транзакции блокчейна. Любой клиент, который хочет совершить транзакцию через этот интерфейс, может войти в веб-приложение, и его опыт будет аналогичен опыту любого веб-приложения, такого как Facebook, Google и т. д., но транзакция теперь будет происходить в блокчейне. Этот способ совершения транзакции может использоваться устройствами с низкой вычислительной мощностью, такими как смартфоны.
- Децентрализованная часть — это интерфейс, предоставляемый самой цепочкой блоков. Любой клиент, который хочет совершить транзакцию через этот интерфейс, может запустить узел блокчейна на своем устройстве и совершать транзакции, напрямую участвуя в сети Blockchain. Этот способ совершения транзакции может использоваться устройствами с высокой вычислительной мощностью, такими как ноутбуки.
Низкоуровневое проектирование гибридной архитектуры
Давайте разберемся с архитектурой с помощью некоторых визуальных иллюстраций. Мы будем использовать сервер nodeJS и набор узлов блокчейна на основе Ethereum для создания нашей гибридной архитектуры. Мы предполагаем, что система управления отпусками построена с использованием этой архитектуры (в следующей части мы расскажем, как все это построить вместе с кодом :)). Допустим, пользователь хочет подать заявление на отпуск, мы увидим поток транзакции в обоих случаях.
Случай 1: клиент заполняет форму для выхода с необходимыми данными и нажимает кнопку отправки в веб-интерфейсе. Отсюда запрос отправляется на сервер NodeJS, где клиент аутентифицируется с использованием данных, хранящихся в базе данных SQL, после чего запрос направляется на любой из узлов блокчейна через балансировщик нагрузки, и транзакция происходит в блокчейне, и ответ возвращается пользователю как успешный!.
Вариант 2: пользователь запускает узел Ethereum на своем устройстве и подает заявку на отпуск, выполняя прямую транзакцию в блокчейне с правильными данными.
Текущие ограничения этой архитектуры
Одним из ключевых ограничений этой архитектуры является то, что для ее работы нам необходимо убедиться, что достаточное количество пользователей совершают транзакции непосредственно в блокчейне, т.е. они запускают блокчейн. Это необходимо для обеспечения того, чтобы объект, контролирующий архитектуру клиент-сервер, Не делать известную атаку 51%.
Во-вторых, в настоящее время мы храним закрытый ключ клиента на сервере, что вызывает проблемы с безопасностью, и поэтому у нас была аутентификация на сервере, но, честно говоря, это можно решить, если закрытый ключ пользователя находится у них, а не на сервере, после чего расширение chrome с помощью закрытого ключа может подписывать транзакцию только на стороне пользователя. затем они могут вручную добавить расширение, а затем выполнить транзакцию со своих смартфонов, ноутбуков и т. д. без запуска блокчейна.
В-третьих, пользователь становится в некоторой степени отслеживаемым при выполнении веб-транзакции.
Заключение
Хотя у этой архитектуры есть ограничения, некоторые из которых можно исправить навсегда, а некоторые потребуют постоянных усилий для исправления. как безопасность и неизменность останутся нетронутыми.
Надеюсь, вам понравилось читать!
Что дальше
Вот видео-демонстрация приложения, которое мы создали. Эта статья была кратким введением в его архитектуру. В следующих частях я расскажу, как создать его с нуля.
PS: Любой, кто хочет узнать больше, может просмотреть мои публикации за то же самое.
