В этой статье я расскажу о том, как мы пытались построить децентрализованный прокат скутеров на смарт контрактах и почему нам все равно понадобился централизованный сервис.
Как все начиналось
В ноябре 2018 года мы приняли участие в хакатоне, посвященном интернету вещей и блокчейн. В качестве идеи наша команда выбрала скутершеринг, так как у нас был скутер от спонсора этого хакатона. Прототип выглядел как мобильное приложение, позволяющее запускать скутер через NFC. С точки зрения маркетинга, идея подкреплялась рассказом про «светлое будущее» с открытой экосистемой, где каждый может стать арендатором или арендодателем, и все это на базе умных контрактов.
Эта идея очень понравилась нашим стейкхолдерам, и они решили превратить ее в прототип для демонстрации на выставках. После нескольких успешных показов на Mobile World Congress и Bosch Connected World в 2019 году, было принято решение протестировать прокат скутеров на реальных пользователях, сотрудниках Deutsche Telekom. Так мы приступили к разработке полноценного MVP.
Блокчейн на костылях
Я думаю, что не стоит объяснять, какая разница между проектом для показа на сцене и тем, которым будут пользоваться реальные люди. За шесть месяцев нам предстояло превратить сырой прототип в нечто подходящее для пилота. И тут мы поняли, что значит “боль”.
Для того чтобы сделать нашу систему децентрализованной и открытой, мы решили использовать умные контракты Ethereum. Выбор пал на эту платформу децентрализованных онлайн-сервисов из-за ее популярности и возможности построить serverless-приложение. Мы планировали реализовать наш проект следующим образом.
Но, к сожалению, смарт контракт – это код, исполняемый виртуальной машиной в момент транзакции, и он не может заменить полноценный сервер. Например, смарт контракт не может выполнять отложенные или запланированные действия. В нашем проекте это не позволило реализовать поминутный сервис аренды, как делают большинство современных каршерингов. Поэтому мы списывали криптовалюту с пользователя после завершения операции без уверенности, что у него есть достаточное количество денег. Такой подход приемлем только для внутреннего пилота и, безусловно, добавляет проблем при проектировании полноценного продакшен-проекта.
Ко всему вышесказанному прибавляется сырость самой платформы. Например, написав смарт контракт с логикой, отличной от токенов ERC-20, вы столкнетесь с проблемой обработки ошибок. Обычно при некорректном вводе или неправильной работе наших методов, мы получаем в ответ код ошибки. В случае Ethereum мы не можем получить ничего, кроме количества газа, затраченного на выполнение этой функции. Газ – это валюта, которую необходимо платить за транзакции и вычисления: чем больше операций в вашем коде, тем больше вы заплатите. Поэтому, чтобы понять, почему код не работает, вы сначала тестируете его, симулируя все возможные ошибки, и хардкодите затраченный газ в качестве кода ошибки. Но если вы измените свой код, эта обработка ошибок поломается.
Помимо этого, практически невозможно создать мобильное приложение, работающее с блокчейном по-честному, не используя ключ, хранящийся где-то в облаке. Хотя честные кошельки и существуют, они не предоставляют интерфейсов для подписания внешних транзакций. Это значит, что нативного приложения вам не видать, если в нем не будет встроен крипто-кошелек, к которому у пользователей доверия будет мало (я бы не доверял). В результате тут нам тоже пришлось срезать угол. Смарт контракты доставлялись в приватную сеть Ethereum, а кошелек был облачным. Но несмотря на это, наши пользователи прочувствовали все “прелести" децентрализованных сервисов в виде длительного ожидания транзакций по несколько раз за сессию аренды.
Все это приводит нас к вот такой архитектуре. Согласитесь, она сильно отличается от того, что мы планировали.
Туз в рукаве: Self-Sovereign Identity
Нельзя построить полностью децентрализованную систему без децентрализованной идентификации. За эту часть отвечает Self-Sovereign Identity (SSI), суть которой заключается в том, что вы выкидываете централизованный провайдер идентичности (IDP) и раздаете народу все данные и ответственность за них. Теперь пользователь сам решает, какие данные ему нужны и с кем он будет ими делиться. Вся эта информация находится на устройстве пользователя. Но для обмена нам понадобится децентрализованная система хранения криптографических доказательств. Все современные реализации концепции SSI используют блокчейн в качестве хранилища.
“При чем тут туз в рукаве?” — спросите вы. Сервис мы запускали для внутреннего теста на своих же сотрудниках в Берлине и Бонне, и перед нами возникли трудности в лице немецких профсоюзов. В Германии компаниям запрещено следить за перемещениями сотрудников, и профсоюзы это контролируют. Эти ограничения ставят крест на централизованном хранении данных удостоверений пользователей, так как в этом случае нам было бы известно местонахождение сотрудников. В то же время не проверять их мы не могли из-за возможности угона скутеров. Но благодаря Self-Sovereign Identity наши юзеры пользовались системой анонимно, и наличие водительских прав сам скутер проверял у них перед стартом аренды. В результате у нас хранились обезличенные метрики пользователей, никаких документов и личных данных у нас не было: все они содержались на устройствах самих водителей. Таким образом, благодаря SSI решение проблемы в нашем проекте было готово еще до ее появления.
Устройство подкинуло проблем
Мы не реализовывали самостоятельно Self-Sovereign Identity, так как это требует экспертизы в криптографии и большого количества времени. Вместо этого мы воспользовались продуктом наших партнеров Jolocom и интегрировали их мобильный кошелек и сервисы в нашу платформу. К сожалению, этот продукт обладает одним существенным минусом: основной язык разработки Node.js.
Такой технологический стек очень сильно ограничивает нас в выборе железа, встраиваемого в скутер. К счастью, в самом начале проекта наш выбор пал на Raspberry Pi Zero, и мы воспользовались всеми преимуществами полноценного микрокомпьютера. Это позволило нам запустить громоздкий Node.js на скутере. Помимо этого мы получили мониторинг и удаленный доступ через vpn, используя готовые инструменты.
В заключение
Несмотря на всю “боль” и проблемы, проект был запущен. Не все работало как мы планировали, но на скутерах действительно можно было покататься, взяв их в аренду.
Да, мы допустили ряд ошибок при проектировании архитектуры, которые не позволили нам сделать сервис полностью децентрализованным, но даже без этих ошибок нам вряд ли удалось бы создать serverless платформу. Одно дело писать очередную крипто-пирамиду и совсем другое — полноценный сервис, в котором надо обрабатывать ошибки, решать пограничные кейсы и выполнять отложенные задания. Будем надеяться на то, что появившиеся в недавнее время новые платформы будут более гибкими и функциональными.
Источник: habr.com