Децентрализованные приложения 2.0
В данном документе мы хотели бы познакомить читателя с последней разработкой нашего проекта, которая возможно изменит не только рынок блокчейна, но и рынок приложений в целом.
Смарт-контракты - самые первые ДП
Самый простой пример децентрализованного приложения (без интерфейсной части) - смарт-контракт: код, который выполняется внутри блокчейна. За счет того, что он проверяется всеми узлами, его никто не может подделать. Результат проверки должен быть одинаков.
В PoW консенсусе все узлы выполняют смарт-контракт одновременно, но выигрывает тот узел, который раньше остальных посчитал выигрывающую комбинацию задачи или хеша. В асинхронном BFT консенсусе смарт-контракт выполняется полностью только на одном узле, а все остальные узлы должны проверить результат его выполнения. Теоретически они могут просто “поставить галочку” проверено, не выполняя смарт-контракт. Но так как проверка остальными узлами происходит после выполнения главным узлом, это занимает большее время.
Напомним, что консенсус Resonance - синхронный BFT алгоритм, поэтому смарт-контракт не только проверяется, но и исполняется одновременно на всех узлах, что позволяет уменьшить время на его исполнение и проверку.
Для того, чтобы смарт-контракты могли использоваться массово, были введены стандарты, например, ERC-20. Токен ERC-20 - просто вызов смарт-контракта для передачи ему каких-то данных. Это дало возможность стандартизировать графические и программные интерфейсы для работы с полями и функциями. Графический - чтобы создать кошелек, который работает с ERC-20 токенами, и программный - чтобы была возможность создавать автоматизированные биржи.
Мы используем смарт-контракты на Wasm, т.к. Wasm исполняется почти на всех устройствах (где есть JavaScript) и оптимизирован по объему данных.
Но все же когда мы говорим “децентрализованные приложения”, чаще всего мы подразумеваем приложения с клиентской частью, о них речь пойдет ниже.
ДП (децентрализованные приложения)
Итак, ДП могут быть серверными и полностью работать внутри блокчейна, но сейчас серьезных ДП, не взаимодействуцющих с внешним миром, кроме ERC-20, практически нет. Остальные используют графический интерфейс.
Давайте разберем ДП с графическим интерфейсом на уже хрестоматийном примере - криптокотиках.
У данного приложения есть клиентская сторона (фронтенд) и серверная сторона (бэкенд). В web-приложениях есть фронтенд и есть графический интерфейс (или графический пользовательский интерфейс, GUI), функцию которого выполняют примитивы web-браузера. А в серверной стороне одна часть выполняет вычисления, а другая, web-сервер - отправляет и принимает запросы графического интерфейса.
Приложение Cryptokitties запускает свой сайт, который содержит картинки, некоторую логику, а остальное “подтягивает” из блокчейна Ethereum.
Для того, чтобы выполнять какие-то действия внутри этого ДП, необходимо использовать плагин Метамаск, в котором пользователь хранит ключи от своего аккаунта сети Ethereum и подписывает транзакции для управления криптокотиками. Через Метамаск пользователь сообщает смарт-контракту, какие изменения он хочет произвести. Получение информации из блокчейна Ethereum возможно только через собственную ноду.
Как мы видим такое приложение обладает довольно сложной архитектурой. Бэкенд состоит из 2-х частей: 1-я - блокчейн, в нем хранится информация и результаты работы (обработки данных), 2-я - web-сервер, который отправляет интерфейс приложения и интерпретирует данные из блокчейна в фронтенд.
Фронтенд также состоит из 2-х частей: web-браузер и кошелек (например, Метамаск).
Попробуем описать процесс взаимодействия пользователя с приложением и логику происходящих процессов.
| Действие | Логика |
|---|---|
| 1. Пользователь запускает веб браузер и вводит имя сайта | Происходит запрос к веб серверу |
| 2. Веб браузер загружает интерфейс пользователя - страницу сайта | Происходит выдача интерфейса веб сервера |
| 3. Пользователь производит обычное взаимодействие (например, нажимает кнопку) | Интерфейс запрашивает и получает данные от веб сервера |
| 4. Пользователь производит действия, которые необходимо записать в блокчейн, например, выставить на продажу крипто-котика | А. Интерфейс формирует транзакцию и запрашивает ее подпись у кошелька. Кошелек выводит свой интерфейс для подтверждения транзакции, после подтверждения отправляет подписанную транзакцию напрямую в блокчейн. B. После любых действий с блокчейном интерфейс должен получить обновленную информацию от блокчейна через веб сервер (посредством собственного доверенного узла). |
Можем выделить здесь 3 типа сущности:
- Которые может полность контролировать Пользователь: веб-браузер и кошелек (ключи)
- Полностью децентрализованные объекты, внести изменения в которые практически невозможно: смарт-контракт и блокчейн
- Объекты инфраструктуры разработчика ДП: свой узел блокчейна и веб-сервер - полностью зависящие от конкретных владельцев - централизованная часть, целевой вектор атаки на приложение.
Главный минус такой архитектуры - большое количество векторов атаки: веб-сервер может быть взломан (подмена DNS или физически), подменен адрес перевода денег, можно взломать ноду, написав специальный код, взломать дополнительные модули к вебсерверу, Java-скрипты
Другой минус - наличие централизованных частей - например, web-сервера и кошелька. Если подумать, для существующих ДП “децентрализованные” не совсем корректное название.
ДП 2.0
Мы добавили новую функцию в смарт-контракт - интерфейсную. Таким образом, мы создаем новый стандарт - интерфейс взаимодействия клиентской части (фронтенда) и серверной (бэкенда). Благодаря этому, на базе наших смарт-контрактов можно строить полноценные децентрализованные приложения, где фронтенд защищенно связан с серверной частью, в роли которого выступает смарт-контракт, внесенный в блокчейн.
В настоящее время мы не можем полностью раскрыть алгоритм взаимодействия смарт-контракта и клиентской части приложения. Однако укажем, что смарт-контракт проверяет оригинальность клиентской части и ее адрес расположения.
Теперь разработчики могут сосредоточиться на интерфейсной, клиентской части приложений (либо программной, если мы например говорим об Интернете Вещей) и запускать их на смарт-контрактах с помощью нашего стандарта ДП 2.0. Нет необходимости создавать связующее ПО (middleware) и бэкенд, просто написать приложение на Rust, C, или C++, оно будет выполняться Wasm и компилироваться в бинарный код, понятный браузеру, и будет иметь серверную часть. Конечно, часть, написанная сторонними разработчиками должна проходить определенную проверку, чтобы им можно было доверять.
После подписания пользователем транзакции она меняет состояние смарт-контракта в блокчейне, и Dapp client может сразу получить и отборазить это изменение без задействования дополнительных серверов. Поэтому такую систему можно назвать “бессерверной” - serverless.
Заключение
Через некоторое время мы представим вам первое ДП 2.0 и Power_Store (магазин децентрализованных приложений и других продуктов и сервисов на блокчейне).
Если вы - активный разработчик, стартап или проект, и вам интересна тема смарт-контрактов или децентрализованных приложений - мы будем рады сотрудничать, делиться опытом и предоставить возможность написать свое приложение на новом стандарте - ДП 2.0.
Отправьте нам запрос на почту info@thepower.io, в запросе напишите о себе и кратко опишите задачу или проект, который вы хотите реализовать.
Если вы знаете C, C++ или Rust и вам интересно попробовать свои силы в написании смарт-контракта - у вас есть такая возможность ;)
Присоединяйтесь к нашему телеграм чату для разработчиков: t.me/thepower_dev.