W tym artykule opowiem, jak próbowaliśmy stworzyć zdecentralizowany system wynajmu skuterów oparty na smart kontraktach i dlaczego mimo to potrzebowaliśmy scentralizowanej usługi.
Jak to się wszystko zaczęło
W listopadzie 2018 roku wzięliśmy udział w hackathonie poświęconym Internetowi Rzeczy i blockchainowi. Nasz zespół wybrał jako pomysł skuter-sharing, ponieważ posiadaliśmy skuter od sponsora tego hackathonu. Prototyp wyglądał jak aplikacja mobilna, która pozwalała na uruchomienie skutera za pomocą NFC. Z perspektywy marketingowej, pomysł wspierała narracja o "jasnej przyszłości" z otwartym ekosystemem, w którym każdy może stać się najemcą lub wynajmującym, a wszystko to oparte na inteligentnych kontraktach.
Pomysł bardzo spodobał się naszym interesariuszom, którzy postanowili przekształcić go w prototyp do zaprezentowania na wystawach. Po kilku udanych pokazach na Mobile World Congress i Bosch Connected World w 2019 roku podjęto decyzję o przetestowaniu wynajmu skuterów na realnych użytkownikach, pracownikach Deutsche Telekom. Tak rozpoczęliśmy rozwój pełnoprawnego MVP.
Blockchain na kuli u nogi
Myślę, że nie trzeba tłumaczyć, jaka jest różnica między projektem pokazowym a tym, z którego będą korzystać rzeczywiści ludzie. W ciągu sześciu miesięcy mieliśmy do przekształcenia surowy prototyp w coś odpowiedniego do pilota. I tutaj zrozumieliśmy, co to znaczy "ból".
Aby uczynić nasz system zdecentralizowanym i otwartym, postanowiliśmy użyć inteligentnych kontraktów Ethereum. Wybór padł na tę platformę zdecentralizowanych usług online ze względu na jej popularność i możliwość stworzenia aplikacji bezserwerowej. Planujemy zrealizować nasz projekt w następujący sposób.
Niestety, smart kontrakt to kod, który jest wykonywany przez wirtualną maszynę w momencie transakcji i nie może zastąpić pełnoprawnej serwer. Na przykład, smart kontrakt nie może wykonywać opóźnionych ani zaplanowanych działań. W naszym projekcie nie pozwoliło to na wdrożenie minutowego serwisu wynajmu, jak to robi większość nowoczesnych systemów car-sharingowych. Dlatego obciążyliśmy użytkownika kryptowalutą po zakończeniu operacji bez pewności, że ma on wystarczającą ilość środków. Takie podejście jest akceptowalne tylko dla wewnętrznego pilota i niewątpliwie wprowadza problemy przy projektowaniu pełnoprawnego projektu produkcyjnego.
Do wcześniej wymienionych kwestii dochodzi wilgoć samej platformy. Na przykład, pisząc smart kontrakt z logiką różniącą się od tokenów ERC-20, napotkasz problem z obsługą błędów. Zwykle, w przypadku nieprawidłowego wejścia lub błędnego działania naszych metod, otrzymujemy odpowiedź z kodem błędu. W przypadku Ethereum nie możemy otrzymać nic oprócz ilości gazu zużytego na wykonanie tej funkcji. Gaz to waluta, którą trzeba zapłacić za transakcje i obliczenia: im więcej operacji w twoim kodzie, tym więcej zapłacisz. Dlatego, aby zrozumieć, dlaczego kod nie działa, najpierw testujesz go, symulując wszystkie możliwe błędy, i twardo kodujesz zużyty gaz jako kod błędu. Ale jeśli zmienisz swój kod, ta obsługa błędów przestaje działać.
Oprócz tego, praktycznie niemożliwe jest stworzenie mobilnej aplikacji działającej z blockchainem uczciwie, nie używając klucza przechowywanego gdzieś w chmurze. Choć uczciwe portfele istnieją, nie oferują one interfejsów do podpisywania zewnętrznych transakcji. Oznacza to, że natywnej aplikacji nie zobaczysz, jeśli nie zostanie w niej wbudowany portfel kryptograficzny, któremu użytkownicy będą mało ufać (ja bym nie ufał). W rezultacie musieliśmy tutaj również pójść na skróty. Smart kontrakty były dostarczane do prywatnej sieci Ethereum, a portfel był w chmurze. Mimo to, nasi użytkownicy doświadczyli wszystkich „uroków” zdecentralizowanych usług w postaci długiego oczekiwania na transakcje kilkukrotnie podczas sesji wynajmu.
Wszystko to prowadzi nas do takiej architektury. Przyznasz, że różni się ona znacznie od tego, co planowaliśmy.
As w rękawie: Tożsamość samowystarczalna
Nie można zbudować w pełni zdecentralizowanego systemu bez zdecentralizowanej identyfikacji. Za tę część odpowiada Self-Sovereign Identity (SSI), której istotą jest to, że rezygnujesz z centralnego dostawcy tożsamości (IDP) i przekazujesz ludziom wszystkie dane oraz odpowiedzialność za nie. Teraz użytkownik sam decyduje, jakie dane są mu potrzebne i z kim będzie się nimi dzielił. Cała ta informacja znajduje się na urządzeniu użytkownika. Ale do wymiany potrzebujemy zdecentralizowanego systemu przechowywania kryptograficznych dowodów. Wszystkie współczesne realizacje koncepcji SSI wykorzystują blockchain jako miejsce przechowywania.
„Co ma wspólnego as w rękawie?” — zapytacie. Usługę uruchamialiśmy dla wewnętrznego testu wśród własnych pracowników w Berlinie i Bonn, a przed nami pojawiły się trudności ze strony niemieckich związków zawodowych. W Niemczech firmom zabrania się śledzenia ruchów pracowników, a związki zawodowe to kontrolują. Te ograniczenia skutkują tym, że nie możemy przechowywać danych identyfikacyjnych użytkowników w sposób scentralizowany, ponieważ w takim przypadku wiedzielibyśmy, gdzie znajdują się pracownicy. Z drugiej strony nie mogliśmy ich nie sprawdzać z powodu możliwości kradzieży skuterów. Ale dzięki Self-Sovereign Identity nasi użytkownicy korzystali z systemu anonimowo, a sam skuter weryfikował ich prawo jazdy przed rozpoczęciem wynajmu. W rezultacie posiadaliśmy zanonimizowane metryki użytkowników, nie mieliśmy żadnych dokumentów ani danych osobowych: wszystkie były przechowywane na urządzeniach samych kierowców. Tak więc, dzięki SSI rozwiązanie problemu w naszym projekcie było gotowe jeszcze przed jego pojawieniem się.
Urządzenie przyniosło problemy
Nie wdrażaliśmy samodzielnie Self-Sovereign Identity, ponieważ wymaga to 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 oraz usługi z naszą platformą. Niestety, ten produkt ma jeden istotny minus: głównym językiem programowania jest Node.js.
Ten stół technologiczny bardzo ogranicza nas w wyborze sprzętu, który można zastosować w skuterze. Na szczęście, na samym początku projektu zdecydowaliśmy się na Raspberry Pi Zero, co umożliwiło nam skorzystanie ze wszystkich zalet pełnoprawnego mikrokontrolera. Dzięki temu mogliśmy uruchomić rozbudowany Node.js na skuterze. Oprócz tego uzyskaliśmy monitorowanie i zdalny dostęp przez vpn, korzystając z gotowych narzędzi.
Na zakończenie
Mimo wszystkich trudności i problemów, projekt został uruchomiony. Nie wszystko działało tak, jak planowaliśmy, ale na skuterach rzeczywiście można było pojeździć, wynajmując je.
Tak, popełniliśmy kilka błędów w projektowaniu architektury, które uniemożliwiły nam stworzenie w pełni zdecentralizowanej usługi, ale nawet bez tych błędów trudno byłoby nam stworzyć platformę typu serverless. Inna sprawa to pisanie kolejnej kryptowalutowej piramidy, a zupełnie inna – stworzenie pełnoprawnej usługi, w której trzeba obsługiwać błędy, rozwiązywać przypadki graniczne i wykonywać zadania opóźnione. Miejmy nadzieję, że nowe platformy, które pojawiły się w ostatnim czasie, będą bardziej elastyczne i funkcjonalne.
Źródło: habr.com
