În acest articol, voi povesti despre cum am încercat să construim un serviciu descentralizat de închiriere a trotinetelor pe baza contractelor inteligente și de ce a fost nevoie totuși de un serviciu centralizat.
Cum a început totul
În noiembrie 2018, am participat la un hackathon dedicat internetului lucrurilor și blockchain. Ca idee, echipa noastră a ales închirierea trotinetelor, având un scuter de la sponsorul hackathon-ului. Prototipul arăta ca o aplicație mobilă care permitea pornirea scuterului prin NFC. Din punct de vedere al marketingului, ideea era susținută de o poveste despre un „viitor luminos” cu un ecosistem deschis, unde oricine poate deveni chiriaș sau proprietar, totul bazat pe contracte inteligente.
Această idee le-a plăcut foarte mult stakeholder-ilor noștri, iar ei au decis să o transforme într-un prototip pentru a fi prezentat la expoziții. După câteva prezentări de succes la Mobile World Congress și Bosch Connected World în 2019, s-a decis să testăm închirierea trotinetelor pe utilizatori reali, angajați ai Deutsche Telekom. Așa am început dezvoltarea unui MVP complet.
Blockchain pe crutches
Cred că nu este nevoie să explicăm care este diferența între un proiect de prezentare pe scenă și unul folosit de utilizatori reali. În cele șase luni, trebuia să transformăm prototipul brut în ceva potrivit pentru un pilot. Și atunci am înțeles ce înseamnă „durere”.
Pentru a face sistemul nostru descentralizat și deschis, am decis să folosim contracte inteligente Ethereum. Am ales această platformă de servicii online descentralizate datorită popularității sale și a posibilității de a construi o aplicație serverless. Ne-am planificat să implementăm proiectul nostru în felul următor.
Dar, din păcate, un contract inteligent este un cod executat de o mașină virtuală în momentul tranzacției și nu poate înlocui un sistem complet. serverul. De exemplu, un smart contract nu poate executa acțiuni amânate sau planificate. În proiectul nostru, acest lucru a împiedicat implementarea unui serviciu de închiriere minute, așa cum fac majoritatea platformelor moderne de carsharing. Așadar, imobilizăm criptovaluta de la utilizator după finalizarea operațiunii fără a fi siguri că are suficiente fonduri. Această abordare este acceptabilă doar pentru un pilot intern și, fără îndoială, adaugă probleme în proiectarea unui proiect complet funcțional.
Pe lângă cele menționate anterior, se adaugă umiditatea platformei în sine. De exemplu, dacă scrieți un smart contract cu o logica diferită de tokenurile ERC-20, vă veți confrunta cu problema gestionării erorilor. De obicei, în cazul unei introduceri incorecte sau al unei funcționări greșite a metodelor noastre, primim un cod de eroare ca răspuns. În cazul Ethereum, nu putem obține nimic altceva decât cantitatea de gaz consumată pentru a executa această funcție. Gazul este moneda pe care trebuie să o plătiți pentru tranzacții și calcule: cu cât aveți mai multe operațiuni în codul dvs., cu atât veți plăti mai mult. Prin urmare, pentru a înțelege de ce codul nu funcționează, trebuie să-l testați simulând toate posibilele erori și codificând gazul consumat ca și cod de eroare. Dar, dacă modificați codul, această gestionare a erorilor se va strica.
În plus, este practic imposibil să creați o aplicație mobilă care să funcționeze corect cu blockchain-ul fără a utiliza o cheie stocată undeva în cloud. Deși portofelele corecte există, ele nu oferă interfețe pentru semnarea tranzacțiilor externe. Asta înseamnă că nu veți avea o aplicație nativă, dacă nu va include un portofel cripto, în care utilizatorii nu au multă încredere (eu nu aș avea). Ca urmare, și aici a trebuit să facem un compromis. Smart contractele erau livrate într-o rețea privată Ethereum, iar portofelul era în cloud. Dar, în ciuda acestui lucru, utilizatorii noștri au resimțit toate "chicotelile" serviciilor descentralizate sub forma așteptărilor lungi pentru tranzacții de câteva ori pe sesiune de închiriere.
Toate acestea ne conduc la o astfel de arhitectură. Sunteți de acord, aceasta este foarte diferită de ceea ce am planificat.
Asul din mânecă: Identitatea auto-suverană
Nu se poate construi un sistem complet descentralizat fără identificare descentralizată. Acest aspect este gestionat de Self-Sovereign Identity (SSI), care constă în faptul că eliminăm un furnizor centralizat de identitate (IDP) și oferim oamenilor toate datele și responsabilitatea pentru ele. Acum utilizatorul decide singur ce date îi sunt necesare și cu cine va împărtăși aceste date. Toate aceste informații se află pe dispozitivul utilizatorului. Dar pentru schimb, ne va trebui un sistem descentralizat de stocare a dovezilor criptografice. Toate implementările moderne ale conceptului SSI utilizează blockchain ca storage.
„Ce legătură are asta cu un as în mânecă?” – veți întreba. Serviciul l-am lansat pentru un test intern pe angajații noștri din Berlin și Bonn, iar în fața noastră au apărut dificultăți legate de sindicatele germane. În Germania, companiilor le este interzis să urmărească mișcările angajaților, iar sindicatele controlează acest aspect. Aceste restricții pun capăt stocării centralizate a datelor de identificare a utilizatorilor, deoarece în acest caz am fi știut locația angajaților. Totodată, nu puteam să nu-i verificăm din cauza riscului de furt al scuterelor. Dar, datorită Self-Sovereign Identity, utilizatorii noștri au utilizat sistemul în mod anonim, iar scuterul verifica automat permisul de conducere înainte de a începe închirierea. În rezultat, am păstrat metrici anonimizate ale utilizatorilor, fără documente și date personale: toate acestea erau stocate pe dispozitivele șoferilor înșiși. Astfel, datorită SSI, soluția problemei în proiectul nostru a fost gata înainte de a se ivi.
Dispozitivul a generat probleme
Nu am implementat noi înșine Self-Sovereign Identity, deoarece acest lucru necesită expertiză în criptografie și mult timp. În schimb, am folosit produsul partenerilor noștri Jolocom și am integrat portofelul lor mobil și serviciile în platforma noastră. Din păcate, acest produs are un dezavantaj semnificativ: principala limbaj de dezvoltare este Node.js.
Această tehnologie ne limitează foarte mult în alegerea hardware-ului integrat în scuter. Din fericire, la începutul proiectului, am ales Raspberry Pi Zero și am profitat de toate avantajele unui microcomputer complet. Acest lucru ne-a permis să rulăm Node.js complex pe scuter. În plus, am obținut monitorizare și acces de la distanță prin vpn, folosind instrumente deja pregătite.
În concluzie
În ciuda tuturor "dureroaselor" probleme, proiectul a fost lansat. Nu totul a funcționat așa cum ne-am planificat, dar pe scutere chiar se putea merge, închiriindu-le.
Da, am făcut o serie de greșeli în proiectarea arhitecturii, care nu ne-au permis să facem serviciul complet descentralizat, dar chiar și fără aceste erori, ne-ar fi fost greu să creăm o platformă serverless. Este o diferență să scrii o altă piramidă crypto și să dezvolți un serviciu complet, în care trebuie să gestionezi erori, să rezolvi cazuri limită și să execuți sarcini planificate. Să sperăm că noile platforme apărute recent vor fi mai flexibile și funcționale.
Sursa: habr.com
