I denne artikkelen vil jeg snakke om hvordan vi prøvde å bygge desentralisert scooterutleie på smarte kontrakter og hvorfor vi fortsatt trengte en sentralisert tjeneste.
Hvordan det hele begynte
I november 2018 deltok vi i et hackathon dedikert til tingenes internett og blokkjede. Teamet vårt valgte scooterdeling som en idé siden vi hadde en scooter fra sponsoren av dette hackathonet. Prototypen så ut som en mobilapplikasjon som lar deg starte en sparkesykkel via NFC. Fra et markedsføringssynspunkt ble ideen støttet av en historie om en «lys fremtid» med et åpent økosystem der hvem som helst kan bli leietaker eller utleier, alt basert på smarte kontrakter.
Våre interessenter likte denne ideen, og de bestemte seg for å gjøre den om til en prototype for utstilling på utstillinger. Etter flere vellykkede demonstrasjoner på Mobile World Congress og Bosch Connected World i 2019, ble det besluttet å teste scooterutleien med ekte brukere, Deutsche Telekom-ansatte. Så vi begynte å utvikle en fullverdig MVP.
Blockchain på krykker
Jeg synes ikke det er verdt å forklare hva forskjellen er mellom et prosjekt som skal vises på scenen og et som skal brukes av ekte mennesker. På seks måneder måtte vi gjøre den rå prototypen om til noe egnet for en pilot. Og så forsto vi hva "smerte" betyr.
For å gjøre systemet vårt desentralisert og åpent, bestemte vi oss for å bruke Ethereum smarte kontrakter. Valget falt på denne plattformen med desentraliserte nettjenester på grunn av dens popularitet og muligheten til å bygge en serverløs applikasjon. Vi planla å gjennomføre prosjektet vårt som følger.
Men dessverre er en smart kontrakt en kode som kjøres av en virtuell maskin på tidspunktet for en transaksjon, og den kan ikke erstatte en fullverdig server. En smart kontrakt kan for eksempel ikke utføre ventende eller planlagte handlinger. I vårt prosjekt tillot dette oss ikke å implementere en leietjeneste per minutt, slik de fleste moderne bildelingstjenester gjør. Derfor debiterte vi kryptovaluta fra brukeren etter å ha fullført transaksjonen uten å være sikker på at han hadde nok penger. Denne tilnærmingen er bare akseptabel for en intern pilot og legger selvfølgelig til problemer når man designer et fullverdig produksjonsprosjekt.
I tillegg til alt det ovennevnte er fuktigheten til selve plattformen. Hvis du for eksempel skriver en smart kontrakt med logikk som er forskjellig fra ERC-20-tokens, vil du støte på feilhåndteringsproblemer. Vanligvis, hvis inndata er feil eller metodene våre ikke fungerer som de skal, mottar vi en feilkode som svar. Når det gjelder Ethereum, kan vi ikke få noe annet enn mengden gass brukt for å utføre denne funksjonen. Gass er en valuta som må betales for transaksjoner og beregninger: jo flere operasjoner i koden din, jo mer betaler du. Så for å forstå hvorfor koden ikke fungerer, tester du den først ved å simulere alle mulige feil og hardkode gassen som er brukt som en feilkode. Men hvis du endrer koden din, vil denne feilhåndteringen gå i stykker.
I tillegg er det nesten umulig å lage en mobilapplikasjon som fungerer med blokkjeden ærlig, uten å bruke en nøkkel lagret et sted i skyen. Selv om ærlige lommebøker finnes, gir de ikke grensesnitt for signering av eksterne transaksjoner. Dette betyr at du ikke vil se en innebygd applikasjon med mindre den har en innebygd kryptolommebok, som brukere vil ha liten tillit til (jeg ville ikke stole på den). Det gjorde at vi også måtte kutte et hjørne her. Smarte kontrakter ble levert til det private Ethereum-nettverket, og lommeboken var skybasert. Men til tross for dette, opplevde våre brukere alle "gledene" ved desentraliserte tjenester i form av lange ventetider på transaksjoner flere ganger per leieøkt.
Alt dette fører oss til denne arkitekturen. Enig, det er veldig forskjellig fra det vi planla.
Ess i hullet: Self-Sovereign Identity
Du kan ikke bygge et fullstendig desentralisert system uten desentralisert identitet. Self-Sovereign Identity (SSI) er ansvarlig for denne delen, hvor essensen er at du kaster ut den sentraliserte identitetsleverandøren (IDP) og distribuerer all data og ansvaret for det til folket. Nå bestemmer brukeren hvilke data han trenger og hvem han vil dele dem med. All denne informasjonen ligger på brukerens enhet. Men for utvekslingen trenger vi et desentralisert system for lagring av kryptografisk bevis. Alle moderne implementeringer av SSI-konseptet bruker blockchain som lagring.
"Hva har dette med esset i hullet å gjøre?" - du spør. Vi lanserte tjenesten for intern testing på egne ansatte i Berlin og Bonn, og vi møtte vanskeligheter i form av tyske fagforeninger. I Tyskland har bedrifter forbud mot å overvåke ansattes bevegelser, og fagforeningene kontrollerer dette. Disse begrensningene setter en stopper for sentralisert lagring av brukeridentitetsdata, siden vi i dette tilfellet ville vite hvor ansatte befinner seg. Samtidig kunne vi ikke la være å sjekke dem på grunn av muligheten for at scootere ble stjålet. Men takket være Self-Sovereign Identity brukte brukerne våre systemet anonymt, og scooteren sjekket selv førerkortet før utleien startet. Som et resultat lagret vi anonyme brukermålinger; vi hadde ingen dokumenter eller personlige data: de var alle inneholdt på enhetene til sjåførene selv. Dermed, takket være SSI, var løsningen på problemet i prosjektet vårt klar allerede før det dukket opp.
Enheten ga meg problemer
Vi implementerte ikke Self-Sovereign Identity selv, da det krever kompetanse innen kryptografi og mye tid. I stedet tok vi fordel av våre partnere Jolocoms produkt og integrerte deres mobile lommebok og tjenester i plattformen vår. Dessverre har dette produktet en betydelig ulempe: hovedutviklingsspråket er Node.js.
Denne teknologistabelen begrenser vårt valg av maskinvare innebygd i en sparkesykkel i stor grad. Heldigvis, helt i begynnelsen av prosjektet, valgte vi Raspberry Pi Zero, og vi utnyttet alle fordelene med en fullverdig mikrodatamaskin. Dette tillot oss å kjøre klumpete Node.js på scooteren. I tillegg fikk vi overvåking og fjerntilgang via VPN ved hjelp av ferdige verktøy.
i konklusjonen
Til tross for all "smerten" og problemene, ble prosjektet lansert. Ikke alt fungerte som vi planla, men det var virkelig mulig å kjøre scooter ved å leie dem.
Ja, vi gjorde en rekke feil ved utformingen av arkitekturen som ikke tillot oss å gjøre tjenesten helt desentralisert, men selv uten disse feilene hadde vi neppe klart å lage en serverløs plattform. En ting er å skrive en annen kryptopyramide, og en helt annen å skrive en fullverdig tjeneste der du må håndtere feil, løse grensetilfeller og utføre ventende oppgaver. La oss håpe at de nye plattformene som har dukket opp i det siste vil være mer fleksible og funksjonelle.
Kilde: www.habr.com