[Перевод] Архитектура Web 3.0 приложений. Авторский перевод статьи Прити Касиредди
От переводчика: в поисках понимания «что за приложения Web 3» была перелопачена целая гора различного материала, это и статьи в интернете, и книжки, и маркетинговые рекламы курсов. Везде очень много воды и зачастую видно, что за модным словом почти нет сути, а у автора нет своего четкого понимания предмета. Прити первая (из тех, кто мне попался на глаза), кто на доступном языке просто и понятно рассказала о сути таких приложений. Статья зацепила своей простотой изложения, хорошими и понятными схемами. Привожу ее перевод с некоторыми авторскими ремарками.
Архитектура приложений Web 3.0 (иначе называемых «DApps») кардинально отлична от архитектуры приложений Web 2.0.
Возьмем, к примеру, любой информационный блог, например сайт Medium, на котором пользователи могут публиковать свои материалы и взаимодействовать друг с другом. С одной стороны, этот сайт относится к приложениям Web 2.0 и кажется, что имеет довольно простое устройство, но при этом для того, чтобы обеспечить весь свой богатый функционал, он имеет достаточно сложную организацию:
Во-первых, для хранения данных пользователей, их материалов, переписок, лайков и другой разнообразной информации необходима мощная онлайн база данных.
Во-вторых, бэкэнд сайта (обычно написанный на Python, Java и Node.js), определяющий внутреннюю бизнес-логику приложения. Например, что происходит, когда регистрируется новый пользователь? Или когда публикует свой новый блог? А как организовано комментирование блогов другими пользователями?
В-третьих, фронтэнд (это что-то написанное на JavaScript, HTML и CSS), который определяет логику веб-интерфейсов сайта. К примеру, что происходит при взаимодействии пользователя с теми или иными элементами сайта (кнопками, слайдерами, разделами).
Итого, когда вы пишете пост на сайт, вы взаимодействуете с фронтэндом сайта, который взаимодействует со бэкэндом сайта, который взаимодействует с базой данных сайта. Суммарно весь этот код и фронтэнда, и бэкэнда, и базы данных размещается на централизованных серверах и передается пользователям через интренет-браузеры. Это очень краткое изложение того, как сегодня работает большинство приложений Web 2.0.
Но времена меняются.
Блокчейн-технологии дали возможность создавать восхитительные новые приложения направления Web 3.0. В этой статье мы сосредоточимся на полезностях блокчейна Ethereum.
В чем отличия приложений Web 3.0?
В отличие от приложений Web 2.0, таких как сайт Medium«а, приложения Web 3.0 устраняют всяческих посредников между собой и пользователями. Никакой централизованной базы данных, никакого централизованного веб-сервера.
Вместо всего этого, вы можете использовать блокчейн для создания приложений на так называемом децентрализованном «конечном автомате», который поддерживается в интернете анонимными узлами.
Под «конечным автоматом» подразумевается некоторое программное устройство, в каждый момент времени находящееся в определенном дискретном состоянии и имеющее конечное число допустимых будущих состояний. Грубо говоря, блокчейны — это программные устройства, запущенные с некоторым первичным состоянием и имеющие строгие правила изменения этого состояния, называемые правилами консенсуса. Более того, блокчейн коллективно управляется всеми участниками своей сети, и одновременно никем единолично.
Что насчет бэкэнд-сервера? Бэкэнд приложений Web 3.0 кардинально отличается от бэкэнда приложений Web 2.0. Здесь логику приложений определяют смарт-контракты, написанные и загруженные в сеть блокчейна. Это означает, что любой, кто желает создать приложение на блокчейне, имеет такую возможность. (Были бы деньги. Деплой на Эфириуме дело не бесплатное. — прим.переводчика)
А что у нас с фронтэндом? С небольшими поправками он почти не изменился. Об этом далее.
Итак, типичная архитектура Web 3.0 приложений выглядит так:
Детали
А теперь давайте взглянем более пристально и посмотрим, как это все реализовано.
1. Блокчейн
Блокчейн Эфириума часто называют «глобальным компьютером». А все потому, что он, поддерживаемый одноранговой сетью узлов по всему миру, доступен повсеместно и строго управляем жестко заданными правилами консенсуса.
Другими словами, к блокчейну может получить доступ совершенно любой человек в мире, и совершенно любой человек в мире может загрузить в нее свой код. Блокчейн не принадлежит никому единолично, это собственность всех участников данной сети.
Еще один важный ньюанс: в блокчейн Эфириума данные только записываются, их нельзя ни обновить, ни удалить.
2. Смарт-контракты
Смарт-контракт — это программа, работающая на блокчейне и определяющая всю логику изменений, происходящих в блокчейне. Смарт-контракты написаны на языках высокого уровня, таких как Solidity или Vyper.
Поскольку код смарт-контракта открыто хранится в блокчейне, любой желающий может проверить логику любого существующего смарт-контракта в сети Эфириума.
3. Виртуальная машина Эфириума (EVM)
Далее, виртуальная машина Эфириума (EVM) выполняет логику, описанную в смарт-контрактах, и вносит изменения дискретных состояний «конечного автомата», другими словами, вносит новые записи в блокчейн. Чтобы это произошло, код смарт-контрактов компилируется в байт-код и загружается (деплоится) в сеть блокчейна.
4. Фронтенд
И, наконец, фронтэнд приложения. Как выше было упомянуто, фронтэнд определяет логику веб-интерфейса сайта, который в свою очередь взаимодействует с логикой самого приложения, которое запрограммировано в смарт-контрактах. Связь между фронтэндом и смарт-контрактами немного сложнее, чем показано на рисунке выше. Остановимся на этом чуть подробнее.
Как фронтэнд взаимодействует со смарт-контрактами на блокчейне?
Итак, нам надо, чтобы наш веб-интерфейс взаимодействовал с нашими смарт-контрактами, то есть мог вызывать некоторые функции из них. Но вспомним, что блокчейн Эфириума — это есть децентрализованная сеть, где каждый узел сети хранит копию всех состояний «конечного автомата», включая код, данные, и другую информацию, связанную с нашим смарт-контрактом.
Чтобы взаимодействовать с данными и кодом, загруженными в блокчейн, достаточно взаимодействовать с одним из этих узлов, а уже этот узел распространит запрос на транзакцию (любое взаимодействие с блокчейном — есть транзакция, прим. переводчика), которую следует выполнить на виртуальной машине Эфириума. Далее, майнер подтвердит транзакцию, добавит ее в новый блок и распространит полученное новое состояние «конечного автомата» на всю сеть блокчейна.
Есть два способа взаимодействовать с блокчейном:
Настроить собственный узел с программным обеспечением Эфириума.
Использовать сторонние сервисы, предоставляющие доступ к существующим узлам сети Эфириума, такие как Infura , Alchemy и Quicknode.
Использование сторонних сервисов ограждает от всех проблем, связанных с самостоятельным запуском собственного узла. К тому же, установка собственного узла сети Эфириум может занять не один день. Очень много данных, которые потребуется синхронизировать. Возможно даже больше (и пропускной способности, и объема хранилища), чем может выдержать обычный ноутбук.
К тому же, стоимость хранения полной цепочки блоков сети Эфириума будет увеличиваться по мере роста и развития вашего децентрализованного приложения и может потребоваться еще больше узлов в сети. Поэтому, по мере роста и усложнения инфраструктуры приложения, потребуются инженеры DevOps, которые смогут обеспечивать надежную работу и быстрое время отклика приложения.
Собственно поэтому, многие собственники децентрализованных приложений предпочитают использовать сторонние сервисы, такие как Infura или Alchemy, для управления инфраструктурой своих узлов. Конечно, тут приходится выбирать между легкостью управления и рисками, так как такие третьи сервисы создают единую точку входа в приложение, отступая от идеи полной децентрализации, но давайте уж заморочимся этим в другой раз. ;)
Далее стоит рассказать о провайдерах. Так называют узлы, к которым вы подключаетесь для взаимодействия с блокчейном (независимо от того, настраиваете ли вы их самостоятельно или используете существующие от сторонних сервисов).
Провайдер реализует спецификацию JSON-RPC протокола, что гарантирует наличие единого набора методов взаимодействия внешних приложений и блокчейна. Грубо говоря, это упрошенный протокол удаленного вызова процедур (RPC), который определяет несколько структур данных и правила их обработки. Протокол может использоваться через сокеты, через HTTP или через разнообразные другие средства обмена сообщений между устройствами. В качестве формата данных в протоколе используется JSON (RFC 4627).
Как только вы подключитесь к блокчейну описанным выше способом, вы сможете читать данные из него, но, если вы хотите сохранять в блокчейн свои данные, нужно сделать еще кое-что. Прежде чем вы отправите свою транзакцию в блокчейн, ее следует «подписать», используя свой закрытый ключ.
К примеру, представьте, что ваше приложение позволяет пользователям читать и публиковать посты в блоге на блокчейне. Скорее всего у вас в приложении будет кнопка, позволяющая загружать посты определенного пользователя (Напомним, что чтение из блокчейна не требует транзакции и ее подписи).
Однако, когда пользователь захочет опубликовать свой новый пост в сеть, наше децентрализованное приложение потребует от пользователя «подписать» транзакцию, используя свой закрытый ключ. И только после подписания отправит транзакцию в блокчейн.
На «подписании» транзакции обычно используется MetaMask.
Metamask — это инструмент, упрощающий управление ключами и подписание транзакций. Все довольно просто: Metamask хранит закрытые ключи в браузере, и всякий раз, когда потребуется подписание транзакции, интерфейс приложения обращается к Metamask«у.
Metamask также обеспечивает подключение к блокчейну в качестве «провайдера», поскольку у него уже есть подключение к узлам через сторонний сервис Infura. Таким образом, Metamask является и провайдером, и сервисом для подписи транзакций.
Хранение данных в блокчейне
Конечно, описанная выше архитектура логична, если все данные приложения полностью хранятся в блокчейне. Но каждый, кто создавал приложения на Эфириуме, знает, что такое хранение очень быстро становится очень дорогим.
Имейте в виду, что с блокчейном Эфириумом пользователь платит каждый раз, когда добавляет новые данные в сеть. Это связано с тем, что добавление нового состояния (новой транзакции, изменяющей состояние блокчейна) увеличивает затраты на поддержание сети для существующих узлов.
И не лучшее решение заставлять пользователей своего приложения каждый раз платить за изменения их данных. Одно из решений — использование децентрализованных сервисов для хранения данных вне сети, например
IPFS или Swarm.
IPFS — это сервис, предоставляющий доступ к распределенной файловой системе для хранения и доступа к данным. Таким образом вместо того, чтобы хранить данные в централизованной базе данных, сервис IPFS предоставляет возможность хранить данные в одноранговой сети и легко получать доступ к ним, когда это потребуется.
IPFS также взаимодействует с Filecoin, протоколом и криптовалютой, стимулирующей хранение данных для других пользователей по всему миру. Такие сервисы есть, например, у Infura или Pinata, суть которых в том, что вы можете «прикрепить» свои файлы к IPFS, взять хэш IPFS и сохранить его в блокчейне.
Swarm — практически тоже самое, с одним заметным отличием. В то время как Filecoin — это отдельная система, система поощрения Swarm входит в экосистему Эфириума.
Итак, с IPFS или Swarm, архитектура нашего приложения выглядит так:
Проницательные читатели могли также заметить, что код фронтэнда также не хранится в блокчейне. Мы могли бы разместить этот код на виртуальном хостинге, как это делается для приложений Web 2.0, но это будет узким горлышком централизации для вашего децентрализованного приложения. Что, если хостинг выйдет из строя? Что, если он запретит ваше приложение?
Поэтому, если вы хотите создать действительно децентрализованное приложение, вам следует разместить код веб-интерфейса своего приложения в одном из децентрализованных сервисов для хранения данных, таких как IPFS или Swarm.
Итак, теперь архитектура будет выглядеть примерно так:
Запросы к блокчейну
До сих пор мы говорили о том, как писать в блокчейн, подписывая транзакции и затем отправляя их в блокчейн. Но что насчет чтения данных из смарт-контрактов в блокчейне? Есть два основных способа:
1. События смарт-контракта
Для запроса данных из блокчейна вы можете слушать события, генерируемые смарт-контрактами через библиотеку Web3.js. К примеру, если ваш смарт-контракт генерирует некоторый поток платежей от одного пользователя к другому, ваш веб-интерфейс можно настроить на прослушивание запускаемых событий.
2. The Graph
Описанный выше подход имеет некоторые ограничения. Например, что, если вы развернете смарт-контракт, а позже поймете, что вам нужно сгенерировать событие, которое вы изначально не включили? К сожалению, вам придется повторно развернуть новый смарт-контракт со всеми необходимыми правками. Более того, такое нагромождение событиями смарт-контрактов для обработки различной логики пользовательского интерфейса растет в геометрической прогрессии и быстро становится не эффективным.
Вот тут-то и приходит на выручку The Graph.
The Graph — это решение для индексации данных вне блокчейна, которое упрощает получение данных из сети Эфириума. The Graph позволяет вам задать, какие смарт-контракты индексировать, какие события и вызовы функций прослушивать и как преобразовывать входящие события в структуры и объекты, которые будет использовать логика вашего внешнего интерфейса приложения (или что-то еще, использующее API). В качестве языка запросов используется GraphQL, который многим фронтенд-инженерам кажется более выразительным по сравнению с традиционным REST API.
Индексируя данные, расположенные в блокчейне, The Graph позволяет легко и с низкой задержкой извлекать данные из блокчейна.
Теперь ваша архитектура приложения выглядит так:
Мы почти закончили, но у нас осталась одна важная тема: масштабирование.
Масштабирование вашего децентрализованного приложения
Как вы, возможно, слышали, Эфириум не масштабируется — по крайней мере, пока.
Средняя цена газа Эфириума
Средняя комиссия за транзакцию
Средний размер блока
Очевидно, здесь скрывается проблема. Создание децентрализованных приложений на Эфириуме с высокой комиссией за газ и необходимостью обеспечивать полное хранилище блоков приводит к постепенному усложнению и замедлению работы с блокчейном. К счастью, сейчас начали создаваться некоторые проекты для решения этих проблем.
Одним из самых известных таких L2 решений для масштабирования является Polygon. Вместо выполнения транзакций в основном блокчейне, Polygon имеет вторичные блокчейны («сайдчейны»), которые принимают и подтверждают транзакции, периодически отправляя совокупность своих последних блоков в основной блокчейн.
Также, среди L2-решений можно назвать Optimistic Rollups и zkRollups с аналогичным логикой: мы подтверждаем транзакции вне основной сети, используя «накопительный» смарт-контракт, периодически загружая эти транзакции в основной блокчейн.
Основная идея подобных решений состоит в том, что они подтверждают транзакцию вне цепочки (то есть выполняют медленную часть логики вне основного блокчейна), сохраняя в него только сами данные транзакций. Это позволяет масштабировать основную сеть, потому что нам не нужно выполнять каждую транзакцию в сети по очереди. Это также удешевляет и ускоряет подтверждение транзакций. И при всем при этом эти транзакции все еще взаимодействуют с основным блокчейном Эфириума.
Соберем все воедино
Если от всей этой информации у вас закружилась голова, знайте, вы не одиноки. Собрать воедино все эти сервисы и инструменты может стать мучением и сложной задачей для разработчика. Но к счастью, сейчас стали появляться специальные платформы для разработчиков, которые сильно упрощают им жизнь (и разработку).
Например, HardHat — это среда разработки, которая упрощает создание, развертывание и тестирование смарт-контрактов на Эфириуме. Hardhat даже обеспечивает собственную локальную сеть блокчейна для развертывания и тестирования смарт-контрактов без необходимости каждый раз деплоить контракты в тестовые и боевые сети блокчейна. К тому же, фреймворк предлагает отличную экосистему самых разнообразных плагинов, упрощающих жизнь разработчикам. Hardhat также для отладки предоставляет функциональность console.log (), как в javascript.
Конечно, это только начало. Я надеюсь, что далее будут появляться все более и более крутые инструменты для разработчиков.
Заключение
Многие начинающие разработчики месяцами выясняют, как собрать во едино весь этот стек разнообразных инструментов, поэтому, если вы новичок в разработке децентрализованных приложений, я надеюсь, что эта статья сэкономила вам время. Пришло время разработки!
Если вас интересует создание Web 3.0 приложений, регистрируйтесь в нашем буткемпе DappCamp, где вы научитесь создавать и разворачивать свое первое децентрализованное приложение на Эфириуме.
И, как всегда, если у вас остались какие-либо вопросы или вы нашли какие-либо ошибки в этом посте, пишите автору в комментариях! :)
Ссылка на оригинал статьи
Доступные выделенные серверы в Германии от AdminVPS
