In dit artikel zal ik vertellen over hoe we probeerden een gedecentraliseerde scooterverhuur op te bouwen met slimme contracten en waarom we toch een gecentraliseerde service nodig hadden.
Hoe het allemaal begon
In november 2018 namen we deel aan een hackathon die gewijd was aan het internet der dingen en blockchain. Onze team koos scooterverhuur als idee, omdat we een scooter hadden van de sponsor van deze hackathon. Het prototype leek op een mobiele applicatie die het mogelijk maakte om de scooter via NFC te starten. Vanuit marketingperspectief werd het idee ondersteund door een verhaal over een 'heldere toekomst' met een open ecosysteem, waar iedereen huurder of verhuurder kan worden, en dat alles op basis van slimme contracten.
Dit idee viel goed in de smaak bij onze belanghebbenden, en ze besloten het om te zetten in een prototype voor demonstraties op exposities. Na een aantal succesvolle presentaties op het Mobile World Congress en Bosch Connected World in 2019, werd besloten om de scooterverhuur te testen met echte gebruikers, medewerkers van Deutsche Telekom. Zo begonnen we met de ontwikkeling van een volwaardig MVP.
Blockchain met krukken
Ik denk niet dat ik moet uitleggen wat het verschil is tussen een project voor presentatie op het podium en iets wat echte mensen zullen gebruiken. In zes maanden tijd moesten we het rauwe prototype omvormen tot iets dat geschikt was voor een pilot. En hier realiseerden we ons wat 'pijn' betekent.
Om ons systeem gedecentraliseerd en open te maken, besloten we om Ethereum slimme contracten te gebruiken. De keuze viel op dit platform van gedecentraliseerde online diensten vanwege de populariteit en de mogelijkheid om een serverless applicatie te bouwen. We waren van plan ons project als volgt te realiseren.
Maar helaas, een slim contract is een code die wordt uitgevoerd door een virtuele machine op het moment van de transactie, en het kan een volledig systeem niet vervangen. serverBijvoorbeeld, een slim contract kan geen uitgestelde of geplande acties uitvoeren. In ons project maakte dit het niet mogelijk om een per minuut verhuurdienst te implementeren, zoals de meeste moderne autodelers doen. Daarom maakten we gebruik van cryptocurrency van de gebruiker na afloop van de operatie, zonder zekerheid dat hij voldoende geld had. Deze aanpak is alleen acceptabel voor een interne pilot en voegt zeker problemen toe bij het ontwerpen van een volledig productieproject.
Bovenop het bovenstaande komt de vochtigheid van het platform zelf. Stel dat je een smart contract schrijft met logica die verschilt van ERC-20 tokens, dan kom je voor het probleem te staan van foutafhandeling. Gewoonlijk krijgen we bij onjuiste invoer of een verkeerde werking van onze methoden een foutcode terug. In het geval van Ethereum kunnen we niets krijgen behalve de hoeveelheid gas die verbruikt is voor het uitvoeren van deze functie. Gas is de valuta die moet worden betaald voor transacties en berekeningen: hoe meer bewerkingen in je code, hoe meer je betaalt. Daarom, om te begrijpen waarom de code niet werkt, test je deze eerst door alle mogelijke fouten te simuleren en hardcodeer je het verbruikte gas als foutcode. Maar als je je code aanpast, werkt deze foutafhandeling niet meer.
Bovendien is het praktisch onmogelijk om een mobiele applicatie te maken die eerlijk met de blockchain werkt zonder een sleutel die ergens in de cloud wordt opgeslagen. Hoewel eerlijke wallets bestaan, bieden ze geen interfaces voor het ondertekenen van externe transacties. Dit betekent dat je geen native applicatie zult hebben als er geen crypto-wallet is ingebouwd die gebruikers weinig vertrouwen geeft (ik zou er geen vertrouwen in hebben). Als gevolg hiervan moesten we hier ook een compromis sluiten. Smart contracts werden afgeleverd in het private Ethereum-netwerk, en de wallet was cloud-gebaseerd. Toch hebben onze gebruikers de 'geneugten' van gedecentraliseerde diensten ervaren in de vorm van lange wachttijden voor transacties meerdere keren per huurperiode.
Dit leidt ons naar een dergelijke architectuur. Geef toe, het verschilt sterk van wat we gepland hadden.
Troef in de mouw: Zelfsovereine Identiteit
Je kunt geen volledig gedecentraliseerd systeem bouwen zonder gedecentraliseerde identificatie. Deze verantwoordelijkheid ligt bij Self-Sovereign Identity (SSI), wat inhoudt dat je de gecentraliseerde identiteitsprovider (IDP) weggooit en alle gegevens en verantwoordelijkheden aan het volk geeft. Nu beslist de gebruiker zelf welke gegevens hij nodig heeft en met wie hij die zal delen. Al deze informatie bevindt zich op het apparaat van de gebruiker. Maar voor de uitwisseling hebben we een gedecentraliseerd systeem voor het opslaan van cryptografische bewijzen nodig. Alle moderne implementaties van het SSI-concept gebruiken blockchain als opslag.
“Wat heeft de aas in de mouw hier mee te maken?” zult u vragen. We hebben de dienst opgestart voor een interne test met onze eigen medewerkers in Berlijn en Bonn, en we stuitten op moeilijkheden in de vorm van Duitse vakbonden. In Duitsland is het bedrijven verboden om de bewegingen van werknemers te volgen, en de vakbonden controleren dat. Deze beperkingen zijn een grote hindernis voor de gecentraliseerde opslag van gebruiker ID-gegevens, omdat we in dat geval de locatie van de werknemers zouden weten. Aan de andere kant konden we hen niet niet controleren vanwege de mogelijkheid van scooters die gestolen worden. Maar dankzij Self-Sovereign Identity konden onze gebruikers anoniem gebruik maken van het systeem, en de scooter controleerde hun rijbewijs voordat de huur begon. Als gevolg hadden we geanonimiseerde gebruikersstatistieken, we hadden geen documenten of persoonlijke gegevens: al deze bevonden zich op de apparaten van de bestuurders zelf. Zo was dankzij SSI de oplossing voor ons project al klaar voordat het probleem zich voordeed.
Het apparaat heeft een probleem veroorzaakt.
We hebben Self-Sovereign Identity niet zelf geïmplementeerd, omdat dit expertise in cryptografie en veel tijd vereist. In plaats daarvan hebben we gebruik gemaakt van het product van onze partners Jolocom en hun mobiele wallet en diensten in ons platform geïntegreerd. Helaas heeft dit product één aanzienlijk nadeel: de hoofdprogrammeertaal is Node.js.
Deze technologische stack beperkt ons enorm in de keuze van hardware die in de scooter kan worden ingebouwd. Gelukkig hebben we in het begin van het project gekozen voor de Raspberry Pi Zero, en hebben we geprofiteerd van alle voordelen van een volwaardige microcomputer. Dit stelde ons in staat om omvangrijke Node.js op de scooter te draaien. Daarnaast kregen we monitoring en remote toegang via vpn, gebruikmakend van kant-en-klare tools.
Ter conclusie
Ondanks alle “pijn” en problemen is het project gelanceerd. Niet alles werkte zoals we hadden gepland, maar het was inderdaad mogelijk om op de scooters te rijden door ze te huren.
Ja, we hebben een aantal fouten gemaakt bij het ontwerpen van de architectuur, die ons niet toestonden om de dienst volledig gedecentraliseerd te maken, maar zelfs zonder deze fouten zouden we waarschijnlijk niet in staat zijn geweest om een serverless platform te creëren. Het is één ding om weer een crypto-piramide te schrijven en iets heel anders om een volwaardige dienst te hebben, waarin fouten moeten worden afgehandeld, randgevallen moeten worden opgelost en uitgestelde taken moeten worden uitgevoerd. Laten we hopen dat de onlangs verschenen nieuwe platforms flexibeler en functioneler zullen zijn.
Bron: habr.com
