Web3: Фантастические SDAPPS и где они обитают
Сейчас разработка Web3 проектов стала уже обычным делом и выпустить свой токен может каждый школьник (даже отстающий, если спросит у ChatGPT, где какую кнопку нажать). Останется лишь написать DAPP (Decentralized application), добавить к нему пользовательский интерфейс (UI), разместить его на сервере и вот Web3 проект готов.
Но подождите! Мы говорим о «разместить на сервере»? Разве проект, размещенный на одном сервере, может называться «Decentralized»? Или надо разместить его на нескольких серверах, чтобы он стал «Decentralized»?
Вряд ли! По определению DAPP должно функционировать автономно, без человеческого вмешательства и не иметь конкретной принадлежности, как наши сервера, на которых мы размещаем UI для своего так называемого DAPP.
Впрочем, традиционно мы успокаиваем себя и нашего пользователя тем, что на сервере лишь UI, а вот само приложение уже в блокчейне и вот уж оно-то по-настоящему децентрализовано.
Но так ли это на самом деле? Кажется, мы сильно лукавим, когда утверждаем, что UI, расположенный на нашем сервере, никак не влияет на пользовательский опыт.
Давайте внимательно посмотрим, какие риски мы имеем?
Доступность / Отказоустойчивость
Сейчас, когда политики взяли за моду решать, какие ресурсы можно посещать жителям их стран, а какие — нет, и могут авторитарно заблокировать доступ к любым ресурсам, такое DAPP вряд ли можно назвать общедоступным.
Также наши сервера, на которых расположен UI DAPP, могут подвергнуться DOS-атаке, отключению домена по прихоти регистратора и много чему еще. На доступность может повлиять и выход из строя нашего сервера, а если их несколько — перебои у провайдера. Можно, конечно, использовать распределенную между провайдерами и странами инфраструктуру, но тогда мы приходим к следующему пункту.
Стоимость / конкурентоспособность
Для поддержки серверной инфраструктуры необходимы сервера, провайдеры, хорошие специалисты. И все это стоит денег, а значит надо закладывать дополнительную комиссию, что повлияет на конкурентоспособность нашего проекта. Особенно если другие смогут создать альтернативу без этих дополнительных затрат.
Безопасность
Сервер, на котором расположен наш DAPP, может быть взломан. Конечно, пользователь подписывает перевод из своего кошелька, но что, если злоумышленник подменит адрес назначения, размещенный на централизованном сервере?
Надежность и быстродействие
В мире крипты все меняется молниеносно. Сегодня вашим DAPP пользуются несколько человек, а завтра ваш сервер уже не способен выдержать поток новых пользователей. Такое нередко случается и на крупных «децентрализованных» проектах, когда рынок делает резкий рывок вверх или вниз. И когда ваш сервер начинает тормозить или вообще полностью перестает отвечать, перегруженный запросами, мы подходим к следующей проблеме.
Репутация
О том, что происходит на вашем сервере на самом деле, знаете только вы и ваш админ. Конечно, код вашего проекта скорее всего open source и каждый может посмотреть, что в нем есть и как он работает. Но кто знает, какой код действительно установлен на вашем сервере? Нет ли в нем доработок, которые по принципу MEV заставляют пользователя платить дополнительную, скрытую комиссию? А если нет, то как вы можете это доказать? Ведь любой FUD на эту тему может плохо отразиться на репутации.
Отдельно стоит сказать об удобстве
В современном Web-строительстве есть два основных подхода: при каждом клике страница полностью заново загружается с сервера и SPA или сайт с сервера загружается целиком, а в процессе подгружаются лишь данные. И если в первом случае пользователю приходиться ждать загрузку каждой страницы, то во втором — долго перегружать весь сайт при любом малейшем сбое, которых у новых проектов предостаточно.
Про неудобство интерфейса, построенного на HTML, я думаю, рассказывать не надо.
Так почему бы не избавиться от всех этих проблем, предоставив пользователю возможность взаимодействовать с блокчейном напрямую, без использования своего централизованного сервера?
Тогда пользователь сам сможет решить — развернуть собственную ноду или использовать один из Web3 провайдеров, которые предоставляют доступ к широкому спектру сетей через API.
Сейчас для этих целей создают либо мобильные приложения, либо расширения для Chrome. И если мобильное приложение можно назвать вполне рабочим решением для мобильной среды, то расширение Chrome подходит отнюдь не для любого проекта. Ограничение функциональности, особенности системы безопасности, надежность работы, риск блокировки расширения — лишь часть причин, почему разработчики DAPP отказываются от создания расширений в пользу собственной инфраструктуры.
Другой путь — это интеграция DAPP приложений в браузеры, мессенджеры и прочие программные продукты. Таких проектов сейчас много, но практически все они интегрируют собственные DAPP проекты, не позволяя другим игрокам выходить на этот рынок.
А теперь представьте себе браузер, в котором вы могли бы реализовать собственный UI для вашего DAPP без создания дорогостоящей инфраструктуры. Пишете смарт-контракт, создаете к нему UI и ваш Web3 проект готов к работе под любой нагрузкой.
Вот именно о таком браузере я и хочу вам рассказать.
Познакомьтесь — QmlBrowser
QmlBrowser — это экспериментальный SDAPPS (Serverless Decentralized Applications) браузер, который поддерживает локальную установку и работу приложений без использования централизованного сервера.
Установить SDAPP приложение в QmlBrowser можно элементарно: достаточно указать URL GIT репозитория прямо в поле ввода URL и браузер развернет ваше приложения непосредственно оттуда, выбрав наиболее свежую версию (подробнее см. инструкцию). Вы также можете просто развернуть архив приложения локально. В будущем планируется добавить поддержку установки из пакета, скачиваемого по HTTP/HTTPS и IPFS.
QmlBrowser поддерживает как привычный HTML, так и более прогрессивный QML. При этом SDAPP на базе QML могут использовать дополнительные возможности браузера, такие как неограниченный localStorage, обращение к серверам без применения политик CORS, возможность выполнения кода в отдельных потоках, создание и использование 3D сцен в реальном времени. Проект активно развивается и обрастает новыми возможностями, которых ранее не было ни у одного из известных браузеров. Более подробно об QmlBrowser можно прочитать в предыдущей статье: https://habr.com/ru/articles/762526/
Конечно, пока этот инструмент может закрыть еще не все потребности Web3. Это лишь первый шаг на пути создания нового подхода. Подхода, который, я уверен, со временем станет основным на рынке и поможет Web3 проектам вытеснить давно устаревший Web 2.0.
И, разумеется, как это уже не раз было, смена подхода обязательно приведет к серьезным изменениям на рынке. И именно сейчас отличный момент, чтобы занять на новом рынке лучшие места. Достаточно лишь оказаться среди первых, кто начнет использовать новый подход.
Репозиторий проекта с актуальным релизом:
https://github.com/Toorion/qml-browser
Канал в телеграм: @qmlbrowser
