In diesem Artikel werde ich darüber berichten, wie wir versucht haben, einen dezentralen Elektroroller-Verleih auf Basis von Smart Contracts aufzubauen und warum wir dennoch einen zentralisierten Service benötigten.
Wie alles begann
Im November 2018 nahmen wir an einem Hackathon zum Thema Internet der Dinge und Blockchain teil. Unsere Team-Idee war das Roller-Sharing, da wir einen Roller vom Sponsor dieses Hackathons zur Verfügung hatten. Der Prototyp sah wie eine mobile App aus, mit der man den Roller über NFC starten konnte. Marketingtechnisch wurde die Idee durch die Erzählung einer "glänzenden Zukunft" mit einem offenen Ökosystem, in dem jeder Mieter oder Vermieter werden kann, untermauert, alles basierend auf Smart Contracts.
Diese Idee gefiel unseren Stakeholdern sehr, und sie beschlossen, sie in einen Prototypen für eine Präsentation auf Messen umzuwandeln. Nach mehreren erfolgreichen Vorführungen beim Mobile World Congress und Bosch Connected World im Jahr 2019 wurde beschlossen, den Roller-Verleih mit echten Nutzern, Mitarbeitern von Deutsche Telekom, zu testen. So begannen wir mit der Entwicklung eines vollwertigen MVP.
Blockchain auf Krücken
Ich denke, es ist nicht nötig zu erklären, was der Unterschied zwischen einem Projekt für eine Bühnenpräsentation und einem Projekt ist, das von echten Benutzern verwendet wird. Wir hatten sechs Monate Zeit, um einen Rohprototyp in etwas zu verwandeln, das für einen Pilotversuch geeignet ist. Und hier verstanden wir, was "Schmerz" bedeutet.
Um unser System dezentral und offen zu gestalten, haben wir uns entschieden, Ethereum-Smart Contracts zu verwenden. Wir wählten diese Plattform für dezentrale Online-Dienste wegen ihrer Popularität und der Möglichkeit, eine serverlose Anwendung zu entwickeln. Wir planten, unser Projekt folgendermaßen umzusetzen.
Aber leider ist ein Smart Contract – ein Code, der von der virtuellen Maschine zum Zeitpunkt der Transaktion ausgeführt wird, und er kann keinen vollständigen Ersatz bieten. der Server. Zum Beispiel kann ein Smart Contract keine verzögerten oder geplanten Aktionen ausführen. In unserem Projekt hat dies die Implementierung eines minutengenauen Mietservices verhindert, wie es die meisten modernen Carsharing-Dienste tun. Daher haben wir die Kryptowährung vom Nutzer nach Abschluss der Transaktion abgebucht, ohne sicherzustellen, dass er über ausreichende Mittel verfügt. Dieser Ansatz ist nur für interne Pilotprojekte akzeptabel und bringt definitiv Probleme bei der Planung eines vollwertigen Produktionsprojekts mit sich.
Zusätzlich zu all dem gibt es die Feuchtigkeit der Plattform selbst. Wenn Sie zum Beispiel einen Smart Contract mit einer Logik erstellen, die sich von der der ERC-20-Token unterscheidet, stoßen Sie auf Probleme bei der Fehlerverarbeitung. Normalerweise erhalten wir bei falscher Eingabe oder Problemen mit unseren Methoden einen Fehlercode. Im Fall von Ethereum können wir jedoch nichts anderes als die Menge an Gas abfragen, 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 enthalten sind, desto mehr bezahlen Sie. Daher müssen Sie, um herauszufinden, warum der Code nicht funktioniert, zunächst alle möglichen Fehler simulieren, um ihn zu testen, und den verbrauchten Gasverbrauch als Fehlercode hartcodieren. Wenn Sie jedoch Ihren Code ändern, wird diese Fehlerverarbeitung nicht mehr funktionieren.
Darüber hinaus ist es nahezu unmöglich, eine Mobile App zu entwickeln, die fair mit Blockchain arbeitet, ohne einen Schlüssel zu verwenden, der irgendwo in der Cloud gespeichert ist. Obwohl es ehrliche Wallets gibt, bieten sie keine Schnittstellen zum Signieren externer Transaktionen an. Das bedeutet, dass Sie eine native App ohne eine integrierte Krypto-Wallet kaum erwarten können, der Nutzer wird diesem jedoch kaum vertrauen (ich würde es nicht). Daher mussten wir auch hier einen Kompromiss eingehen. Smart Contracts wurden in ein privates Ethereum-Netzwerk geliefert, und das Wallet war cloudbasiert. Trotz alledem haben unsere Nutzer die „Vorzüge“ dezentraler Dienste in Form von langen Wartezeiten für Transaktionen während jeder Mietsession gespürt.
All dies führt uns zu einer solchen Architektur. Sie müssen zugeben, dass sie sich stark von dem unterscheidet, was wir geplant hatten.
Trumpf im Ärmel: Selbstbestimmte Identität
Eine vollständig dezentralisierte Systemarchitektur ist ohne dezentrale Identifizierung nicht möglich. Diese Aufgabe übernimmt die Self-Sovereign Identity (SSI), deren Kernidee darin besteht, den zentralen Identitätsanbieter (IDP) zu eliminieren und den Menschen alle Daten und die Verantwortung dafür zu übergeben. Der Nutzer entscheidet nun selbst, welche Daten er benötigt und mit wem er diese teilen möchte. Alle diese Informationen befinden sich auf dem Gerät des Nutzers. Für den Austausch benötigen wir jedoch ein dezentrales System zur Speicherung kryptografischer Nachweise. Alle modernen Implementierungen des SSI-Konzepts nutzen Blockchain als Speicher.
„Was hat das mit einem Trumpf im Ärmel zu tun?“ — fragen Sie sich. Wir haben den Service für interne Tests mit unseren eigenen Mitarbeitern in Berlin und Bonn gestartet und standen vor Schwierigkeiten in Form deutscher Gewerkschaften. In Deutschland ist Unternehmen verboten, die Bewegungen ihrer Angestellten zu überwachen, und die Gewerkschaften kontrollieren das. Diese Einschränkungen machen eine zentralisierte Speicherung von Identitätsdaten unmöglich, da wir in diesem Fall Kenntnis über den Aufenthaltsort der Mitarbeiter hätten. Gleichzeitig konnten wir sie jedoch nicht unüberprüft lassen, aufgrund der Möglichkeit von Mopeddiebstählen. Doch dank der Selbstsouveränen Identität nutzten unsere Nutzer das System anonym, und das Moped prüfte vor Beginn der Vermietung automatisch ihre Führerscheine. Infolgedessen hatten wir anonymisierte Nutzermetriken gespeichert, wir besaßen keine Dokumente und persönlichen Daten: all diese verblieben auf den Geräten der Fahrer. Somit war dank SSI die Lösung des Problems in unserem Projekt bereits vor seinem Auftreten bereit.
Das Gerät hat Probleme aufgeworfen
Wir haben keine eigene Self-Sovereign Identity umgesetzt, da dies Fachwissen in der Kryptografie und viel Zeit erfordert. Stattdessen haben wir das Produkt unserer Partner Jolocom genutzt und ihre mobile Wallet sowie Dienstleistungen in unsere Plattform integriert. Leider hat dieses Produkt einen wesentlichen Nachteil: Die Hauptprogrammiersprache ist Node.js.
Dieser Technologiestack schränkt uns stark in der Auswahl der Hardware ein, die wir im Scooter verbauen können. Glücklicherweise fiel unsere Wahl zu Beginn des Projekts auf den Raspberry Pi Zero, und wir konnten alle Vorteile eines vollwertigen Mikrocomputers nutzen. Das ermöglichte uns den Einsatz von umfangreichem Node.js im Scooter. Darüber hinaus haben wir Überwachung und Fernzugriff über VPN, indem wir auf fertige Werkzeuge zurückgegriffen haben.
Zusammenfassung
Trotz aller "Schwierigkeiten" und Herausforderungen wurde das Projekt gestartet. Zwar funktionierte nicht alles wie geplant, aber die Scooter konnten tatsächlich gemietet und gefahren werden.
Ja, wir haben bei der Architekturplanung eine Reihe von Fehlern gemacht, die uns daran gehindert haben, den Service vollständig dezentralisiert zu gestalten. Aber selbst ohne diese Fehler wäre es uns wahrscheinlich nicht gelungen, eine serverless Plattform zu kreieren. Es ist eine Sache, eine weitere Krypto-Pyramide zu schreiben, und ganz etwas anderes, einen vollwertigen Service zu schaffen, bei dem Fehler bearbeitet, 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
