W tym artykule opowiem o tym, jak próbowaliśmy zbudować zdecentralizowaną wypożyczalnię hulajnóg w oparciu o inteligentne kontrakty i dlaczego nadal potrzebowaliśmy scentralizowanej usługi.
Jak to wszystko się zaczęło
W listopadzie 2018 wzięliśmy udział w hackatonie poświęconym Internetowi Rzeczy i blockchainowi. Nasz zespół wybrał dzielenie się hulajnogą jako pomysł, ponieważ mieliśmy hulajnogę od sponsora tego hackatonu. Prototyp wyglądał jak aplikacja mobilna umożliwiająca uruchomienie hulajnogi poprzez NFC. Z marketingowego punktu widzenia pomysł został wsparty opowieścią o „świetlanej przyszłości” z otwartym ekosystemem, w którym każdy może zostać najemcą lub wynajmującym, a wszystko w oparciu o inteligentne kontrakty.
Naszym interesariuszom bardzo spodobał się ten pomysł i postanowili przekształcić go w prototyp do prezentacji na wystawach. Po kilku udanych demonstracjach na Mobile World Congress i Bosch Connected World w 2019 roku zdecydowano się przetestować wypożyczenie hulajnogi z prawdziwymi użytkownikami, pracownikami Deutsche Telekom. Zaczęliśmy więc pracować nad pełnoprawnym MVP.
Blockchain o kulach
Chyba nie warto tłumaczyć, jaka jest różnica pomiędzy projektem, który ma być pokazany na scenie, a takim, z którego będą korzystać realni ludzie. W ciągu sześciu miesięcy musieliśmy zamienić prymitywny prototyp w coś odpowiedniego dla pilota. I wtedy zrozumieliśmy, co oznacza „ból”.
Aby nasz system był zdecentralizowany i otwarty, zdecydowaliśmy się na wykorzystanie inteligentnych kontraktów Ethereum. Wybór padł na tę platformę zdecentralizowanych usług online ze względu na jej popularność i możliwość zbudowania aplikacji bezserwerowej. Planowaliśmy zrealizować nasz projekt w następujący sposób.
Ale niestety inteligentny kontrakt to kod wykonywany przez maszynę wirtualną w momencie transakcji i nie może zastąpić pełnoprawnego serwera. Na przykład inteligentny kontrakt nie może wykonywać oczekujących lub zaplanowanych działań. W naszym projekcie nie pozwoliło to na wdrożenie usługi wynajmu na minuty, jak robi to większość nowoczesnych usług carsharingu. Dlatego też po zakończeniu transakcji pobraliśmy od użytkownika kryptowalutę, nie mając pewności, czy ma on wystarczającą ilość pieniędzy. Takie podejście jest dopuszczalne tylko w przypadku pilota wewnętrznego i oczywiście powoduje dodatkowe problemy przy projektowaniu pełnoprawnego projektu produkcyjnego.
Do tego wszystkiego dochodzi wilgoć samej platformy. Na przykład, jeśli napiszesz inteligentny kontrakt z logiką inną niż tokeny ERC-20, napotkasz problemy z obsługą błędów. Zwykle, jeśli dane wejściowe są nieprawidłowe lub nasze metody nie działają poprawnie, w odpowiedzi otrzymujemy kod błędu. W przypadku Ethereum nie możemy uzyskać niczego poza ilością gazu wydanego na wykonanie tej funkcji. Gaz to waluta, którą należy zapłacić za transakcje i obliczenia: im więcej operacji w kodzie, tym więcej zapłacisz. Aby zrozumieć, dlaczego kod nie działa, najpierw przetestuj go, symulując wszystkie możliwe błędy i zakoduj na stałe zużyty gaz jako kod błędu. Ale jeśli zmienisz kod, obsługa błędów zostanie przerwana.
Poza tym prawie niemożliwe jest stworzenie aplikacji mobilnej, która uczciwie współpracuje z blockchainem, bez użycia klucza przechowywanego gdzieś w chmurze. Chociaż istnieją uczciwe portfele, nie zapewniają one interfejsów do podpisywania transakcji zewnętrznych. Oznacza to, że nie zobaczysz aplikacji natywnej, jeśli nie będzie ona miała wbudowanego portfela kryptowalut, do którego użytkownicy nie będą mieli zaufania (ja bym temu nie ufał). W rezultacie i tutaj musieliśmy pójść na skróty. Inteligentne kontrakty dostarczane były do prywatnej sieci Ethereum, a portfel działał w chmurze. Mimo to nasi użytkownicy doświadczyli wszystkich „rozkoszy” zdecentralizowanych usług w postaci długiego oczekiwania na transakcje kilka razy w ciągu sesji wynajmu.
Wszystko to prowadzi nas do tej architektury. Zgadzam się, bardzo różni się od tego, co planowaliśmy.
As w rękawie: tożsamość suwerenna
Nie można zbudować całkowicie zdecentralizowanego systemu bez zdecentralizowanej tożsamości. Za tę część odpowiada Self-Sovereign Identity (SSI), której istota polega na tym, że należy wyrzucić scentralizowanego dostawcę tożsamości (IDP) i przekazać ludziom wszystkie dane i odpowiedzialność za nie. Teraz użytkownik decyduje, jakich danych potrzebuje i komu je udostępni. Wszystkie te informacje znajdują się na urządzeniu użytkownika. Ale do wymiany będziemy potrzebować zdecentralizowanego systemu przechowywania dowodów kryptograficznych. Wszystkie współczesne implementacje koncepcji SSI wykorzystują blockchain jako pamięć masową.
„Co to ma wspólnego z asem w rękawie?” - ty pytasz. Uruchomiliśmy usługę testów wewnętrznych na własnych pracownikach w Berlinie i Bonn i napotkaliśmy trudności w postaci niemieckich związków zawodowych. W Niemczech firmom nie wolno monitorować przemieszczania się pracowników, a związki zawodowe to kontrolują. Ograniczenia te kładą kres scentralizowanemu przechowywaniu danych dotyczących tożsamości użytkownika, ponieważ w tym przypadku znalibyśmy lokalizację pracowników. Jednocześnie nie mogliśmy ich nie sprawdzić ze względu na możliwość kradzieży hulajnogi. Jednak dzięki Self-Sovereign Identity nasi użytkownicy korzystali z systemu anonimowo, a sam hulajnoga przed rozpoczęciem wypożyczenia sprawdzał ich prawo jazdy. W rezultacie przechowywaliśmy anonimowe dane o użytkownikach, nie mieliśmy żadnych dokumentów ani danych osobowych: wszystkie znajdowały się na urządzeniach samych kierowców. Tym samym dzięki SSI rozwiązanie problemu w naszym projekcie było gotowe jeszcze zanim się pojawił.
Urządzenie sprawiło mi problemy
Nie wdrożyliśmy samodzielnie Tożsamości Suwerennej, ponieważ wymaga ona wiedzy z zakresu kryptografii i dużej ilości czasu. Zamiast tego skorzystaliśmy z produktu naszych partnerów Jolocom i zintegrowaliśmy ich mobilny portfel i usługi z naszą platformą. Niestety produkt ten ma jedną istotną wadę: głównym językiem programowania jest Node.js.
Ten stos technologii znacznie ogranicza nasz wybór sprzętu wbudowanego w hulajnogę. Na szczęście już na początku projektu wybraliśmy Raspberry Pi Zero i wykorzystaliśmy wszystkie zalety pełnoprawnego mikrokomputera. Umożliwiło nam to uruchomienie nieporęcznego Node.js na hulajnodze. Dodatkowo otrzymaliśmy monitoring i zdalny dostęp poprzez VPN z wykorzystaniem gotowych narzędzi.
Na zakończenie
Pomimo wszystkich „bólów” i problemów projekt ruszył. Nie wszystko udało się tak jak planowaliśmy, ale wypożyczając hulajnogi naprawdę można było pojeździć.
Tak, projektując architekturę popełniliśmy szereg błędów, które nie pozwoliły nam na całkowitą decentralizację usługi, ale nawet bez tych błędów raczej nie bylibyśmy w stanie stworzyć platformy bezserwerowej. Czym innym jest napisanie kolejnej kryptopiramidy, a czym innym napisanie pełnoprawnej usługi, w której trzeba obsługiwać błędy, rozwiązywać przypadki graniczne i wykonywać oczekujące zadania. Miejmy nadzieję, że nowe platformy, które pojawiły się ostatnio, będą bardziej elastyczne i funkcjonalne.
Źródło: www.habr.com