In dit artikel zal ik vertellen hoe we probeerden gedecentraliseerde scooterverhuur op basis van slimme contracten te bouwen en waarom we nog steeds een gecentraliseerde service nodig hadden.
Hoe het allemaal begon
In november 2018 namen we deel aan een hackathon gewijd aan het Internet of Things en blockchain. Ons team koos voor het delen van scooters als idee omdat we een scooter hadden van de sponsor van deze hackathon. Het prototype leek op een mobiele applicatie waarmee je via NFC een scooter kunt starten. Vanuit marketingoogpunt werd het idee ondersteund door een verhaal over een ‘mooie toekomst’ met een open ecosysteem waar iedereen huurder of verhuurder kan worden, allemaal op basis van slimme contracten.
Onze belanghebbenden waren erg enthousiast over dit idee en besloten er een prototype van te maken voor tentoonstellingen. Na verschillende succesvolle demonstraties op Mobile World Congress en Bosch Connected World in 2019 werd besloten om de scooterverhuur te testen met echte gebruikers, medewerkers van Deutsche Telekom. Daarom zijn we begonnen met het ontwikkelen van een volwaardige MVP.
Blockchain op krukken
Ik denk niet dat het de moeite waard is om uit te leggen wat het verschil is tussen een project dat op het podium wordt getoond en een project dat door echte mensen zal worden gebruikt. In zes maanden tijd moesten we het ruwe prototype ombouwen tot iets dat geschikt was voor een pilot. En toen begrepen we wat ‘pijn’ betekent.
Om ons systeem gedecentraliseerd en open te maken, hebben we besloten om slimme contracten van Ethereum te gebruiken. De keuze viel op dit platform van gedecentraliseerde online diensten vanwege de populariteit en de mogelijkheid om een serverloze applicatie te bouwen. We waren van plan ons project als volgt uit te voeren.
Maar helaas is een slim contract een code die door een virtuele machine wordt uitgevoerd op het moment van een transactie, en het kan een volwaardige server niet vervangen. Een slim contract kan bijvoorbeeld geen lopende of geplande acties uitvoeren. In ons project konden we hierdoor geen verhuurservice per minuut implementeren, zoals de meeste moderne autodeeldiensten doen. Daarom hebben we cryptocurrency van de gebruiker afgeschreven nadat de transactie was voltooid, zonder er zeker van te zijn dat hij genoeg geld had. Deze aanpak is alleen acceptabel voor een interne pilot en levert uiteraard problemen op bij het ontwerpen van een volwaardig productieproject.
Toegevoegd aan al het bovenstaande is de vochtigheid van het platform zelf. Als u bijvoorbeeld een slim contract schrijft met een andere logica dan ERC-20-tokens, zult u problemen met de foutafhandeling tegenkomen. Als de invoer onjuist is of onze methoden niet correct werken, ontvangen we meestal een foutcode als reactie. In het geval van Ethereum kunnen we niets anders krijgen dan de hoeveelheid gas die wordt uitgegeven om deze functie uit te voeren. Gas is een valuta waarvoor betaald moet worden voor transacties en berekeningen: hoe meer bewerkingen in uw code, hoe meer u betaalt. Om te begrijpen waarom de code niet werkt, test je deze eerst door alle mogelijke fouten te simuleren en het verbruikte gas hard te coderen als een foutcode. Maar als u uw code wijzigt, vervalt deze foutafhandeling.
Daarnaast is het bijna onmogelijk om een mobiele applicatie te maken die eerlijk met de blockchain werkt, zonder gebruik te maken van een sleutel die ergens in de cloud is opgeslagen. Hoewel er eerlijke portemonnees bestaan, bieden deze geen interfaces voor het ondertekenen van externe transacties. Dit betekent dat je geen native applicatie zult zien tenzij deze een ingebouwde crypto-portemonnee heeft, waar gebruikers weinig vertrouwen in zullen hebben (ik zou het niet vertrouwen). Hierdoor moesten we ook hier een hoekje afsnijden. Slimme contracten werden geleverd aan het particuliere Ethereum-netwerk en de portemonnee was cloudgebaseerd. Maar desondanks ervoeren onze gebruikers alle “geneugten” van gedecentraliseerde diensten in de vorm van meerdere keren lang wachten op transacties per huursessie.
Dit alles leidt ons naar deze architectuur. Mee eens, het is heel anders dan we hadden gepland.
Aas in het gat: zelf-soevereine identiteit
Je kunt geen volledig gedecentraliseerd systeem bouwen zonder een gedecentraliseerde identiteit. Self-Sovereign Identity (SSI) is verantwoordelijk voor dit deel, waarvan de essentie is dat je de gecentraliseerde identiteitsprovider (IDP) weggooit en alle gegevens en verantwoordelijkheid daarvoor onder de mensen verdeelt. Nu bepaalt de gebruiker welke gegevens hij nodig heeft en met wie hij deze deelt. Al deze informatie bevindt zich op het apparaat van de gebruiker. Maar voor de uitwisseling hebben we een gedecentraliseerd systeem nodig voor het opslaan van cryptografisch bewijsmateriaal. Alle moderne implementaties van het SSI-concept gebruiken blockchain als opslag.
“Wat heeft dit te maken met de aas in de hole?” - je vraagt. We lanceerden de dienst voor interne tests bij onze eigen werknemers in Berlijn en Bonn, en we ondervonden problemen in de vorm van Duitse vakbonden. In Duitsland is het bedrijven verboden de bewegingen van werknemers te controleren, en vakbonden controleren dit. Deze beperkingen maken een einde aan de gecentraliseerde opslag van gebruikersidentiteitsgegevens, omdat we in dit geval de locatie van werknemers zouden kennen. Tegelijkertijd konden we het niet laten om ze te controleren vanwege de mogelijkheid dat scooters werden gestolen. Maar dankzij Self-Sovereign Identity gebruikten onze gebruikers het systeem anoniem en controleerde de scooter zelf zijn rijbewijs voordat hij met de huur begon. Als gevolg hiervan hebben we anonieme gebruikersstatistieken opgeslagen; we hadden geen documenten of persoonlijke gegevens: ze stonden allemaal op de apparaten van de chauffeurs zelf. Dankzij SSI was de oplossing voor het probleem in ons project dus al klaar voordat deze verscheen.
Het apparaat gaf mij problemen
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 portemonnee en diensten in ons platform geïntegreerd. Helaas heeft dit product één belangrijk nadeel: de belangrijkste ontwikkeltaal is Node.js.
Deze technologiestapel beperkt enorm onze keuze aan hardware die in een scooter is ingebouwd. Gelukkig hebben we helemaal aan het begin van het project gekozen voor de Raspberry Pi Zero en hebben we geprofiteerd van alle voordelen van een volwaardige microcomputer. Hierdoor konden we omvangrijke Node.js op de scooter draaien. Daarnaast kregen we monitoring en toegang op afstand via VPN met kant-en-klare tools.
Concluderend
Ondanks alle “pijn” en problemen werd het project gelanceerd. Niet alles werkte zoals we hadden gepland, maar het was echt mogelijk om scooters te besturen door ze te huren.
Ja, we hebben een aantal fouten gemaakt bij het ontwerpen van de architectuur waardoor we de dienst niet volledig gedecentraliseerd konden maken, maar zelfs zonder deze fouten hadden we nauwelijks een serverloos platform kunnen creëren. Het is één ding om nog een cryptopiramide te schrijven, en iets heel anders om een volwaardige service te schrijven waarin je fouten moet afhandelen, grensgevallen moet oplossen en lopende taken moet uitvoeren. Laten we hopen dat de nieuwe platforms die onlangs zijn ontstaan flexibeler en functioneler zullen zijn.
Bron: www.habr.com