Ebben a cikkben arról fogok beszélni, hogyan próbáltuk megépíteni a decentralizált robogókölcsönzőt okosszerződéseken alapulva, és miért volt szükségünk mégis központosított szolgáltatásra.
Hogyan kezdődött az egész
2018 novemberében részt vettünk egy hackathonon, amely az Internet of Things-ről és a blokkláncról szólt. Csapatunk ötletéül a robogómegosztást választottuk, mivel a hackathon szponzora biztosított nekünk egy robogót. A prototípus egy mobilalkalmazásként nézett ki, amely lehetővé tette a robogó indítását NFC-n keresztül. A marketing szempontjából az ötletet a „fényes jövő” története támogatta, ahol mindenki válhat bérlővé vagy bérbeadóvá, mindez okosszerződések alapján.
Ez az ötlet nagyon tetszett a részvényeseinknek, ezért úgy döntöttek, hogy prototípussá alakítják a kiállításokra való bemutatáshoz. Miután 2019-ben sikeresen bemutattuk a Mobile World Congress és a Bosch Connected World rendezvényeken, úgy döntöttünk, hogy valós felhasználókkal, a Deutsche Telekom alkalmazottaival teszteljük a robogók kölcsönzését. Így kezdtük el kidolgozni a teljes értékű MVP-t.
A blokklánc mankón.
Azt hiszem, nem kell magyarázni, mi a különbség a színpadon bemutatott projekt és a valós felhasználók által használt projekt között. Hat hónap állt előttünk, hogy a nyers prototípust egy pilótaüzemre alkalmas dologgá alakítsuk. Itt jöttünk rá, mit jelent a „fájdalom”.
Ahhoz, hogy rendszereink decentralizáltak és nyitottak legyenek, úgy döntöttünk, hogy Ethereum okosszerződéseket használunk. Ezt az online decentralizált szolgáltatások platformját népszerűsége és a serverless alkalmazások megvalósításának lehetősége miatt választottuk. A projektünket a következőképpen terveztük megvalósítani.
Sajnos azonban az okosszerződés olyan kód, amely a tranzakció pillanatában fut le egy virtuális gépen, és nem tudja helyettesíteni a teljes értékű szerver. Például egy okosszerződés nem tudja végrehajtani a halasztott vagy ütemezett műveleteket. A mi projektünkben ez megakadályozta a perc-alapú kölcsönzési szolgáltatás megvalósítását, ahogy azt a legtöbb modern autómegosztó teszi. Ezért a tranzakció befejezését követően levontuk a kriptovalutát a felhasználótól, anélkül hogy biztosak lettünk volna benne, hogy elegendő pénz áll rendelkezésre. Ez a megközelítés csak belső teszteléshez alkalmazható, és egyértelműen problémákat okoz a teljes értékű termelési projekt tervezésében.
A platform's inherent dampness adds to everything mentioned above. For instance, if you write a smart contract with logic that differs from ERC-20 tokens, you'll encounter an issue with error handling. Generally, when there is incorrect input or malfunctioning methods, we receive an error code in response. In the case of Ethereum, we can't get anything but the amount of gas spent on executing that function. Gas is the currency you need to pay for transactions and computations: the more operations in your code, the more you'll pay. Therefore, to understand why the code isn't functioning, you first test it by simulating all possible errors and hardcoding the gas spent as the error code. But if you alter your code, this error handling will break.
In addition, it is nearly impossible to create a mobile application that works honestly with the blockchain without using a key stored somewhere in the cloud. Although honest wallets do exist, they do not provide interfaces for signing external transactions. This means you won't see a native application unless it includes a crypto wallet, which users would trust very little (I wouldn't trust it). As a result, we had to cut corners here too. Smart contracts were delivered to a private Ethereum network, and the wallet was cloud-based. Nevertheless, our users felt all the "joys" of decentralized services, experiencing long transaction waits several times during a rental session.
All this leads us to such an architecture. Agree, it's quite different from what we planned.
Ace up the sleeve: Self-Sovereign Identity
Teljesen decentralizált rendszert nem lehet felépíteni decentralizált azonosítás nélkül. Ezt az önálló identitás (SSI) részleg felelőssége, amelynek lényege, hogy elhagyjuk a központosított azonosító szolgáltatót (IDP), és a nép kezébe adjuk az összes adatot és a felelősséget értük. Most a felhasználó saját magának döntheti el, mely adatokra van szüksége és kivel osztja meg őket. Minden információ a felhasználó eszközén található. Azonban a megosztáshoz szükségünk van egy decentralizált rendszerre a kriptográfiai bizonyítékok tárolására. A modern SSI koncepciók mind blockchain-t használnak tárolási megoldásként.
„Mi köze ennek a wetrump-cardhoz?” – kérdezheti. A szolgáltatást belső tesztelés céljából indítottuk el a berlini és bonni munkatársaink körében, és német szakszervezetek által jelentkezett nehézségekkel találkoztunk. Németországban a cégeknek tilos figyelniük a munkavállalók mozgását, ezt a szakszervezetek ellenőrzik. Ezek a korlátozások megakadályozzák a felhasználói azonosítók központosított tárolását, mert ebben az esetben tudnánk a munkavállalók tartózkodási helyét. Ugyanakkor nem ellenőrizhettük őket a robogók ellopásának lehetősége miatt. Azonban a Self-Sovereign Identity révén felhasználóink névtelenül használták a rendszert, és a robogó magát ellenőrizte a vezetői engedély megléte előtt a bérlés megkezdése előtt. Ennek eredményeként névtelenített felhasználói metrikáink voltak, nem tároltunk iratokat vagy személyes adatokat: mindez a sofőrök eszközein található. Így az SSI révén a probléma megoldása projektünkben még a megjelenése előtt kész volt.
Az eszköz problémákat okozott.
Nem valósítottuk meg önállóan a Self-Sovereign Identity-t, mivel ez kriptográfiai szakértelmet és nagy mennyiségű időt igényel. Ehelyett partnereink, a Jolocom termékét használtuk, és integráltuk mobil pénztárcájukat és szolgáltatásaikat a platformunkba. Sajnos ennek a terméknek van egy jelentős hátránya: fő fejlesztési nyelve a Node.js.
Ez a technológiai stack nagyon korlátozza a választási lehetőségeinket a robogóba beépíthető hardverek terén. Szerencsére a projekt kezdetén a Raspberry Pi Zero-ra esett a választásunk, így kihasználhattuk egy teljes értékű mikroszámítógép minden előnyét. Ez lehetővé tette számunkra, hogy nagyméretű Node.js-t futtassunk a robogón. Emellett így monitorozást és távoli hozzáférést is kaptunk vpn, kész eszközök felhasználásával.
Végül
Annak ellenére, hogy minden „fájdalom” és probléma jelentkezett, a projekt elindult. Nem minden működött úgy, ahogyan terveztük, de a robogók valóban használatra kész voltak, bérelhető formában.
Igen, számos hibát követtünk el az architektúra tervezése során, amelyek megakadályozták, hogy a szolgáltatásunk teljes mértékben decentralizált legyen, de még ezek nélkül is nehezen sikerült volna egy serverless platformot létrehoznunk. Egy dolog egy újabb kripto-piramist írni, és egészen más egy teljes értékű szolgáltatást, ahol kezelni kell a hibákat, a határeseteket megoldani és az elhalasztott feladatokat végrehajtani. Reméljük, hogy a közelmúltban megjelent új platformok rugalmasabbak és funkcionálisabbak lesznek.
Forrás: habr.com
