V tem članku bom govoril o tem, kako smo poskušali zgraditi decentraliziran najem skuterjev na pametnih pogodbah in zakaj smo še vedno potrebovali centralizirano storitev.
Kako se je vse začelo
Novembra 2018 smo se udeležili hackathona, posvečenega Internetu stvari in blockchainu. Naša ekipa je kot idejo izbrala deljenje skuterjev, saj smo imeli skuter od sponzorja tega hackathona. Prototip je bil videti kot mobilna aplikacija, ki omogoča zagon skuterja prek NFC. Z marketinškega vidika je bila ideja podkrepljena z zgodbo o »svetli prihodnosti« z odprtim ekosistemom, kjer lahko vsak postane najemnik ali najemodajalec, vse na podlagi pametnih pogodb.
Našim deležnikom je bila ta ideja zelo všeč in odločili so se, da jo spremenijo v prototip za prikaz na razstavah. Po več uspešnih demonstracijah na Mobile World Congress in Bosch Connected World leta 2019 je bilo odločeno, da najem skuterjev preizkusimo pri dejanskih uporabnikih, zaposlenih v Deutsche Telekomu. Tako smo začeli razvijati polnopravni MVP.
Blockchain na berglah
Mislim, da ni vredno razlagati, kakšna je razlika med projektom, ki bo prikazan na odru, in tistim, ki ga bodo uporabljali resnični ljudje. V šestih mesecih smo morali surovi prototip spremeniti v nekaj primernega za pilota. In potem smo razumeli, kaj pomeni "bolečina".
Da bi naš sistem naredili decentraliziran in odprt, smo se odločili za uporabo pametnih pogodb Ethereum. Izbira je padla na to platformo decentraliziranih spletnih storitev zaradi njene priljubljenosti in možnosti izdelave aplikacije brez strežnika. Naš projekt smo nameravali izvesti na naslednji način.
Toda na žalost je pametna pogodba koda, ki jo izvede virtualni stroj v času transakcije, in ne more nadomestiti polnopravnega strežnika. Na primer, pametna pogodba ne more izvajati čakajočih ali načrtovanih dejanj. V našem projektu nam to ni omogočilo implementacije storitve minutnega najema, kot to počne večina sodobnih storitev souporabe vozil. Zato smo po opravljeni transakciji od uporabnika bremenili kriptovaluto, ne da bi bili prepričani, da ima dovolj denarja. Ta pristop je sprejemljiv samo za interni pilot in seveda dodaja težave pri oblikovanju polnopravnega proizvodnega projekta.
K vsemu naštetemu je dodana tudi vlažnost same ploščadi. Na primer, če napišete pametno pogodbo z logiko, ki se razlikuje od žetonov ERC-20, boste naleteli na težave pri obravnavanju napak. Običajno, če vnos ni pravilen ali naše metode ne delujejo pravilno, v odgovor prejmemo kodo napake. V primeru Ethereuma ne moremo dobiti ničesar drugega kot količino plina, porabljenega za izvajanje te funkcije. Plin je valuta, ki jo je treba plačati za transakcije in izračune: več kot je operacij v vaši kodi, več boste plačali. Če želite razumeti, zakaj koda ne deluje, jo najprej preizkusite tako, da simulirate vse možne napake in porabljeni plin trdo kodirate kot kodo napake. Toda če spremenite svojo kodo, bo ta obravnava napak prekinjena.
Poleg tega je skoraj nemogoče ustvariti mobilno aplikacijo, ki pošteno deluje z blockchainom, brez uporabe ključa, shranjenega nekje v oblaku. Čeprav obstajajo poštene denarnice, ne nudijo vmesnikov za podpisovanje zunanjih transakcij. To pomeni, da ne boste videli izvorne aplikacije, razen če ima vgrajeno kripto denarnico, ki ji bodo uporabniki malo zaupali (jaz ji ne bi zaupal). Posledično smo tudi tu morali presekati ovinek. Pametne pogodbe so bile dostavljene v zasebno omrežje Ethereum, denarnica pa je temeljila na oblaku. Toda kljub temu so naši uporabniki izkusili vse »prijete« decentraliziranih storitev v obliki dolgega čakanja na transakcije večkrat na sejo najema.
Vse to nas pripelje do te arhitekture. Strinjam se, zelo se razlikuje od tistega, kar smo načrtovali.
As v luknji: Samostojna suverena identiteta
Ne morete zgraditi popolnoma decentraliziranega sistema brez decentralizirane identitete. Za ta del je odgovoren Self-Sovereign Identity (SSI), katerega bistvo je, da centralizirani ponudnik identitete (IDP) zavržeš in vse podatke in odgovornost zanje razdeliš ljudem. Zdaj se uporabnik odloči, katere podatke potrebuje in s kom jih bo delil. Vsi ti podatki se nahajajo na uporabnikovi napravi. Toda za izmenjavo bomo potrebovali decentraliziran sistem za shranjevanje kriptografskih dokazov. Vse sodobne izvedbe koncepta SSI uporabljajo blockchain kot shrambo.
"Kaj ima to opraviti z asom v luknji?" - vprašate. Zagnali smo storitev za interno testiranje na lastnih zaposlenih v Berlinu in Bonnu, pri čemer smo naleteli na težave v obliki nemških sindikatov. V Nemčiji je podjetjem prepovedano spremljanje gibanja zaposlenih, sindikati pa to nadzorujejo. Te omejitve odpravljajo centralizirano shranjevanje podatkov o identiteti uporabnikov, saj bi v tem primeru poznali lokacijo zaposlenih. Hkrati pa si nismo mogli pomagati, da jih ne bi preverili zaradi možnosti kraje skuterjev. Toda zahvaljujoč Self-Sovereign Identity so naši uporabniki sistem uporabljali anonimno, skuter pa je pred začetkom najema preveril njihovo vozniško dovoljenje. Posledično smo shranili anonimne uporabniške meritve; nismo imeli nobenih dokumentov ali osebnih podatkov: vsi so bili na napravah samih voznikov. Tako je bila po zaslugi SSI rešitev problema v našem projektu pripravljena, še preden se je pojavila.
Naprava mi je povzročala težave
Self-Sovereign Identity nismo implementirali sami, saj zahteva strokovno znanje na področju kriptografije in veliko časa. Namesto tega smo izkoristili produkt naših partnerjev Jolocom in integrirali njihovo mobilno denarnico in storitve v našo platformo. Na žalost ima ta izdelek eno pomembno pomanjkljivost: glavni razvojni jezik je Node.js.
Ta tehnološki sklop močno omejuje našo izbiro strojne opreme, vgrajene v skuter. Na srečo smo na samem začetku projekta izbrali Raspberry Pi Zero in izkoristili vse prednosti polnopravnega mikroračunalnika. To nam je omogočilo zagon obsežnega Node.js na skuterju. Poleg tega smo prejeli nadzor in oddaljeni dostop prek VPN z že pripravljenimi orodji.
Na koncu
Kljub vsem »bolečinam« in težavam je projekt stekel. Ni šlo vse tako, kot smo načrtovali, se je pa res dalo voziti skuterje z izposojo.
Da, pri načrtovanju arhitekture smo naredili številne napake, ki nam niso omogočile popolne decentralizacije storitve, a tudi brez teh napak nam težko bi uspelo ustvariti brezstrežniško platformo. Ena stvar je napisati še eno kripto-piramido in povsem druga stvar je napisati popolno storitev, v kateri morate obravnavati napake, reševati mejne primere in opravljati čakajoče naloge. Upajmo, da bodo nove platforme, ki so se nedavno pojavile, bolj prilagodljive in funkcionalne.
Vir: www.habr.com