Ebben a cikkben arról fogok beszélni, hogyan próbáltuk meg a decentralizált robogóbérlést okosszerződésekre építeni, és miért volt szükségünk mégis központi szolgáltatásra.
Hogyan kezdődött minden
2018 novemberében részt vettünk a tárgyak internetének és a blokkláncnak szentelt hackathonon. Csapatunk a robogó megosztást választotta ötletnek, mivel volt egy robogónk a hackathon szponzorától. A prototípus úgy nézett ki, mint egy mobilalkalmazás, amellyel NFC-n keresztül indíthatunk robogót. Marketing szempontból az ötletet egy „fényes jövőről” szóló történet támasztotta alá, nyitott ökoszisztémával, ahol bárki bérlővé vagy bérbeadóvá válhat, mindezt intelligens szerződések alapján.
Érintetteknek nagyon tetszett ez az ötlet, és úgy döntöttek, hogy prototípust készítenek belőle kiállításokon. A Mobile World Congress és a Bosch Connected World 2019-es sikeres bemutatója után úgy döntöttek, hogy valódi felhasználókkal, a Deutsche Telekom alkalmazottaival tesztelik a robogókölcsönzést. Elkezdtük tehát egy teljes értékű MVP fejlesztését.
Blockchain mankón
Nem hiszem, hogy érdemes elmagyarázni, mi a különbség a színpadon bemutatandó projekt és a valódi emberek által használt projekt között. Hat hónap alatt a nyers prototípust valami pilóta számára alkalmassá kellett alakítanunk. És akkor megértettük, mit jelent a „fájdalom”.
Annak érdekében, hogy rendszerünket decentralizálttá és nyitottá tegyük, úgy döntöttünk, hogy Ethereum intelligens szerződéseket használunk. A választás a decentralizált online szolgáltatások e platformjára esett a népszerűsége és a szerver nélküli alkalmazás építésének lehetősége miatt. Projektünket az alábbiak szerint terveztük megvalósítani.
De sajnos az intelligens szerződés egy virtuális gép által végrehajtott kód a tranzakció során, és nem helyettesítheti a teljes értékű szervert. Például egy intelligens szerződés nem tud függőben lévő vagy ütemezett műveleteket végrehajtani. Projektünkben ez nem tette lehetővé a percbérlési szolgáltatás megvalósítását, ahogy a legtöbb modern autómegosztó szolgáltatás teszi. Ezért a tranzakció befejezése után kriptovalutát vontunk le a felhasználótól anélkül, hogy biztosak lettünk volna abban, hogy van elég pénze. Ez a megközelítés csak egy belső pilot számára elfogadható, és természetesen problémákat okoz egy teljes értékű gyártási projekt megtervezésekor.
A fentiekhez hozzáadódik magának a platformnak a nedvessége is. Például, ha olyan intelligens szerződést ír, amelynek logikája eltér az ERC-20 tokenektől, akkor hibakezelési problémákkal találkozhat. Általában, ha a bevitel helytelen, vagy a módszereink nem működnek megfelelően, hibakódot kapunk válaszul. Az Ethereum esetében a funkció ellátására elköltött gázmennyiségen kívül mást nem kaphatunk. A gáz egy pénznem, amelyet fizetni kell a tranzakciókért és a számításokért: minél több művelet van a kódban, annál többet kell fizetnie. Tehát annak megértéséhez, hogy a kód miért nem működik, először tesztelje le az összes lehetséges hibát szimulálva, és kódolja a felhasznált gázt hibakódként. De ha megváltoztatja a kódot, ez a hibakezelés megszakad.
Ráadásul szinte lehetetlen olyan mobilalkalmazást létrehozni, amely a blokklánccal őszintén, valahol a felhőben tárolt kulcs használata nélkül működik. Bár léteznek becsületes pénztárcák, nem biztosítanak felületet a külső tranzakciók aláírásához. Ez azt jelenti, hogy nem fog látni natív alkalmazást, hacsak nem rendelkezik beépített kriptopénztárcával, amiben a felhasználók nem fognak bízni (nem bíznék benne). Ebből kifolyólag itt is szögletet kellett vágnunk. Az intelligens szerződéseket a privát Ethereum hálózatba szállították, és a pénztárca felhőalapú volt. Ennek ellenére felhasználóink átélték a decentralizált szolgáltatások minden „örömét” a tranzakciókra való hosszas várakozás formájában, bérlésenként többször is.
Mindez elvezet bennünket ehhez az építészethez. Egyetértek, ez nagyon eltér attól, amit terveztünk.
Ász a lyukban: Self-suverén identitás
Decentralizált identitás nélkül nem lehet teljesen decentralizált rendszert felépíteni. A Self-Sovereign Identity (SSI) felelős ezért a részért, aminek az a lényege, hogy kidobja a centralizált identitásszolgáltatót (IDP), és az ezzel kapcsolatos összes adatot és felelősséget szétosztja az emberek között. Most a felhasználó dönti el, hogy milyen adatokra van szüksége, és kivel osztja meg azokat. Mindezek az információk a felhasználó eszközén találhatók. De a cseréhez szükségünk lesz egy decentralizált rendszerre a kriptográfiai bizonyítékok tárolására. Az SSI koncepció minden modern megvalósítása blokkláncot használ tárolóként.
– Mi köze ennek az ászhoz a lyukban? - kérdezed. A szolgáltatást saját munkatársaink belső tesztelésére indítottuk Berlinben és Bonnban, és nehézségekbe ütköztünk a német szakszervezetek formájában. Németországban tilos a cégeknek nyomon követni a munkavállalók mozgását, a szakszervezetek ezt ellenőrzik. Ezek a korlátozások véget vetnek a felhasználói azonosító adatok központosított tárolásának, hiszen ebben az esetben ismernénk az alkalmazottak tartózkodási helyét. Ugyanakkor nem tudtuk nem ellenőrizni őket a robogók ellopásának lehetősége miatt. De a Self-Sovereign Identity-nek köszönhetően felhasználóink névtelenül használták a rendszert, és maga a robogó ellenőrizte a jogosítványukat a bérlés megkezdése előtt. Ennek eredményeként anonim felhasználói mérőszámokat tároltunk, dokumentumok vagy személyes adatok nem álltak rendelkezésünkre: ezek mind maguk a járművezetők eszközein voltak. Így az SSI-nek köszönhetően projektünkben a probléma megoldása már a megjelenés előtt készen volt.
A készülék problémát okozott
Nem mi magunk valósítottuk meg a Self-Sovereign Identity-t, mivel ez kriptográfiai szakértelmet és sok időt igényel. Ehelyett kihasználtuk partnereink Jolocom termékét, és mobiltárcájukat és szolgáltatásaikat integráltuk platformunkba. Sajnos ennek a terméknek van egy jelentős hátránya: a fő fejlesztési nyelv a Node.js.
Ez a technológiai halom nagymértékben korlátozza a robogókba épített hardver kiválasztását. Szerencsére a projekt legelején a Raspberry Pi Zero-t választottuk, és kihasználtuk a teljes értékű mikroszámítógép minden előnyét. Ez lehetővé tette számunkra, hogy terjedelmes Node.js-t futtassunk a robogón. Ezen kívül VPN-en keresztül, kész eszközökkel monitorozást és távoli hozzáférést kaptunk.
Összefoglalva
Minden „fájdalom” és probléma ellenére a projekt elindult. Nem minden úgy működött, ahogy terveztük, de bérelve tényleg lehetett robogóval közlekedni.
Igen, számos olyan hibát követtünk el az architektúra kialakításakor, amely nem tette lehetővé a szolgáltatás teljes decentralizálását, de ezen hibák nélkül is aligha tudtunk volna szerver nélküli platformot létrehozni. Egy dolog egy újabb kriptopiramist írni, és egészen más egy teljes értékű szolgáltatást írni, amelyben hibákat kell kezelni, határeseteket kell megoldani és függőben lévő feladatokat kell végrehajtani. Reméljük, hogy a közelmúltban megjelent új platformok rugalmasabbak és funkcionálisabbak lesznek.
Forrás: will.com