In diesem Artikel werde ich darüber berichten, wie wir versucht haben, einen dezentralen Scooter-Verleih basierend auf Smart Contracts aufzubauen und warum wir dennoch einen zentralisierten Dienst benötigten.
Wie alles begann
Im November 2018 nahmen wir an einem Hackathon teil, der sich mit dem Internet der Dinge und Blockchain beschäftigte. Als Idee wählte unser Team das Scooter-Sharing, da wir einen Scooter vom Sponsor dieses Hackathons hatten. Der Prototyp sah wie eine mobile Anwendung aus, die es ermöglichte, den Scooter über NFC zu starten. Aus Marketingsicht wurde die Idee durch das Versprechen einer "hellen Zukunft" mit einem offenen Ökosystem untermauert, in dem jeder Mieter oder Vermieter werden kann, und das alles auf Basis von Smart Contracts.
Diese Idee gefiel unseren Stakeholdern sehr, und sie beschlossen, sie in einen Prototyp für die Präsentation auf Messen umzuwandeln. Nach mehreren erfolgreichen Präsentationen auf dem Mobile World Congress und Bosch Connected World im Jahr 2019 wurde beschlossen, den Scooter-Verleih mit realen Nutzern, Mitarbeitern der Deutschen Telekom, zu testen. So begannen wir mit der Entwicklung eines vollständigen MVP.
Blockchain auf Krücken
Ich denke, es ist nicht notwendig zu erklären, was der Unterschied zwischen einem Projekt zur Vorführung auf der Bühne und einem ist, das von realen Menschen genutzt wird. In sechs Monaten sollten wir den rohen Prototyp in etwas taugliches für den Pilotbetrieb verwandeln. Und hier wurde uns klar, was "Schmerz" bedeutet.
Um unser System dezentral und offen zu gestalten, entschieden wir uns, Smart Contracts von Ethereum zu verwenden. Die Wahl fiel auf diese Plattform für dezentrale Online-Dienste aufgrund ihrer Popularität und der Möglichkeit, eine serverlose Anwendung zu erstellen. Wir planten, unser Projekt folgendermaßen umzusetzen.
Leider ist ein Smart Contract jedoch Code, der von einer virtuellen Maschine zum Zeitpunkt der Transaktion ausgeführt wird, und er kann nicht einen vollwertigen ersetzen. Server. Zum Beispiel kann ein Smart Contract keine verzögerten oder geplanten Aktionen durchführen. In unserem Projekt hat dies verhindert, dass wir einen minutengenauen Mietservice implementieren, wie es die meisten modernen Carsharing-Dienste tun. Daher haben wir die Kryptowährung von den Nutzern nach Abschluss der Operation abgebucht, ohne sicherzustellen, dass sie genügend Geld haben. Dieser Ansatz ist nur für interne Pilotprojekte akzeptabel und bringt ohne Zweifel Probleme bei der Planung eines vollwertigen Produktionsprojekts mit sich.
Darüber hinaus kommt die Unzulänglichkeit der Plattform hinzu. Zum Beispiel, wenn Sie einen Smart Contract mit einer Logik schreiben, die sich von ERC-20-Token unterscheidet, werden Sie auf ein Problem bei der Fehlerbehandlung stoßen. Normalerweise erhalten wir bei falscher Eingabe oder wenn unsere Methoden nicht korrekt funktionieren, einen Fehlercode als Antwort. Im Fall von Ethereum können wir nichts anderes erhalten als die Menge an Gas, die für die Ausführung dieser Funktion aufgewendet wurde. Gas ist die Währung, die für Transaktionen und Berechnungen bezahlt werden muss: Je mehr Operationen in Ihrem Code sind, desto mehr zahlen Sie. Daher testen Sie zuerst Ihren Code, indem Sie alle möglichen Fehler simulieren und das verbrauchte Gas als Fehlercode fest codieren, um zu verstehen, warum der Code nicht funktioniert. Aber wenn Sie Ihren Code ändern, bricht diese Fehlerbehandlung.
Zusätzlich ist es praktisch unmöglich, eine mobile Anwendung zu erstellen, die ehrlich mit der Blockchain arbeitet, ohne einen Schlüssel zu verwenden, der irgendwo in der Cloud gespeichert ist. Obwohl ehrliche Wallets existieren, bieten sie keine Schnittstellen für die Unterzeichnung externer Transaktionen an. Das bedeutet, dass Sie keine native Anwendung haben werden, es sei denn, sie enthält eine integrierte Krypto-Wallet, der die Nutzer wenig Vertrauen entgegenbringen werden (ich würde ihr nicht vertrauen). Infolgedessen mussten wir auch hier Abstriche machen. Smart Contracts wurden in ein privates Ethereum-Netzwerk geliefert, während das Wallet cloud-basiert war. Trotz alledem haben unsere Nutzer die „Vorzüge“ dezentraler Dienste in Form von langen Wartezeiten für Transaktionen mehrfach während einer Mietsession gespürt.
All dies führt uns zu dieser Architektur. Sie müssen zugeben, dass sie sich stark von dem unterscheidet, was wir geplant hatten.
Das Ass im Ärmel: Self-Sovereign Identity
Es ist nicht möglich, ein vollständig dezentralisiertes System ohne dezentrale Identifizierung zu schaffen. Dafür ist die Selbstverwaltete Identität (SSI) verantwortlich, deren Kern darin besteht, einen zentralisierten Identitätsanbieter (IDP) abzulehnen und alle Daten und deren Verantwortung an die Nutzer zu übergeben. Jetzt entscheidet der Nutzer selbst, welche Daten er benötigt und mit wem er sie teilen möchte. Sämtliche Informationen befinden sich auf dem Gerät des Nutzers. Für den Austausch benötigen wir jedoch ein dezentrales System zur Speicherung kryptografischer Beweise. Alle aktuellen Implementierungen des SSI-Konzepts nutzen Blockchain als Speichermedium.
„Was hat das mit einem Trumpf im Ärmel zu tun?“ – werden Sie fragen. Den Dienst haben wir für einen internen Test mit unseren eigenen Mitarbeitern in Berlin und Bonn gestartet, und dabei hatten wir Schwierigkeiten mit den deutschen Gewerkschaften. In Deutschland ist es Unternehmen verboten, die Bewegungen ihrer Mitarbeiter zu überwachen, und die Gewerkschaften kontrollieren das. Diese Einschränkungen machen eine zentrale Speicherung von Nutzerdaten nahezu unmöglich, da wir in diesem Fall wüssten, wo sich die Mitarbeiter befinden. Gleichzeitig konnten wir sie aufgrund der Möglichkeit von Mopeddiebstählen nicht unbeaufsichtigt lassen. Doch dank der Selbstverwalteten Identität konnten unsere Nutzer das System anonym nutzen, wobei der Moped selbst vor Beginn der Anmietung die Führungsscheine der Nutzer überprüfte. Infolgedessen hatten wir anonymisierte Nutzermetriken gespeichert, ohne irgendwelche Dokumente oder persönlichen Daten: All diese Daten befanden sich auf den Geräten der Fahrer selbst. Somit war die Lösung des Problems in unserem Projekt dank SSI bereits vor ihrem Erscheinen bereit.
Das Gerät brachte Probleme mit sich.
Wir haben die Selbstverwaltete Identität nicht selbst umgesetzt, da dies Expertise in der Kryptographie und eine Menge Zeit erfordert. Stattdessen haben wir das Produkt unserer Partner Jolocom genutzt und deren mobile Wallet- und Dienstleistungsangebote in unsere Plattform integriert. Leider hat dieses Produkt einen wesentlichen Nachteil: Die Hauptprogrammiersprache ist Node.js.
Dieser Technologie-Stack schränkt uns stark in der Auswahl der Hardware ein, die in den Scooter eingebaut werden kann. Glücklicherweise fiel unsere Wahl zu Beginn des Projekts auf den Raspberry Pi Zero, und wir haben alle Vorteile eines vollwertigen Mikrokameras genutzt. Dies ermöglichte es uns, das umfangreiche Node.js auf dem Scooter zu starten. Darüber hinaus erhielten wir Monitoring und Remote-Zugriff über vpn, indem wir vorhandene Tools nutzten.
Abschließend
Trotz all der "Schwierigkeiten" und Probleme wurde das Projekt gestartet. Nicht alles funktionierte, wie wir es geplant hatten, aber es war tatsächlich möglich, mit den Scootern zu fahren und sie zu mieten.
Ja, wir haben bei der Architekturplanung eine Reihe von Fehlern gemacht, die uns daran hinderten, den Service vollständig dezentral zu gestalten, aber selbst ohne diese Fehler wäre es uns kaum gelungen, eine serverlose Plattform zu schaffen. Es ist eine Sache, eine weitere Krypto-Pyramide zu schreiben, und etwas ganz anderes, einen vollwertigen Service zu entwickeln, in dem Fehler behandelt, Grenzfälle gelöst und verzögerte Aufgaben ausgeführt werden müssen. Hoffen wir, dass die in letzter Zeit aufgetauchten neuen Plattformen flexibler und funktionaler sein werden.
Quelle: habr.com
