Как создать децентрализованное приложение

Обновлено: 07.01.2025

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

Что из себя представляют dApps? Почему они стали настолько популярными? Как будет развиваться рынок децентрализованных приложений дальше? Будем разбираться в этом интересном обзоре.

Что такое децентрализованное приложение?

Как работает децентрализованное приложение?

Такие приложения обрели большую популярность после появления Ethereum, универсального протокола для развертывания dApps. Если до Ethereum блокчейн-разработчик должен писать код с нуля, то с Ethereum он может создавать код для dApps чуть ли не в два клика и без особых знания языка программирования.

Как результат, появилось три вида децентрализованных приложений:

Финансовые приложения. Они нацелены на работу с крипто-активами и в большей степени создаются как простой крипто-кошелек (в редких случаях поддерживающий банковские карты).
Инфраструктурные приложения. Они облегчают использование блокчейна и криптовалют и способствуют их распространению среди массового потребителя.
Альтернативные приложения, созданные как децентрализованная альтернатива централизованным решениям. К примеру, облачный сервис или блог-платформа. Токены таких приложений используются в качестве внутренней валюты (Siacoin или Steem).

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

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

Какие платформы используются для разработки dApps?

В большинстве случаев это Ethereum, EOS и Tron. Сейчас этот рынок достаточно конкурентоспособен, поэтому на нем можно встретить более интересные платформы (QTUM, Stratis и др).

На текущий момент 29% всех децентрализованных приложений созданы на базе Ethereum. Почти 50% dApps создаются на EOS, а 20% на базе Tron. Стоит отметить, что доля Tron ежемесячно растет, поскольку пользователи нуждаются в максимальном быстродействии приложений, в их безопасности и в удобстве использования. На эти критерии собственно и ориентируется Tron.

Тем не менее, EOS может предложить блокчейн-решение с более высокой пропускной способностью (6000 тр/c), с более удобным инструментом для работы со смарт-контрактами и многие другие возможности. Одновременно с этим, dApps на Ethereum остаются наименее уязвимыми и более гибкими в плане разработки.

Как dApps влияет на криптовалютный рынок?

Децентрализованные приложения привлекательны за счет возможной монетизации. Варианта всего три:

Выполнение тех или иных действий в приложении с оплатой в токенах;
Майнинг;
ICO;

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

Востребованность;
Инвестиционная привлекательность нативного токена;
Беспрецедентная безопасность;

Совокупность этих трех факторов способна обеспечить развитие dApps в крипто-индустрии. Блокчейн-приложения, разрабатываемые традиционными компаниями (например, Microsoft, IBM) практически не интересны участникам крипто-рынка, нежели децентрализованные.

Подведем итоги

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

После развития и внедрения смарт-контрактов в 2015 году появилась новая модель для построения успешных и масштабируемых технологий — Dapps, или decentralized application. Децентрализованные приложения за несколько лет стали настолько популярными, что из-за постоянной работы начали перегружать сеть Ethereum и замедлять ее работу. Для разгрузки блокчейна Loom Network представил ZombieChain — общий сайдчейн для всех Ethereum-Dapps. В индустрии на данный момент существует 1576 приложений. С каждым разом их становится все больше. Можно ли самостоятельно собрать Dapp?

Dapp это больше, чем смарт-контракт

Децентрализованные приложения во многом схожи со смарт-контрактами, основанными на Ethereum. Но все же между двумя разработками есть существенные отличия. Если смарт-контракты связаны только с финансовыми транзакциями и имеют ограничение по количеству участников в конкретный момент времени, то Dapps расширяет эти границы и выходит за рамки установленных правил — в приложении одновременно может участвовать неограниченное число пользователей (хоть это и вызовет перегрузку сети), а разработчики не ограничиваются одним лишь экономическим сектором и придумывают утилиты для развлекательной, музыкальной, игровой и других индустрий. С полным списком приложений можно ознакомиться на сайте, где происходит постоянное обновление участников сети.

Таким образом, Dapps — это утилиты, с помощью которых можно реализовать и в будущем сопровождать процессы CI/CD (Continuous Integration, или непрерывная интеграция, и Continuous Delivery, или непрерывная доставка).

Чтобы приложение рассматривалось как Dapp, оно должно соответствовать следующим критериям:

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

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

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

Приложение обязано генерировать токены в соответствии со стандартным криптографическим алгоритмом, действующим в качестве доказательства того, что ноды достоверны (биткоин использует алгоритм Proof-of-Work).

Dapp состоит из двух частей: интерфейс, написанный в HTML, и бэкэнд — «база данных» для интерфейса.

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

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

Как запустить Dapp. Начальная инструкция

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

Команда Ethereum на своем сайте дает рекомендации по сборке собственного приложения. Мы подготовили перевод инструкции.

Первым вашим шагом будет установка клиента Alethzero с языком C++. После установки на компьютер вы увидите белые окна с браузером.

Специалисты Ethereum обещают выпустить свой браузер Minst, который будет предназначен для работы с Dapps, пока его можно скачать в бета-версии, выглядеть он будет так:

Для создания Dapp лучше всего использовать язык Solidity, так как именно он формально поддерживается командой ETHDEV. Но существует несколько других языков, которые можно внедрять в приложение. Это LLL (аналогичен «языку обработки списков» Lisp) и Serpent (аналогичен языку программирования общего назначения Python).

После выбора языка необходимо ввести в систему хотя бы одну учетную запись токена, чтобы запустить контракт. Затем нужно нажать функцию «send», аналогичную contract.send (счет, сумма) для перемещения токена.

Для написания программы можно использовать любой редактор, информацию из которого вы потом перенесете в Alethzero.

Контракты делятся на методы. Первый — metaCoin. Является специальным методом конструктора, который определяет начальное состояние хранения данных контракта. Функции конструктора всегда имеют то же имя, что и контракт. Этот код инициализации выполняется только один раз при создании договора.

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

Строка, которая указана выше, создает сопоставление, где ваш код строго записывает информацию в хранилище контрактов, — здесь мы определили сопоставление для пар ключей значения типа address и uint called balance. Тут будет храниться баланс монет.

Обратите внимание, что указано два типа данных: address и uint. В отличие от языка Serpent, Solidity статически типизирует и выполняет проверку типов во время компиляции. Указание типа перед компиляцией также позволяет уменьшить размер переданного транзакциями массива данных, это помогает компилятору создавать более оптимизированный EVM-код.

Это инициализация контракта, который будет запускаться только один раз (так как находится в методе конструктора metaCoin) и выполнять два действия. Во-первых, контракт использует msg.sender для поиска общего адреса отправителя транзакции, то есть вас. Во-вторых, контракт обращается к хранилищу контрактов, используя отображающиеся балансы. Контракты хранят данные как пару ключевых значений длиной 32 байта.

Msg.sender — номер в 160 бит, обозначающий ваш открытый ключ. Это уникальный идентификатор в сети, который нельзя подделать благодаря криптографическим законам, которые реализует Ethereum.

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

Подтвердить процесс передачи токенов с одного адреса на другой можно с помощью msg.sender, receiver и amount.

Если баланс проверяется, условие будет оцениваться как ложное, а следующие две строки будут вычитать сумму, отправляемую с баланса отправителя: балансы [msg.sender] = amount; затем добавятся к балансу счета, получающего токены: balances[receiver] += amount;.

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

Как запустить Dapp. Шаг: работа в Alethzero

После того, как вы пропишите последовательность ходов, всю информацию нужно будет перенести в Alethzero. Откройте кошелек и убедитесь, что это личный интерфейс и что у вас открыт блокнот с контрактом, сохраненным внутри. В данном руководстве не нужно подключаться к Testnet, вместо этого выберите «Use Private chain» в меню debug и создайте свою собственную частную цепочку. Благодаря этому вы будете зависить от того, что тестовая сеть находится в онлайне, когда разрабатываете Dapp.

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

Так как у вас запущена частная цепочка, и вы не подключены к сети, можно использовать только новые блоки. Нажмите «Mine» на панели инструментов, затем перейдите в меню debug и выберите «Force Mining». В этот момент различные вкладки должны наполняться информацией. На вкладке учетной записи есть визуальное представление процесса разработки блока — когда успешный блок обнаружен, красная отметка достигает пика, и баланс должен увеличиваться. Для просмотра процесса можно воспользоваться вкладкой «Blockchain», где записывается каждое действие.

Остановить майнинг можно в тот момент, когда вы станете держателем каких-либо токенов (в нашем примере описываются монеты Finney) тех проектов, которые основаны на Ethereum. Для этого еще раз нажмите «My» и разверните свой контракт.

Повторно запустите всплывающее окно «New Transaction», скопируйте и вставьте Solidity, которую ранее написали в текстовом поле «Data». Это должно выглядеть примерно так:

Поскольку мы просто создаем тестовый контракт и не собираемся отправлять эфир на другие аккаунты, все незаполненные поля можно оставить по умолчанию. Но в данном примере отправляется 10,000 газа на контракт по цене 10 Szabo за каждый эфир. Szabo — другая единица стоимости, эквивалентная 0.000001 части эфира. Контракт не будет потреблять весь газ, поскольку тестовый код в данном контракте очень простой.

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

Поскольку вы не майните, контракт будет выходить в «Pending» и выглядеть следующим образом:

После нажатия «Execute» в области транзакций обратите внимание на поле «creates» для этой конкретной транзакции на pending-панели, в данном случае «1f530b6b…» (для каждого пользователя будет создан свой уникальный ID).

Теперь, когда есть ожидающий или pending-контракт, нужно зафиксировать его в блочной цепочке путем разработки блока. Нажмите «mine» и дождитесь, пока транзакция исчезнет с pending-панели, и новая запись появится в панели «Contract». Снова выключите майнинг и нажмите на новый контракт в панели контрактов. Вы должны увидеть:

Теперь в области, где ранее вводили код, впишите идентификатор функции и адрес получателя и значение в отдельных строках. Когда ранее отправляли контракт в сеть, вы должны были сохранить ID sendCoin. Используйте 0xec6d9353ca85eb80076817fa989f8825e136d55d (общий адрес в тестовой сети: p) и любое значение ниже 10,000. Данные должны выглядеть примерно так:

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

Нажмите «Execute», и вы должны еще раз увидеть транзакцию в ожидании, нажмите «my», пока не сгенерировали новый блок, а затем прекратите майнинг. Теперь контракт должен выглядеть примерно так:

Выдохните, это финал

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

Децентрализованное приложение очень широкое понятие. Но, поскольку мы работаем со смарт-контрактами эфира, то определим децентрализованное приложение как:

В разных источниках может встречаться аббревиатура Đapps, Dapp или Đapp. Поскольку это первая статья посвященная децентрализованным приложениям, то мы сначала решим организационные вопросы: знания для понимая статьи и инструменты и их установка. А потом напишем наше первое децентрализованное приложение.

С чем вы должны быть знакомы для понимания статьи

С web-программированием. Тут потребуется не только опыт в использовании HTML и CSS, но и знакомство с языком JavaScript.
С платформой nodeJs. Гуру быть в этом вопросе не нужно. Достаточно уметь ставить пакеты с помощью пакетного менеджера и уметь работать в консоле node.
C написанием смарт-контрактов ethereum. Если не знакомы, то можете прочитать три статьи отсюда. Для начала этого хватит.
С Apache2 или другим веб-сервером. Нужно уметь запускать веб-сервер и знать куда сохранять файлы проекта.

Инструменты и их установка

Для выполнения примеров нам потребуются инструменты.

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

В статье все примеры будут выполняться в Linux. По-возможности от специфики операционной системы буду отходить.

Теперь можно приступать.

Архитектура DApp

Грубо говоря типовая архитектура децентрализованного приложения состоит из трех частей.

Нода с блокчейном эфира
web3.js
Интерфейс

Сама по себе нода не очень удобна для программирования. Поэтому между интерфейсом и нодой используют web.js.

Наше первое DApp приложение

Наше первое DApp приложение будет читать и записывать строчку приветствия в контракт через web-страничку.

Но для начала мы подготовим проект.

Создайте папку для проекта. У меня это будет testdapp
Перейдите в эту папку
Теперь нам надо инициализировать конфигурацию node проекта. Для этого выполните

Папка с проектом готова. А теперь давайте напишем наш контракт.

function setWellcomeString ( string newWellcomeString ) <

В нем ничего сложного нет. Сохраните его в файле wellcome.sol. Теперь в отдельной консоле вам нужно запустить testrpc одноименной командой. Таким образом мы запустим тестовое окружение, которое будет играть у нас роль ноды эфира. После запуска testrpc выведет список тестовых аккаунтов.

Мы будем использовать нулевой аккаунт чтобы заливать наш контракт.

Теперь нам надо скомпилировать наш контракт и залить в блокчйен. Делать мы это будем с помощью модуля web3.js. Запускаем nodejs:

У нас появится консоль nodejs. В которой мы подключим web3js и создадим его инстанс:

web3 = new Web3 ( new Web3 . providers . HttpProvider ( "http://localhost:8545" ) )

Теперь мы можем работать с web3js. Давайте скомпилируем наш контракт:

abiDefinition = JSON . parse ( compiledCode . contracts [ ':WellcomeContract' ] . interface ) WellcomeContract = web3 . eth . contract ( abiDefinition ) byteCode = compiledCode . contracts [ ':WellcomeContract' ] . bytecode

В первой строчке мы получаем API интерфейс нашего контракта. На базе этого интерфейса создаем класс контракта во второй строчке. В третьей получаем байткод. А в четвертой заливаем наш контракт в блокчейн от имени аккаунта 0. Количество газа для транзакции можно вычислить в remix.

Давайте выведем адрес нашего контракта в блокчейне. Он нам понадобится при написании web-странички.

Скопируйте этот адрес куда-нибудь.

Кстати теперь мы можем общаться с контрактом прямо из консоли node. Для этого выполните

contractInstance = WellcomeContract . at ( deployedContract . address )

К примеру теперь мы можем получить строчку wellcomeString

Если все прошло успешно, то коносль отобразит вам хэш транзакции. А теперь самостоятельно выведите строчку приветствия.

Давайте приступим к написанию HTML странички, которая будет с помощью web3js получать у контракта и выводить строчку приветствия.

Ничего сложно. Просто подключили web3.js и наш index.js, который мы сейчас напишем. Ну и конечно jQuery для удобств. Строка приветствия будет выводится в контейнер wellcomeStringContainer.

Давайте теперь добавим логику в index.js. У нас после загрузки странички web3.js будет подключаться к нашей ноде testrpc. А она у нас принимает запросы по адресу localhost:8445. После подключения мы с помощью web3.js будем получать wellcomeString и назначать ее контейнеру wellcomeStringContainer.

Для того чтобы мы могли обращаться к методам контракта нам потребуется ABI интерфейс. Для этого выполните

compiledCode . contracts [ ':WellcomeContract' ] . interface

И в консоль выведется ABI интерфейс. Еще нам нужно получить адрес от которого заливали контракт.

Теперь мы можем приступать непосредственно к написанию index.js.

web3 = new Web3 ( new Web3 . providers . HttpProvider ( "http://localhost:8545" ) ) ; abi = JSON . parse ( '[<"constant":true,"inputs":[],"name":"wellcomeString","outputs":[<"name":"","type":"string">],"payable":false,"stateMutability":"view","type":"function">,<"constant":false,"inputs":[<"name":"newWellcomeString","type":"string">],"name":"setWellcomeString","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function">]' ) ; contractInstance = WellcomeContract . at ( '0xc04d0c1bb4984b3a158a780ff3bfc0561484917f' ) ; let val = contractInstance . wellcomeString . call ( ) . toString ( ) ;

Далее идет код, который выполняется после загрузки HTML документа. В нем мы получаем строчку приветствия из конракта. А затем устанавливаем эту строчку HTML элементу с идентификатором wellcomeStringContainer.

Наше первое децентрализованное приложение заработало!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя основной упор 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 приложении без смарт-контрактов.

Читайте также: