I denne artikel vil jeg fortælle om, hvordan vi forsøgte at bygge decentraliseret scooterudlejning på smarte kontrakter, og hvorfor vi stadig havde brug for en centraliseret service.
Hvordan det hele begyndte
I november 2018 deltog vi i et hackathon dedikeret til Internet of Things og blockchain. Vores team valgte scooterdeling som en idé, da vi havde en scooter fra sponsoren af dette hackathon. Prototypen lignede en mobilapplikation, der giver dig mulighed for at starte en scooter via NFC. Fra et markedsføringssynspunkt blev ideen understøttet af en historie om en "lys fremtid" med et åbent økosystem, hvor enhver kan blive lejer eller udlejer, alt sammen baseret på smarte kontrakter.
Vores interessenter kunne virkelig godt lide denne idé, og de besluttede at gøre den til en prototype til udstilling på udstillinger. Efter flere succesfulde demonstrationer på Mobile World Congress og Bosch Connected World i 2019, blev det besluttet at teste scooterudlejningen med rigtige brugere, Deutsche Telekom-medarbejdere. Så vi begyndte at udvikle en fuldgyldig MVP.
Blockchain på krykker
Jeg synes ikke, det er værd at forklare, hvad forskellen er mellem et projekt, der skal vises på scenen, og et, der skal bruges af rigtige mennesker. På seks måneder skulle vi lave den rå prototype om til noget, der var egnet til en pilot. Og så forstod vi, hvad "smerte" betyder.
For at gøre vores system decentraliseret og åbent besluttede vi at bruge Ethereum smarte kontrakter. Valget faldt på denne platform af decentraliserede onlinetjenester på grund af dens popularitet og evnen til at bygge en serverløs applikation. Vi planlagde at gennemføre vores projekt som følger.
Men desværre er en smart kontrakt en kode, der udføres af en virtuel maskine på tidspunktet for en transaktion, og den kan ikke erstatte en fuldgyldig server. For eksempel kan en smart kontrakt ikke udføre afventende eller planlagte handlinger. I vores projekt tillod dette os ikke at implementere en lejeservice pr. minut, som de fleste moderne delebilstjenester gør. Derfor debiterede vi cryptocurrency fra brugeren efter at have gennemført transaktionen uden at være sikker på, at han havde penge nok. Denne tilgang er kun acceptabel for en intern pilot og tilføjer naturligvis problemer, når man designer et fuldgyldigt produktionsprojekt.
Føjet til alt ovenstående er fugten af selve platformen. For eksempel, hvis du skriver en smart kontrakt med logik forskellig fra ERC-20-tokens, vil du støde på fejlhåndteringsproblemer. Normalt, hvis input er forkert, eller vores metoder ikke fungerer korrekt, modtager vi en fejlkode som svar. I tilfælde af Ethereum kan vi ikke få andet end den mængde gas, der bruges til at udføre denne funktion. Gas er en valuta, der skal betales for transaktioner og beregninger: Jo flere operationer i din kode, jo mere betaler du. Så for at forstå hvorfor koden ikke virker, tester du den først ved at simulere alle mulige fejl og hardkode den brugte gas som en fejlkode. Men hvis du ændrer din kode, vil denne fejlhåndtering gå i stykker.
Derudover er det næsten umuligt at lave en mobilapplikation, der fungerer med blockchain ærligt, uden at bruge en nøgle gemt et sted i skyen. Selvom der findes ærlige tegnebøger, giver de ikke grænseflader til at underskrive eksterne transaktioner. Dette betyder, at du ikke vil se en indbygget applikation, medmindre den har en indbygget krypto-pung, som brugerne vil have ringe tillid til (jeg ville ikke stole på den). Derfor måtte vi også skære et hjørne her. Smarte kontrakter blev leveret til det private Ethereum-netværk, og tegnebogen var cloud-baseret. Men på trods af dette oplevede vores brugere alle "glæderne" ved decentraliserede tjenester i form af lange ventetider på transaktioner flere gange pr. lejesession.
Alt dette fører os til denne arkitektur. Enig, det er meget anderledes, end vi havde planlagt.
Es i hullet: Self-Sovereign Identity
Man kan ikke bygge et fuldstændig decentraliseret system uden decentraliseret identitet. Self-Sovereign Identity (SSI) er ansvarlig for denne del, hvis essens er, at du smider den centraliserede identitetsudbyder (IDP) ud og distribuerer alle data og ansvaret for det til folket. Nu bestemmer brugeren, hvilke data han har brug for, og hvem han vil dele dem med. Alle disse oplysninger er placeret på brugerens enhed. Men til udvekslingen har vi brug for et decentraliseret system til lagring af kryptografiske beviser. Alle moderne implementeringer af SSI-konceptet bruger blockchain som opbevaring.
"Hvad har dette at gøre med esset i hullet?" - du spørger. Vi lancerede tjenesten til intern test på vores egne medarbejdere i Berlin og Bonn, og vi stødte på vanskeligheder i form af tyske fagforeninger. I Tyskland er det forbudt for virksomheder at overvåge medarbejdernes færden, og fagforeningerne kontrollerer dette. Disse begrænsninger sætter en stopper for centraliseret lagring af brugeridentitetsdata, da vi i dette tilfælde ville kende medarbejdernes placering. Samtidig kunne vi ikke lade være med at tjekke dem på grund af muligheden for, at scootere blev stjålet. Men takket være Self-Sovereign Identity brugte vores brugere systemet anonymt, og scooteren tjekkede selv deres kørekort, før de startede udlejningen. Som et resultat gemte vi anonyme brugermålinger; vi havde ingen dokumenter eller personlige data: de var alle indeholdt på chaufførernes enheder. Takket være SSI var løsningen på problemet i vores projekt således klar, allerede før den dukkede op.
Enheden gav mig problemer
Vi har ikke selv implementeret Self-Sovereign Identity, da det kræver ekspertise i kryptografi og meget tid. I stedet udnyttede vi vores partnere Jolocoms produkt og integrerede deres mobile tegnebog og tjenester i vores platform. Desværre har dette produkt en væsentlig ulempe: det vigtigste udviklingssprog er Node.js.
Denne teknologistabel begrænser i høj grad vores valg af hardware indbygget i en scooter. Heldigvis valgte vi i begyndelsen af projektet Raspberry Pi Zero, og vi udnyttede alle fordelene ved en fuldgyldig mikrocomputer. Dette gjorde det muligt for os at køre voluminøse Node.js på scooteren. Derudover modtog vi overvågning og fjernadgang via VPN ved hjælp af færdige værktøjer.
Afslutningsvis
På trods af al "smerten" og problemerne blev projektet lanceret. Ikke alt fungerede som vi havde planlagt, men det var virkelig muligt at køre på scooter ved at leje dem.
Ja, vi lavede en række fejl ved design af arkitekturen, som ikke tillod os at gøre tjenesten fuldstændig decentral, men selv uden disse fejl ville vi næppe have været i stand til at skabe en serverløs platform. En ting er at skrive endnu en kryptopyramide, og noget andet er at skrive en fuldgyldig tjeneste, hvor du skal håndtere fejl, løse grænsetilfælde og udføre afventende opgaver. Lad os håbe, at de nye platforme, der er dukket op for nylig, vil være mere fleksible og funktionelle.
Kilde: www.habr.com