В тази статия ще ви разкажа как се опитахме да изградим децентрализирана услуга за наем на скутери на базата на смарт контракти и защо все пак ни трябваше централизирана услуга.
Как всичко започна
През ноември 2018 г. участвахме в хакатон, посветен на интернет на нещата и блокчейн. Идеята, която избрахме за нашия екип, беше за споделяне на скутери, тъй като разполагахме със скутер от спонсора на хакатона. Прототипът изглеждаше като мобилно приложение, което позволяваше стартиране на скутера чрез NFC. От маркетингова гледна точка, идеята беше подсилена с разказ за "светлото бъдеще" с отворена екосистема, в която всеки може да бъде наемател или наемодател, всичко това на база на смарт контракти.
Тази идея много хареса на нашите заинтересовани страни и те решиха да я превърнат в прототип за демонстрация на изложения. След няколко успешни представяния на Mobile World Congress и Bosch Connected World през 2019 г., беше взето решение да тестваме наема на скутери с реални потребители, служители на Deutsche Telekom. Така започнахме разработката на напълно функциониращо MVP.
Блокчейн на патерици
Мисля, че няма нужда да обяснявам каква е разликата между проект, предназначен за показ на сцена, и такъв, който ще ползват реални хора. За шест месеца трябваше да преобразим суровия прототип в нещо, подходящо за пилот. И тук разбрахме какво означава "болка".
За да направим нашата система децентрализирана и отворена, решихме да използваме смарт контракти на Ethereum. Изборът падна на тази платформа за децентрализирани онлайн услуги заради нейната популярност и възможността да изградим безсървърно приложение. Планирахме да реализираме нашия проект по следния начин.
Но, за съжаление, смарт контрактът е код, изпълняван от виртуалната машина в момента на транзакцията и не може да замести пълноценен сървър. Например, смарт контрактът не може да извършва отложени или планирани действия. В нашия проект това не ни позволи да реализираме поминутна услуга за наем, както правят повечето съвременни каршерингови услуги. Поради това списвахме криптовалута от потребителя след завършване на операцията без сигурност, че разполага с достатъчно средства. Такъв подход е приемлив само за вътрешен пилот и, безусловно, добавя проблеми при проектирането на напълно функционален продукт.
Към всичко изброено по-горе се добавя и влагата на самата платформа. Например, ако напишете смарт контракт с логика, различна от токените ERC-20, ще се сблъскате с проблема с обработката на грешки. Обикновено, при неправилен вход или неправилна работа на нашите методи, получаваме код на грешката. В случая с Ethereum, не можем да получим нищо освен количеството газ, изразходвано за изпълнение на тази функция. Газът е валута, която трябва да се плаща за транзакции и изчисления: колкото повече операции има във вашия код, толкова повече ще платите. Ето защо, за да разберете защо кодът не работи, първо трябва да го тествате, симулирайки всички възможни грешки, и ръчно кодирайте изразходвания газ като код на грешка. Но ако промените кода си, тази обработка на грешките ще се счупи.
Освен това, практически е невъзможно да се създаде мобилно приложение, работещо с blockchain по честен начин, без да се използва ключ, съхраняван някъде в облака. Въпреки че честни портфейли съществуват, те не предлагат интерфейси за подписване на външни транзакции. Това означава, че нативно приложение няма да видите, освен ако в него не бъде вграден крипто портфейл, на който потребителите да нямат доверие (аз не бих доверил). В резултат на това тук също трябваше да изрежем ъгъл. Смарт договорите бяха предадени в частната мрежа на Ethereum, а портфейлът беше облачен. Но въпреки това, нашите потребители усетиха всички "прелести" на децентрализираните услуги в лицето на дългото чакане на транзакции няколко пъти в рамките на сесията на наем.
Всичко това ни довежда до такава архитектура. Съгласете се, че тя се различава значително от това, което планирахме.
Туз в ръкава: Самоуправляваща се идентичност
Не може да се построи напълно децентрализирана система без децентрализирана идентификация. За тази част отговаря 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
