У цій статті я розповім, як ми намагалися побудувати децентралізований прокат скутерів на смарт контрактах і чому нам все одно знадобився централізований сервіс.
Як все починалося
У листопаді 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