Get best of the week

Entwicklung einer Software für den dezentralen Rollerverleih. Wer hat gesagt, dass es einfach sein würde?

In diesem Artikel werde ich darüber sprechen, wie wir versucht haben, eine dezentrale Rollervermietung auf intelligenten Verträgen aufzubauen, und warum wir immer noch einen zentralen Service brauchten.



Wie alles begann


Im November 2018 nahmen wir an einem Hackathon teil, der dem Internet der Dinge und der Blockchain gewidmet war. Unser Team entschied sich für das Teilen von Rollern als Idee, da wir einen Roller vom Sponsor dieses Hackathons hatten. Der Prototyp sah aus wie eine mobile Anwendung, mit der Sie einen Roller über NFC fahren können. Aus Marketingsicht wurde die Idee durch eine Geschichte über eine „glänzende Zukunft“ mit einem offenen Ökosystem untermauert, in dem jeder Mieter oder Vermieter werden kann, alles basierend auf intelligenten Verträgen.

Unseren Stakeholdern hat diese Idee sehr gut gefallen und sie haben beschlossen, daraus einen Prototyp für Demonstrationen auf Ausstellungen zu machen. Nach mehreren erfolgreichen Shows auf dem Mobile World Congress und Bosch Connected World im Jahr 2019 wurde beschlossen, den Rollerverleih an realen Nutzern, Mitarbeitern der Deutschen Telekom, zu testen. Also haben wir begonnen, ein vollwertiges MVP zu entwickeln.

Krücken-Blockchain


Ich denke, es lohnt sich nicht zu erklären, was der Unterschied zwischen einem Projekt für die Bühne und dem Projekt ist, das echte Menschen verwenden werden. Sechs Monate lang mussten wir den rohen Prototyp in etwas für den Piloten geeignetes verwandeln. Und dann wurde uns klar, was „Schmerz“ bedeutet.

Um unser System dezentral und offen zu gestalten, haben wir uns für intelligente Verträge von Ethereum entschieden. Die Wahl fiel auf diese Plattform für dezentrale Onlinedienste aufgrund ihrer Beliebtheit und der Fähigkeit, eine serverlose Anwendung zu erstellen. Wir planten, unser Projekt wie folgt umzusetzen.



Leider ist ein intelligenter Vertrag ein Code, der zum Zeitpunkt einer Transaktion von einer virtuellen Maschine ausgeführt wird und einen vollwertigen Server nicht ersetzen kann. Ein intelligenter Vertrag kann beispielsweise keine ausstehenden oder geplanten Aktivitäten ausführen. In unserem Projekt konnten wir den Minutenmietservice nicht implementieren, wie dies bei den meisten modernen Carsharing-Systemen der Fall ist. Daher haben wir nach Abschluss des Vorgangs die Kryptowährung vom Benutzer abgezogen, ohne die Gewissheit zu haben, dass er über genügend Geld verfügt. Dieser Ansatz ist nur für den internen Piloten akzeptabel und trägt natürlich zu den Problemen bei der Planung eines vollwertigen Produktionsprojekts bei.

Zu all dem oben Genannten wird die Feuchtigkeit der Plattform selbst hinzugefügt. Das Schreiben eines intelligenten Vertrags mit einer anderen Logik als ERC-20-Token führt beispielsweise zu einem Problem bei der Fehlerbehandlung. Normalerweise erhalten wir bei einer falschen Eingabe oder einer falschen Bedienung unserer Methoden einen Fehlercode als Antwort. Im Fall von Ethereum können wir nur die Menge an Gas erhalten, die zur Ausführung dieser Funktion aufgewendet wurde. Gas ist die Währung, die Sie für Transaktionen und Berechnungen bezahlen müssen: Je mehr Transaktionen in Ihrem Code enthalten sind, desto mehr zahlen Sie. Um zu verstehen, warum der Code nicht funktioniert, testen Sie ihn zunächst, simulieren alle möglichen Fehler und codieren das verbrauchte Gas als Fehlercode. Wenn Sie jedoch Ihren Code ändern, wird diese Fehlerbehandlung unterbrochen.

Darüber hinaus ist es fast unmöglich, eine mobile Anwendung zu erstellen, die ehrlich mit der Blockchain funktioniert, ohne einen Schlüssel zu verwenden, der irgendwo in der Cloud gespeichert ist. Obwohl es ehrliche Geldbörsen gibt, bieten sie keine Schnittstellen zum Signieren externer Transaktionen. Dies bedeutet, dass Sie die native Anwendung nicht sehen können, wenn keine Krypto-Brieftasche integriert ist, der Benutzer wenig vertrauen (ich würde nicht vertrauen). Infolgedessen mussten wir hier auch eine Ecke schneiden. Intelligente Verträge wurden an das private Netzwerk von Ethereum geliefert, und die Brieftasche war trübe. Trotzdem verspürten unsere Benutzer den „Charme“ dezentraler Dienste in Form eines langen Wartens auf Transaktionen mehrmals pro Mietsitzung.

All dies führt uns zu dieser Architektur. Wir sind uns einig, dass sie sich stark von dem unterscheidet, was wir geplant haben.



Ass im Ärmel: Selbstsouveräne Identität


Sie können kein vollständig dezentrales System ohne dezentrale Identifikation aufbauen. Self-Sovereign Identity (SSI) ist für diesen Teil verantwortlich. Das Wesentliche ist, dass Sie einen zentralen Identitätsanbieter (IDP) ausschalten und alle Daten und die Verantwortung für diese an die Personen verteilen. Jetzt entscheidet der Benutzer, welche Daten er benötigt und mit wem er sie teilen wird. Alle diese Informationen befinden sich auf dem Gerät des Benutzers. Für die gemeinsame Nutzung benötigen wir jedoch ein dezentrales kryptografisches Beweissicherungssystem. Alle modernen Implementierungen des SSI-Konzepts verwenden Blockchain als Speicher.

"Was hat das Ass im Ärmel?" - du fragst. Wir haben den Dienst für einen internen Test unserer eigenen Mitarbeiter in Berlin und Bonn gestartet und waren angesichts der deutschen Gewerkschaften mit Schwierigkeiten konfrontiert. In Deutschland ist es Unternehmen untersagt, Arbeitnehmerbewegungen zu überwachen, und die Gewerkschaften kontrollieren dies. Diese Einschränkungen machen der zentralen Speicherung von Benutzeridentitätsdaten ein Ende, da wir in diesem Fall den Standort der Mitarbeiter gekannt hätten. Gleichzeitig konnten wir sie wegen der Möglichkeit, Motorroller zu entführen, nicht überprüfen. Dank Self-Sovereign Identity nutzten unsere Benutzer das System jedoch anonym, und der Roller selbst überprüfte die Verfügbarkeit eines Führerscheins, bevor er mit der Anmietung begann. Infolgedessen haben wir anonymisierte Benutzerkennzahlen beibehalten, wir hatten keine Dokumente oder persönlichen Daten: Alle wurden auf den Geräten der Fahrer selbst gespeichert.Dank SSI war die Lösung des Problems in unserem Projekt bereits vor dem Erscheinen fertig.

Das Gerät warf Probleme


Wir haben Self-Sovereign Identity nicht selbst implementiert, da dies Fachwissen in Kryptographie und viel Zeit erfordert. Stattdessen haben wir das Produkt unserer Partner Jolocom genutzt und deren mobile Geldbörse und Services in unsere Plattform integriert. Leider hat dieses Produkt einen wesentlichen Nachteil: Die Hauptentwicklungssprache ist Node.js.

Ein solcher technologischer Stapel schränkt uns bei der Auswahl des in einen Roller eingebauten Eisens sehr ein. Glücklicherweise fiel unsere Wahl zu Beginn des Projekts auf den Raspberry Pi Zero, und wir nutzten den vollwertigen Mikrocomputer. Dadurch konnten wir die sperrigen Node.js auf einem Roller ausführen. Darüber hinaus erhielten wir Überwachung und Fernzugriff über VPN mit vorgefertigten Tools.

Abschließend


Trotz aller „Schmerzen“ und Probleme wurde das Projekt gestartet. Nicht alles funktionierte wie geplant, aber es war wirklich möglich, Roller zu fahren, indem man sie mietete.

Ja, wir haben eine Reihe von Fehlern bei der Gestaltung der Architektur gemacht, die es uns nicht ermöglichten, den Service vollständig dezentral zu gestalten, aber selbst ohne diese Fehler hätten wir es kaum geschafft, eine serverlose Plattform zu erstellen. Es ist eine Sache, eine andere Kryptopyramide zu schreiben, und eine andere ist ein vollwertiger Dienst, bei dem Sie Fehler behandeln, Grenzfälle lösen und ausstehende Aufgaben ausführen müssen. Hoffen wir, dass kürzlich erschienene neue Plattformen flexibler und funktionaler sind.

More articles:


All Articles