In diesem Artikel werde ich darüber sprechen, wie wir versucht haben, eine dezentrale Rollervermietung auf Basis von Smart Contracts aufzubauen und warum wir dennoch einen zentralisierten Service brauchten.
Wie alles begann
Im November 2018 nahmen wir an einem Hackathon zum Thema Internet der Dinge und Blockchain teil. Unser Team hat sich für die Idee „Scooter-Sharing“ entschieden, da wir einen Roller vom Sponsor dieses Hackathons hatten. Der Prototyp sah aus wie eine mobile Anwendung, die es ermöglicht, einen Roller über NFC zu starten. Aus Marketingsicht wurde die Idee durch eine Geschichte über eine „glänzende Zukunft“ mit einem offenen Ökosystem unterstützt, in dem jeder Mieter oder Vermieter werden kann, alles auf der Grundlage intelligenter Verträge.
Unseren Stakeholdern gefiel diese Idee sehr und sie beschlossen, daraus einen Prototyp für die Ausstellung auf Ausstellungen zu machen. Nach mehreren erfolgreichen Vorführungen auf dem Mobile World Congress und der Bosch Connected World im Jahr 2019 wurde beschlossen, den Rollerverleih mit echten Nutzern, Mitarbeitern der Deutschen Telekom, zu testen. Also begannen wir mit der Entwicklung eines vollwertigen MVP.
Blockchain auf Krücken
Ich glaube nicht, dass es sich lohnt zu erklären, was der Unterschied zwischen einem Projekt ist, das auf der Bühne gezeigt wird, und einem Projekt, das von echten Menschen genutzt wird. Innerhalb von sechs Monaten mussten wir aus dem groben Prototyp etwas Pilottaugliches machen. Und dann haben wir verstanden, was „Schmerz“ bedeutet.
Um unser System dezentral und offen zu gestalten, haben wir uns für den Einsatz von Ethereum Smart Contracts entschieden. Die Wahl fiel auf diese Plattform dezentraler Online-Dienste aufgrund ihrer Beliebtheit und der Möglichkeit, eine serverlose Anwendung zu erstellen. Wir hatten vor, unser Projekt wie folgt umzusetzen.
Leider handelt es sich bei einem Smart Contract um einen Code, der zum Zeitpunkt einer Transaktion von einer virtuellen Maschine ausgeführt wird, und kann einen vollwertigen Server nicht ersetzen. Beispielsweise kann ein Smart Contract keine ausstehenden oder geplanten Aktionen ausführen. Dies ermöglichte es uns in unserem Projekt nicht, einen Mietservice pro Minute zu implementieren, wie dies bei den meisten modernen Carsharing-Diensten der Fall ist. Daher haben wir dem Benutzer nach Abschluss der Transaktion die Kryptowährung abgebucht, ohne sicher zu sein, dass er über genügend Geld verfügte. Dieser Ansatz ist nur für ein internes Pilotprojekt akzeptabel und bringt natürlich Probleme mit sich, wenn ein vollwertiges Produktionsprojekt entworfen wird.
Hinzu kommt die Feuchtigkeit der Plattform selbst. Wenn Sie beispielsweise einen Smart Contract mit einer anderen Logik als ERC-20-Tokens schreiben, treten Probleme bei der Fehlerbehandlung auf. Wenn die Eingabe falsch ist oder unsere Methoden nicht korrekt funktionieren, erhalten wir normalerweise als Antwort einen Fehlercode. Im Fall von Ethereum können wir nichts anderes als die Menge an Gas erhalten, die für die Ausführung dieser Funktion aufgewendet wird. Gas ist eine Währung, die für Transaktionen und Berechnungen bezahlt werden muss: Je mehr Operationen in Ihrem Code, desto mehr zahlen Sie. Um zu verstehen, warum der Code nicht funktioniert, testen Sie ihn zunächst, indem Sie alle möglichen Fehler simulieren und das ausgegebene Gas als Fehlercode fest codieren. 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 irgendwo in der Cloud gespeicherten Schlüssel zu verwenden. Obwohl es ehrliche Wallets gibt, bieten sie keine Schnittstellen zum Signieren externer Transaktionen. Das bedeutet, dass Sie keine native Anwendung sehen, es sei denn, sie verfügt über eine integrierte Krypto-Wallet, der die Benutzer wenig Vertrauen entgegenbringen (ich würde ihr nicht vertrauen). Dadurch mussten wir auch hier Abstriche machen. Intelligente Verträge wurden an das private Ethereum-Netzwerk geliefert und das Wallet war cloudbasiert. Trotzdem erlebten unsere Nutzer alle „Vorzüge“ dezentraler Dienste in Form langer Wartezeiten auf Transaktionen mehrmals pro Mietsitzung.
All dies führt uns zu dieser Architektur. Stimmen Sie zu, es unterscheidet sich stark von dem, was wir geplant haben.
Ass im Ärmel: Selbstsouveräne Identität
Ohne dezentrale Identität kann man kein vollständig dezentrales System aufbauen. Für diesen Teil ist Self-Sovereign Identity (SSI) verantwortlich, dessen Kern darin besteht, dass Sie den zentralen Identitätsanbieter (IDP) verwerfen und alle Daten und die Verantwortung dafür an die Menschen verteilen. Nun entscheidet der Nutzer, welche Daten er benötigt und mit wem er diese teilt. Alle diese Informationen befinden sich auf dem Gerät des Benutzers. Für den Austausch benötigen wir jedoch ein dezentrales System zur Speicherung kryptografischer Beweise. Alle modernen Implementierungen des SSI-Konzepts nutzen Blockchain als Speicher.
„Was hat das mit dem Ass im Ärmel zu tun?“ - du fragst. Wir haben den Dienst für interne Tests bei unseren eigenen Mitarbeitern in Berlin und Bonn eingeführt und stießen dabei auf Schwierigkeiten seitens der deutschen Gewerkschaften. In Deutschland ist es Unternehmen verboten, die Bewegungen der Arbeitnehmer 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 kennen würden. Gleichzeitig konnten wir nicht anders, als sie zu überprüfen, da die Möglichkeit bestand, dass Motorroller gestohlen wurden. Aber dank Self-Sovereign Identity nutzten unsere Nutzer das System anonym und der Roller selbst überprüfte vor Beginn der Miete seinen Führerschein. Infolgedessen haben wir anonyme Benutzermetriken gespeichert; wir hatten keine Dokumente oder persönlichen Daten: Sie waren alle auf den Geräten der Fahrer selbst enthalten. Somit war die Lösung des Problems in unserem Projekt dank SSI bereits fertig, bevor sie erschien.
Das Gerät bereitete mir Probleme
Wir haben Self-Sovereign Identity nicht selbst implementiert, da dies Fachwissen in der Kryptographie und viel Zeit erfordert. Stattdessen haben wir das Produkt unseres Partners Jolocom genutzt und dessen mobile Geldbörse und Dienste in unsere Plattform integriert. Leider hat dieses Produkt einen wesentlichen Nachteil: Die Hauptentwicklungssprache ist Node.js.
Dieser Technologie-Stack schränkt unsere Auswahl an in einen Roller eingebauter Hardware erheblich ein. Glücklicherweise haben wir uns gleich zu Beginn des Projekts für den Raspberry Pi Zero entschieden und alle Vorteile eines vollwertigen Mikrocomputers genutzt. Dadurch konnten wir umfangreiche Node.js auf dem Scooter ausführen. Darüber hinaus erhielten wir eine Überwachung und einen Fernzugriff über VPN mit vorgefertigten Tools.
Abschließend
Trotz aller „Schmerzen“ und Probleme wurde das Projekt gestartet. Es hat nicht alles so geklappt, wie wir es geplant hatten, aber es war wirklich möglich, Roller zu fahren, indem man sie mietete.
Ja, wir haben beim Entwurf der Architektur eine Reihe von Fehlern gemacht, die es uns nicht ermöglichten, den Dienst vollständig dezentral zu gestalten, aber auch ohne diese Fehler hätten wir kaum eine serverlose Plattform erstellen können. Es ist eine Sache, eine weitere Krypto-Pyramide zu schreiben, und eine ganz andere, einen vollwertigen Dienst zu schreiben, bei dem man Fehler behandeln, Grenzfälle lösen und anstehende Aufgaben erledigen muss. Hoffen wir, dass die neuen Plattformen, die kürzlich entstanden sind, flexibler und funktionaler sind.
Source: habr.com