I den hÀr artikeln kommer jag att berÀtta om hur vi försökte bygga en decentraliserad scootersharing-tjÀnst med smarta kontrakt och varför vi fortfarande behövde en centraliserad tjÀnst.
SÄ hur började allt
I november 2018 deltog vi i en hackathon som handlade om IoT och blockchain. Som idé valde vÄrt team scootersharing, eftersom vi hade en scooter frÄn sponsorn av hackathonet. Prototypen sÄg ut som en mobilapp som gjorde det möjligt att starta scootern via NFC. Ur ett marknadsföringsperspektiv förstÀrktes idén av en berÀttelse om en "ljus framtid" med en öppen ekosystem, dÀr alla kan bli hyresgÀst eller uthyrare, allt baserat pÄ smarta kontrakt.
Denna idé uppskattades mycket av vÄra intressenter, och de beslutade att förvandla den till en prototyp för visning pÄ mÀssor. Efter flera framgÄngsrika uppvisningar pÄ Mobile World Congress och Bosch Connected World 2019 fattades beslutet att testa scootersharing pÄ riktiga anvÀndare, anstÀllda hos Deutsche Telekom. SÄ vi började utveckla en fullt fungerande MVP.
Blockchain pÄ kryckor
Jag tror inte att det behöver förklaras vilken skillnad det Àr mellan ett projekt för visning pÄ scen och ett som riktiga mÀnniskor kommer att anvÀnda. Under sex mÄnader hade vi som mÄl att förvandla en rÄ prototyp till nÄgot som Àr lÀmpligt för en pilot. Och hÀr insÄg vi vad "smÀrta" betyder.
För att göra vÄrt system decentraliserat och öppet beslutade vi att anvÀnda Ethereum-smarta kontrakt. Valet föll pÄ denna plattform för decentraliserade onlinetjÀnster pÄ grund av dess popularitet och möjligheten att bygga en serverlös applikation. Vi planerade att genomföra vÄrt projekt pÄ följande sÀtt.
Men tyvÀrr Àr ett smart kontrakt kod som exekveras av en virtuell maskin vid tidpunkten för transaktionen, och det kan inte ersÀtta ett fullt fungerande server. Till exempel kan ett smart kontrakt inte utföra fördröjda eller schemalagda ÄtgÀrder. I vÄrt projekt gjorde detta det omöjligt att implementera minut-till-minut hyrningstjÀnst, som de flesta moderna bilpooler gör. DÀrför debiterade vi kryptovaluta frÄn anvÀndaren efter att operationen avslutats utan att vara sÀkra pÄ att han hade tillrÀckligt med pengar. Denna strategi Àr acceptabel endast för en intern pilot och tillför utan tvekan problem vid utformningen av ett fullt fungerande produktionsprojekt.
Till allt som sagts ovan lÀggs till fuktigheten i plattformen. Om du till exempel skriver ett smart kontrakt med logik som skiljer sig frÄn ERC-20-token kommer du att möta problem med felhantering. Vanligtvis fÄr vi en felkod som svar pÄ felaktig inmatning eller om vÄra metoder fungerar fel. I Ethereum kan vi inte fÄ nÄgot annat Àn mÀngden gas som anvÀnds för att köra denna funktion. Gas Àr den valuta som mÄste betalas för transaktioner och berÀkningar: ju fler operationer du har i din kod, desto mer fÄr du betala. DÀrför, för att förstÄ varför koden inte fungerar, testar du först koden genom att simulera alla möjliga fel och hÄrdkodar den anvÀnda gasen som felkod. Men om du Àndrar din kod kommer denna felhantering att brytas.
Dessutom Ă€r det praktiskt taget omöjligt att skapa en mobilapplikation som arbetar med blockkedjan pĂ„ ett korrekt sĂ€tt utan att anvĂ€nda en nyckel som lagras nĂ„gonstans i molnet. Ăven om Ă€rliga plĂ„nböcker finns, tillhandahĂ„ller de inte grĂ€nssnitt för att signera externa transaktioner. Det betyder att du inte kommer att ha en inbyggd kryptoplĂ„nbok i din app, vilket anvĂ€ndarna förmodligen inte kommer att lita pĂ„ (jag skulle inte lita pĂ„ det). Som ett resultat fick vi ocksĂ„ kompromissa hĂ€r. Smarta kontrakt levererades till det privata Ethereum-nĂ€tverket, och plĂ„nboken var molnbaserad. Men trots detta upplevde vĂ„ra anvĂ€ndare alla "fördelar" med decentraliserade tjĂ€nster i form av lĂ„ng vĂ€ntetid för transaktioner flera gĂ„nger per uthyrningssession.
Allt detta leder oss till en sÄdan arkitektur. HÄller ni inte med om att den skiljer sig kraftigt frÄn vad vi planerade.
Ett ess i rockÀrmen: SjÀlvförsörjande identitet
Det gÄr inte att bygga ett helt decentraliserat system utan decentraliserad identifikation. Den delen ansvarar Self-Sovereign Identity (SSI), vilket innebÀr att du slÀpper det centraliserade identitetsleverantören (IDP) och ger folket all data och ansvar för den. Nu bestÀmmer anvÀndaren sjÀlv vilka uppgifter han eller hon behöver och med vem som ska delas. All denna information finns pÄ anvÀndarens enhet. Men för att utbyta behöver vi ett decentraliserat system för lagring av kryptografiska bevis. Alla moderna implementeringar av SSI-konceptet anvÀnder blockchain som lagringsyta.
âVad har ni för ess i rockĂ€rmen?â frĂ„gar ni. Vi lanserade tjĂ€nsten för intern testning bland vĂ„ra anstĂ€llda i Berlin och Bonn, och vi stötte pĂ„ svĂ„righeter i form av tyska fackföreningar. I Tyskland Ă€r företagen förbjudna att följa sina anstĂ€lldas rörelser, och fackföreningarna kontrollerar detta. Dessa begrĂ€nsningar sĂ€tter stopp för centraliserad lagring av anvĂ€ndaridentiteter, eftersom vi i sĂ„ fall skulle veta var anstĂ€llda befinner sig. Samtidigt kunde vi inte lĂ„ta bli att kontrollera dem pĂ„ grund av risken för skotertjuvning. Men tack vare Self-Sovereign Identity anvĂ€nde vĂ„ra anvĂ€ndare systemet anonymt, och skotern kontrollerade deras körkort innan hyresstarten. Som ett resultat hade vi anonymiserad anvĂ€ndardata, inga dokument eller personuppgifter var lagrade hos oss: allt fanns pĂ„ förarnas enheter. SĂ„ledes var lösningen pĂ„ problemet i vĂ„rt projekt fĂ€rdig innan det ens hade uppstĂ„tt.
Enheten stötte pÄ problem
Vi implementerade inte sjÀlva Self-Sovereign Identity, eftersom detta krÀver expertis inom kryptografi och en stor mÀngd tid. IstÀllet anvÀnde vi en produkt frÄn vÄra partners, Jolocom, och integrerade deras mobila plÄnbok och tjÀnster i vÄr plattform. TyvÀrr har denna produkt en betydande nackdel: huvudsprÄket för utveckling Àr Node.js.
Denna teknologiska stack begrÀnsar oss kraftigt i valet av hÄrdvara som kan integreras i skotern. Lyckligtvis föll vÄrt val i början av projektet pÄ Raspberry Pi Zero, och vi kunde utnyttja alla fördelar med en komplett mikrocomputer. Detta gjorde det möjligt för oss att köra den skrymmande Node.js pÄ skotern. Dessutom fick vi övervakning och fjÀrrÄtkomst genom vpn, med hjÀlp av fÀrdiga verktyg.
Avslutningsvis
Trots all "smÀrta" och problem, lanserades projektet. Inte allt fungerade som vi planerat, men det var faktiskt möjligt att Äka skoter genom att hyra dem.
Ja, vi gjorde ett antal misstag vid utformningen av arkitekturen, vilket hindrade oss frÄn att göra tjÀnsten helt decentraliserad, men Àven utan dessa misstag skulle vi knappast ha lyckats skapa en serverlös plattform. Det Àr en sak att skriva Ànnu en kryptopyramid och en helt annan att skapa en fullstÀndig tjÀnst dÀr man mÄste hantera fel, lösa grÀnsfall och utföra försenade uppgifter. LÄt oss hoppas att de nya plattformar som nyligen har dykt upp blir mer flexibla och funktionella.
KĂ€lla: habr.com
