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