Технологии Velas: MicroApps

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

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

Мотивация

Безопасность

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

Этот клиентский экземпляр контракта взаимодействует с Front-end Dapp, и выступает в роли конструктора смарт-контракта транзакции, визуально описывая пользователю то что он делает.

Существует несколько типов запуска таких конструкторов:

1. Клиентский код самого приложения / кошелька
2. Browser
3. Dapp Browser

Смарт-контракт, с которым взаимодействует кошелек должен быть публично-верифицированным на предмет:

1. Правильности реализации (соответствие заявленной логики с запрограммированной логикой)
2. Отсутствия проблем с безопасностью

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

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

Примеры:

https://github.com/MetaMask/metamask-extension

https://github.com/trustwallet/wallet-core

https://github.com/AlphaWallet/alpha-wallet-android

Но как доказать, что кошелек, который вы используете, соответствует коду находящимся в github?

Рассмотрим вопрос номер 1:

Существует дополнительная возможность верификации закачанного кошелька, если он:

1. Находится в внутри браузера страницы
2. Загружен как расширение браузера
3. Установлен с исходников

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

В случае, когда кошелек загружен как мобильное приложение, такого доказательства нет.

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

Где доказательство того, что код, который находится на гитхаб на текущий момент не имеет ошибки?

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

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

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

Каждый вариант использования, требует множество вариантов тестирования, а каждый вариант тестирования требует написание множества UNIT-тестов. И в конечном счете, необходимо протестировать правильность описания вариантов использования, множества вариантов тестирования, и множества UNIT тестов.

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

Но этот процесс практически никогда нельзя завершить на 100 процентов.

1. Динамика развития индустрии и необходимость создания решений для проведения эксперимента над горячим рынком не способствуют постановке четких задач.
2. Сам процесс описания тестами не устойчив к принципиальным изменениям кода. При каждом изменения кода, необходимо начинать весь процесс заново
3. Написанный код, может быть затруднен или непригоден полноценному тестированию.
4. По условиям NDA, команда держит разработку под секретом, и не может передать ее на верификацию аудиторам.
5. Аудиторы, не гарантирует 100 процентную гарантию качества аудита

Можно сделать вывод, что для рядового пользователя не существует кода, которому можно доверять на 100%, а доверие к программному продукту формируется сообществом.

Кроссплатформенность

Любое Dapp приложение ограничивается теми платформами, на которых запускается. Чтобы увеличить охват пользователей необходимо написать Dapp приложение под все возможные используемые платформы IOS, Android, Windows, MacOS, Linux, и так далее.

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

Следовательно, все приложения должны реализовывать свойства:

1. 1. Детерминизм — все функции приложения должны возвращать один и тот-же результат при одинаковом вводе
   2. Соответствие функционала — даже если приложение выглядит по разному, все равно пользователь должен получить доступ к функционалу, который имеет в этом же приложении на другой платформе

Логично предположить, что куда проще написать один и тот же код, который имеет разный компилятор под разные платформы с учетом специфики платформ и как следствие несет единство функционала для пользователей с разными предпочтениями OS и устройств.

Удобство использования

Данный раздел проще всего рассматривать на примере.

Рассмотрим Telegram Bots. Данный функционал реализует кроссплатформенность, потому что клиент Телеграм доступен на всех платформах и содержит в себе этот функционал.

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

Боты представляют определенные ограниченные возможности для разработчика:

1. Текст
2. Картинка
3. Кнопки
4. Подсказки
5. Доступ к геолокации
6. Доступ к контактам
7. Отправка файлов
8. Отправка текста
9. Отправка команд — нажатие на кнопки

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

Решение

Исходя из статистики использования Браузера и Мобильных приложений, согласно анализу, пользователи пользуются на 75 процентов больше мобильными устройствами чем браузером. А если сделать анализ использования приложений в мобильном устройстве — то пользователи на 75 процентов пользуются чатами больше чем всеми приложениями.

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

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

Velas предоставляет:

1. Децентрализованное хранилище компонентов
2. Чат, где эти компоненты могут быть задействованы

Функция хранилища:

1. Гарантия неизменности компонентов
2. Гарантия хранения компонентов на период определенный самим разработчиком (не меньше года)
3. Доставка компонентов клиентскому приложению чата по требованию
4. Доказательство подлинности кода (нет возможности подмены)

Функции чата:

1. Воспроизведение компонентов как визуальный элемент чата, взаимодействующий с пользователем
2. Предоставление API самого чата:

• Location Request
• Contact Request
• Payment Request
• Auth Request

3. Предоставление изолированного хранилища компонентов, для обеспечения пользовательского взаимодействия с компонентами

Процесс разработки Velas microApps выглядит следующим образом:

1. Разработчик разрабатывает компоненты следуя правилам конвенции кода
2. Разработчик публикует приложение в VelasSphera
3. Разработчик создает Телеграм бот, который вместо текста отправляет пользователю ссылку на адрес где лежит его приложение
4. Телеграм скачивает приложение из ссылки и воспроизводит его в клиентском чате.
5. Пользователь начинает взаимодействие с приложением, с уверенностью что разработчик (ни кто либо еще) не может больше его поменять
6. В случае когда приложение использует децентрализованные сервисы — оно само по себе становится полностью децентрализованным и устойчивым к цензуре