I den här artikeln kommer jag att prata om hur vi försökte bygga decentraliserad skoteruthyrning på smarta kontrakt och varför vi fortfarande behövde en centraliserad tjänst.
Hur det hela började
I november 2018 deltog vi i ett hackathon dedikerat till Internet of Things och blockchain. Vårt team valde skoterdelning som en idé eftersom vi hade en skoter från sponsorn av detta hackathon. Prototypen såg ut som en mobilapplikation som låter dig starta en skoter via NFC. Ur marknadsföringssynpunkt stöddes idén av en berättelse om en ”ljus framtid” med ett öppet ekosystem där vem som helst kan bli hyresgäst eller hyresvärd, allt baserat på smarta kontrakt.
Våra intressenter gillade verkligen den här idén och de bestämde sig för att göra om den till en prototyp för utställning på utställningar. Efter flera framgångsrika demonstrationer på Mobile World Congress och Bosch Connected World 2019 beslutades det att testa skoteruthyrningen med riktiga användare, Deutsche Telekom-anställda. Så vi började utveckla en fullfjädrad MVP.
Blockchain på kryckor
Jag tycker inte att det är värt att förklara vad skillnaden är mellan ett projekt som ska visas på scen och ett som ska användas av riktiga människor. På sex månader var vi tvungna att förvandla den råa prototypen till något lämpligt för en pilot. Och då förstod vi vad "smärta" betyder.
För att göra vårt system decentraliserat och öppet beslutade vi att använda Ethereums smarta kontrakt. Valet föll på denna plattform av decentraliserade onlinetjänster på grund av dess popularitet och förmågan att bygga en serverlös applikation. Vi planerade att genomföra vårt projekt enligt följande.
Men tyvärr är ett smart kontrakt en kod som exekveras av en virtuell maskin vid tidpunkten för en transaktion, och den kan inte ersätta en fullfjädrad server. Ett smart kontrakt kan till exempel inte utföra väntande eller schemalagda åtgärder. I vårt projekt tillät detta oss inte att implementera en minututhyrningstjänst, som de flesta moderna bildelningstjänster gör. Därför debiterade vi kryptovaluta från användaren efter att ha slutfört transaktionen utan att vara säkra på att han hade tillräckligt med pengar. Detta tillvägagångssätt är endast acceptabelt för en intern pilot och skapar naturligtvis problem vid utformningen av ett fullfjädrat produktionsprojekt.
Till allt ovanstående är fuktigheten i själva plattformen. Till exempel, om du skriver ett smart kontrakt med logik som skiljer sig från ERC-20-tokens, kommer du att stöta på felhanteringsproblem. Om inmatningen är felaktig eller om våra metoder inte fungerar korrekt får vi vanligtvis en felkod som svar. När det gäller Ethereum kan vi inte få något annat än mängden gas som spenderas för att utföra denna funktion. Gas är en valuta som måste betalas för transaktioner och beräkningar: ju fler operationer i din kod, desto mer kommer du att betala. Så för att förstå varför koden inte fungerar testar du den först genom att simulera alla möjliga fel och hårdkoda gasen som förbrukats som en felkod. Men om du ändrar din kod kommer denna felhantering att gå sönder.
Dessutom är det nästan omöjligt att skapa en mobilapplikation som fungerar med blockkedjan ärligt, utan att använda en nyckel lagrad någonstans i molnet. Även om det finns ärliga plånböcker, tillhandahåller de inga gränssnitt för att signera externa transaktioner. Detta innebär att du inte kommer att se en inbyggd applikation om den inte har en inbyggd kryptoplånbok, som användare kommer att ha lite förtroende för (jag skulle inte lita på den). Det gjorde att vi även här fick klippa ett hörn. Smarta kontrakt levererades till det privata Ethereum-nätverket, och plånboken var molnbaserad. Men trots detta upplevde våra användare alla "läckerheter" med decentraliserade tjänster i form av långa väntan på transaktioner flera gånger per hyresession.
Allt detta leder oss till denna arkitektur. Håller med, det är väldigt annorlunda än vad vi planerat.
Ess i hålet: Självsuverän identitet
Du kan inte bygga ett helt decentraliserat system utan decentraliserad identitet. Self-Sovereign Identity (SSI) ansvarar för denna del, vars essens är att man kastar ut den centraliserade identitetsleverantören (IDP) och distribuerar all data och ansvaret för det till folket. Nu bestämmer användaren vilken data han behöver och med vem han ska dela den. All denna information finns på användarens enhet. Men för utbytet kommer vi att behöva ett decentraliserat system för lagring av kryptografiska bevis. Alla moderna implementeringar av SSI-konceptet använder blockchain som lagring.
"Vad har detta med ess i hålet att göra?" - du frågar. Vi lanserade tjänsten för intern testning av våra egna anställda i Berlin och Bonn och vi stötte på svårigheter i form av tyska fackföreningar. I Tyskland är det förbjudet för företag att övervaka anställdas rörelser, och fackföreningarna kontrollerar detta. Dessa begränsningar sätter stopp för centraliserad lagring av användaridentitetsdata, eftersom vi i det här fallet skulle veta var de anställda befinner sig. Samtidigt kunde vi inte låta bli att kontrollera dem på grund av risken för att skotrar skulle bli stulna. Men tack vare Self-Sovereign Identity använde våra användare systemet anonymt, och skotern själv kontrollerade sitt körkort innan uthyrningen påbörjades. Som ett resultat lagrade vi anonyma användarstatistik; vi hade inga dokument eller personuppgifter: de fanns alla på förarnas enheter. Således, tack vare SSI, var lösningen på problemet i vårt projekt klar redan innan den dök upp.
Enheten gav mig problem
Vi implementerade inte Self-Sovereign Identity själva, eftersom det kräver expertis inom kryptografi och mycket tid. Istället utnyttjade vi våra partners Jolocoms produkt och integrerade deras mobila plånbok och tjänster i vår plattform. Tyvärr har denna produkt en betydande nackdel: det huvudsakliga utvecklingsspråket är Node.js.
Denna teknikstapel begränsar i hög grad vårt val av hårdvara inbyggd i en skoter. Lyckligtvis valde vi i början av projektet Raspberry Pi Zero, och vi utnyttjade alla fördelarna med en fullfjädrad mikrodator. Detta gjorde att vi kunde köra skrymmande Node.js på skotern. Dessutom fick vi övervakning och fjärråtkomst via VPN med hjälp av färdiga verktyg.
Sammanfattningsvis
Trots all "smärta" och problem lanserades projektet. Allt fungerade inte som vi planerat, men det gick verkligen att åka skoter genom att hyra dem.
Ja, vi gjorde ett antal misstag när vi designade arkitekturen som inte tillät oss att göra tjänsten helt decentraliserad, men även utan dessa misstag hade vi knappast kunnat skapa en serverlös plattform. Det är en sak att skriva en annan krypto-pyramid, och en helt annan att skriva en fullfjädrad tjänst där du behöver hantera fel, lösa gränsfall och utföra pågående uppgifter. Låt oss hoppas att de nya plattformarna som har dykt upp nyligen kommer att vara mer flexibla och funktionella.
Källa: will.com