Нет, запуск децентрализованного приложения (dapp) на блокчейне не приведет к успешному бизнесу. На самом деле, большинство пользователей даже не задумывается работает ли приложение на блокчейне — они просто выбирают продукт, который дешевле, быстрее и проще.

К сожалению, даже если у блокчейна есть свои уникальные особенности и преимущества, большинство приложений, которые работают на нем, гораздо дороже, медленнее и менее понятны, чем их централизованные конкуренты.

Довольно часто в whitepaper’ах приложений, которые построены на блокчейне, можно найти параграф, в котором сказано: "блокчейн дорогой и не способен поддерживать требуемое число транзакций в секунду. К счастью, много умных людей работает над масштабированием блокчейна и к моменту запуска нашего приложения он станет достаточно масштабируем".

В одном простом параграфе, разработчик dapp’а может отказаться от более глубокого обсуждения проблем масштабируемости и альтернативных решений проблем. Это часто приводит к неэффективной архитектуре, где бэкендом и ядром приложения служат смарт-контракты, работающие на блокчейне.

Однако, существуют еще неопробованные подходы в архитектуре децентрализованных приложений, которые позволяют гораздо лучше масштабироваться, благодаря уменьшению зависимости от блокчейна. Например, Blockstack работает над архитектурой, где большинство данных и логики приложения хранится за пределами блокчейна.

Давайте сперва глянем на более традиционный подход, в котором блокчейн используется, как прямой посредник между пользователями приложения, и который не особо хорошо масштабируется.

Подход #1: Блокчейн как бэкенд

Чтобы было нагляднее, давайте возьмем гостиничную индустрию в качестве примера. Это огромная индустрия, в которой посредники вроде Booking.com, берут огромную плату за соединение гостей и отелей.

В любой ситуации, когда мы хотим одолеть такого посредника, используя этот подход, мы будем пытаться повторить его бизнес логику, используя смарт-контракты на таком блокчейне, как, например, Ethereum.

Смарт-контракты с открытым исходным кодом, запущенные на "всемирном компьютере", могут соединять продавцов с потребителями без сторонней компании между ними, в конечном итоге уменьшая плату и комиссию, взимаемую посредником.

Как показано на изображении ниже, отели используют децентрализованное приложение для размещения в блокчейне информации о номерах, их доступности и ценах в будние или выходные дни, и возможно даже описание номеров со всей остальной подходящей информацией.

Любой, кто хочет забронировать номер, использует это приложение для поиска отелей и номеров, размещенных на блокчейне. Как только пользователь выбирает номер, бронирование происходит отправкой нужной суммы токенов отелю в качестве залога. А в ответ, смарт-контракт обновляет информацию в блокчейне, что номер больше недоступен.

В этом подходе есть две стороны проблемы масштабируемости. Во-первых, максимальное число транзакций в секунду. Во-вторых, объем данных, который может храниться в блокчейне.

Давайте сделаем примерные расчеты. Booking.com заявляет, что у них зарегистрировано почти 2 миллиона отелей. Предположим, что в среднем у отеля есть 10 номеров и каждый бронируется всего 20 раз в году — это дает нам в среднем 13 бронирований в секунду.

Для оценки этого числа стоит отметить, что Ethereum может обрабатывать примерно 15 транзакций в секунду.

При этом, стоит учитывать, что в нашем приложении будут также транзакции от отелей — для загрузки и постоянного обновления информации о их номерах. Отели обновляют цену номеров очень часто, иногда даже ежедневно, и каждое изменение цены или описания требует транзакцию в блокчейне.

Здесь также проблем размера — вес блокчейна Ethereum недавно перешел отметку в 2TB. Если бы приложения с подобным подходом стали бы действительно популярны, то сеть Ethereum стала бы крайне нестабильной.

Такая система, основанная на блокчейне, может исключить посторонних из-за ее беспристрастности и отсутствия централизации — главных преимуществ технологии блокчейна. Но у блокчейна есть также и другие особенности — он распределенный и не перезаписываемый, это отличные характеристики, но за них надо платить скоростью и комиссией транзакций.

Поэтому разработчики dapp’ов должны тщательно оценить действительно ли каждой фиче, использующей блокчейн, нужна распределенность и неперезаписываемость.

Например: в чем преимущество распределения данных каждого отеля по сотням машин по всему миру и постоянного хранения их там? Действительно ли важно, чтобы исторические данные по ценам и доступности номеров всегда были включены в блокчейн? Наверное, нет.

Если мы начнем задавать такие вопросы, то начнем видеть, что нам не обязательно нужны все дорогостоящие характеристики блокчейна для всех наших функций. Так, какая же альтернатива?

Подход #2: Архитектура, вдохновленная Blockstack’ом

Хотя основной упор Blockstack на приложениях, в которых пользователи являются владельцами своих данных (например, таких как Airtext, BentenSound, ImageOptimizer или Graphite), у blockstack также есть философия малого использования блокчейна — только тогда, когда это абсолютно необходимо. Их основной аргумент в том, что блокчейн медленный и дорогой, а значит должен использоваться только для одиночных или нечастых операций. Остальное взаимодействие с приложениями должно происходить через peer-to-peer, т.е. пользователи децентрализованных приложений должны делиться данными напрямую друг с другом, а не через блокчейн. В конце концов, самые старые и успешные децентрализованные приложения, такие как BitTorrent, емейл и Tor были созданы еще до создания самого концепта блокчейна.

Слева: первый подход, в котором пользователи взаимодействуют через блокчейн. Справа: пользователи взаимодействуют напрямую друг с другом, а блокчейн используется только для идентификации и подобного.

Давайте вернемся к примеру с бронированием отелей. Мы хотим беспристрастный, независимый и открытый протокол для связывания гостей с отелями. Другими словами, мы хотим убрать централизованного посредника. У нас нет необходимости, например, постоянно хранить цены номеров в общем распределенном реестре.

Почему бы нам просто не позволить гостям и отелям взаимодействовать напрямую, а не через блокчейн. Отели могут хранить их цены, доступность номеров и любую другую информацию где-нибудь, где они будут доступны для всех — например, IPFS, Amazon S3, или даже их собственный локальный сервер. Это как раз то, что предоставляет децентрализованная система хранения от Blockstack под названием Gaia. Она позволяет пользователям выбрать, где они хотят хранить их данные и контролировать, у кого может быть доступ к ним через подход, называемый многопользовательским хранилищем.

Чтобы установить доверие, все данные отеля криптографически подписываются самим отелем. Независимо от того, где хранятся эти данные, их целостность может быть проверена с использованием открытых ключей, связанных с идентификационной информацией этого отеля, хранящейся в блокчейне.

В случае с Blockstack, в блокчейне хранится только ваша идентификационная информация. Информация о том, как получить данные каждого пользователя, хранится в файлах зоны (zone files) и распространяется через пиринговую сеть с помощью нод. И еще раз — вам не нужно верить данным, которые отдают ноды, потому что вы можете проверить их подлинность, сравнив их с хешами, которые хранятся в блокчейне и у других пользователей.

В упрощенной версии системы, гости будут использовать пиринговую сеть Blockstack для поиска отелей и получения информации о их номерах. А подлинность и целостность всех данных, которые вы получите, может быть проверена используя публичные ключи и хеши, хранящиеся в виртуальной цепи Blockstack.

Эта архитектура сложнее, чем первый подход, и требует более комплексной инфраструктуры. На самом деле, это как раз то, где приходит Blockstack, предоставляя все необходимые компоненты для создания такой децентрализованной системы.

При такой архитектуре, мы храним в блокчейне только данные, которые действительно должны быть распределенными и не перезаписываемыми. В случае с Blockstack, вам нужны транзакции в блокчейне только, чтобы зарегистрироваться и указать, где должны храниться ваши данные. Вам может потребоваться больше транзакций, если вы захотите изменить что-то из этой информации, но это не повторяющееся событие.

Более того, логика приложения, в противоположность первому подходу, работает на стороне клиента, а не на смарт-контрактах. Это позволяет разработчику изменять эту логику без дорогостоящих или иногда даже невозможных обновлений смарт-контракта. А держа данные и логику приложения не в блокчейне, децентрализованные приложения могут достигнуть уровня производительности и масштабируемости традиционных централизованных систем.

Заключение

Приложения, работающие на Blockstack, могут масштабироваться гораздо лучше обычных блокчейн приложений, но это более молодой подход с собственными проблемами и неотвеченными вопросами.

Например, если децентрализованное приложение работает не на смарт-контрактах, то это уменьшает необходимость в утилити-токенах. Это может вызвать проблемы для бизнеса, если учитывать, что ICO были основным источником финансирования для децентрализованных приложений (включая сам Blockstack)

Здесь также есть технические проблемы. Например, относительно просто реализовать функцию бронирования отелей в смарт-контракте, где при атомарной операции бронирование номеров производится в обмен на токены. И не очень очевидно, как бронирование будет работать в Blockstack приложении без смарт-контрактов.

Приложения, которые целятся в глобальные рынки с потенциалом в миллионы пользователей должны очень хорошо масштабироваться, чтобы стать успешными. Ошибочно полагаться исключительно на блокчейны для достижения такого уровня масштабируемости в ближайшем будущем. Чтобы иметь возможность конкурировать с крупными централизованными игроками рынка, такими как Booking.com, разработчики децентрализованных приложений должны рассмотреть альтернативные подходы к проектированию своих приложений, например, такие как тот, который предлагает Blockstack.

Источник: habr.com