I denne artikel vil jeg fortælle om, hvordan vi forsøgte at opbygge en decentraliseret scooterudlejning baseret på smart contracts, og hvorfor vi stadig havde brug for en centraliseret tjeneste.
Hvordan det hele begyndte
I november 2018 deltog vi i et hackathon, der handlede om Internet of Things og blockchain. Som idé valgte vores team scooterudlejning, da vi havde en scooter fra sponsoren af hackathonet. Prototypen så ud som en mobilapp, der gjorde det muligt at starte scooteren via NFC. Fra et marketingperspektiv blev idéen understøttet af fortællingen om en "lys fremtid" med et åbent økosystem, hvor alle kunne blive udlejer eller lejer, alt sammen baseret på smarte kontrakter.
Denne idé faldt i god jord hos vores interessenter, og de besluttede at omdanne den til en prototype til demonstration på messer. Efter flere succesfulde præsentationer på Mobile World Congress og Bosch Connected World i 2019 blev det besluttet at teste scooterudlejningen på rigtige brugere, medarbejdere fra Deutsche Telekom. Så begyndte vi at udvikle et fuldt fungerende MVP.
Blockchain på krykker
Jeg tror, det er unødvendigt at forklare forskellen mellem et projekt til fremvisning på scenen og et, som rigtige mennesker vil bruge. På seks måneder skulle vi omdanne en rå prototype til noget der var egnet til et pilotprojekt. Og her indså vi, hvad "smerte" betød.
For at gøre vores system decentraliseret og åbent besluttede vi at bruge Ethereum smarte kontrakter. Valget faldt på denne platform for decentraliserede online-tjenester på grund af dens popularitet og muligheden for at bygge en serverless-applikation. Vi planlagde at realisere vores projekt på følgende måde.
Men desværre er en smart kontrakt – en kode, der udføres af en virtuel maskine i det øjeblik, transaktionen finder sted – og kan ikke erstatte en fuldgyldig. serverFor eksempel kan en smart kontrakt ikke udføre udskudte eller planlagte handlinger. I vores projekt har det ikke gjort det muligt at implementere et minut-for-minut leje service, som de fleste moderne biludlejningssystemer gør. Derfor blev kryptovaluta trukket fra brugeren efter afslutningen af operationen uden at være sikker på, at de havde nok penge. Denne tilgang er kun acceptabel for en intern pilot og tilføjer bestemt problemer ved designet af et fuldt produktionsprojekt.
Til alt dette kommer fugtigheden i selve platformen. For eksempel, hvis du skriver en smart kontrakt med logik, der adskiller sig fra ERC-20 tokens, vil du støde på problemet med fejlbehandling. Normalt, ved forkert input eller forkert funktion af vores metoder, får vi en fejlmeddelelse som svar. I tilfælde af Ethereum kan vi ikke få andet end den mængde gas, der er brugt til at udføre denne funktion. Gas er den valuta, der skal betales for transaktioner og beregninger: jo flere operationer der er i din kode, jo mere betaler du. Derfor, for at forstå, hvorfor koden ikke fungerer, tester du den først ved at simulere alle mulige fejl og hardcode den anvendte gas som fejlmeddelelse. Men hvis du ændrer din kode, vil denne fejlbehandling ikke fungere.
Derudover er det næsten umuligt at oprette en mobilapp, der arbejder med blockchain på en ærlig måde, uden at bruge en nøgle, der opbevares et eller andet sted i skyen. Selvom ærlige tegnebøger findes, tilbyder de ikke grænseflader til at underskrive eksterne transaktioner. Det betyder, at du ikke kan forvente en native app, medmindre der er indbygget en kryptotegnebog, som brugerne vil have lidt tillid til (jeg ville ikke stole på det). Som et resultat måtte vi også skære hjørner her. Smart kontrakter blev leveret til det private Ethereum-netværk, og tegnebogen var i skyen. Men på trods af dette oplevede vores brugere alle "fornøjelserne" ved decentraliserede tjenester i form af lang ventetid på transaktioner flere gange i løbet af lejesessionen.
Alt dette fører os til en sådan arkitektur. Enig, det er meget forskelligt fra hvad vi planlagde.
Es i ærmet: Selvstyret identitet
Man kan ikke bygge et helt decentraliseret system uden decentraliseret identifikation. Denne del varetages af Self-Sovereign Identity (SSI), hvis essens er, at man kasserer den centraliserede identitetsudbyder (IDP) og giver folk alle data og ansvar for dem. Nu beslutter brugeren selv, hvilke data de har brug for, og hvem de vil dele dem med. Al denne information opbevares på brugerens enhed. Men for at dele dataene har vi brug for et decentraliseret system til opbevaring af kryptografiske beviser. Alle moderne implementeringer af SSI-konceptet bruger blockchain som lager.
"Hvad har en es i ærmet med det at gøre?" - vil du spørge. Vi lancerede tjenesten til intern test på vores egne medarbejdere i Berlin og Bonn, og vi stødte på vanskeligheder i form af de tyske fagforeninger. I Tyskland er det forbudt for virksomheder at overvåge medarbejdernes bevægelser, og fagforeningerne kontrollerer dette. Disse begrænsninger sætter en stopper for centraliseret opbevaring af brugerindeks data, da vi i så fald ville have kendskab til medarbejdernes opholdssteder. Samtidig kunne vi ikke undlade at kontrollere dem på grund af muligheden for scootertyveri. Men takket være Self-Sovereign Identity kunne vores brugere benytte systemet anonymt, og scooteren kontrollerede automatisk deres kørekort inden lejeaftalen startede. Som et resultat havde vi anonymiserede brugerdata opbevaret, og vi havde ingen dokumenter eller personlige oplysninger: alle disse blev opbevaret på chaufførens egne enheder. Dermed var løsningen på problemet i vores projekt klar, inden det overhovedet opstod.
Enheden gav os problemer
Vi har ikke selv implementeret Self-Sovereign Identity, da det kræver ekspertise inden for kryptografi og en betydelig mængde tid. I stedet brugte vi et produkt fra vores partner Jolocom og integrerede deres mobiltegnebog og tjenester i vores platform. Desværre har dette produkt én væsentlig ulempe: hovedprogrammeringssproget er Node.js.
Denne teknologistak begrænser os kraftigt i valget af hardware, der kan integreres i scooteren. Heldigvis valgte vi i starten af projektet Raspberry Pi Zero, og vi kunne udnytte alle fordelene ved en fuld mikrocomputer. Dette gjorde det muligt for os at køre en krævende Node.js på scooteren. Derudover fik vi overvågning og fjernadgang gennem vpn, ved at anvende de tilgængelige værktøjer.
Afslutningsvis
På trods af al "smerten" og problemerne blev projektet lanceret. Ikke alt fungerede som planlagt, men det var faktisk muligt at køre på scootere, når man lejede dem.
Ja, vi begik en række fejl i designet af arkitekturen, som forhindrede os i at gøre tjenesten helt decentraliseret, men selv uden disse fejl ville det næppe have været muligt for os at skabe en serverless platform. Det er én ting at skrive endnu en kryptopyramide, og noget helt andet at lave en fuldgyldig tjeneste, hvor man skal håndtere fejl, løse grænsetilfælde og udføre forsinkede opgaver. Lad os håbe, at de nye platforme, der er dukket op for nylig, bliver mere fleksible og funktionelle.
Kilde: habr.com
