• Projekt CoffeeChain: Laptop mit geth Ausgabe, RaspberryPi Node Rig und intelligente Nespresso Maschine
  • Projekt CoffeeChain: Verbindungsplatine im Mining Rig
  • Projekt CoffeeChain: der App-Prototyp
  • Projekt CoffeeChain: das Tablet mit der App in der Mining Rig Halterung
  • Projekt CoffeeChain: Kaffeemaschinen-Steuerung Marke "Eigenbau"
  • Projekt CoffeeChain: der RaspberryPi Blockchain Node Rig
  • Projekt CoffeeChain: Die Mitarbeiter Tobias und Marvin arbeiten an einer Lösung

Das Wort „Blockchain“ ist in aller Munde und trotzdem können sich nur recht wenige etwas Konkretes darunter vorstellen. Ähnlich ging es auch uns. Zumindest, bis wir unser eigenes Testprojekt aufgesetzt haben, um einfach mal auszuprobieren, was es eigentlich heißt, „eine Blockchain zu bauen“.

Kein Plan von nix. Also erstmal recherchieren.

Vielleicht ist es etwas überspitzt formuliert, aber wenn wir ehrlich sind, hatten wir am Anfang des Projekts wirklich nicht viel Ahnung. Zumindest nicht, wie man ein Blockchain-Projekt aus technischer Sicht angeht und was man alles beachten muss. So mussten wir uns beispielsweise mit der Frage auseinandersetzen, ob wir uns eine eigene private Chain aufsetzen oder ob wir auf einer öffentlichen (Test-)Chain aufbauen. Auch die Wahl der Blockchain – ob Ethereum, Hyperledger, Tendermint oder etwas ganz Exotisches – war keine unerhebliche Entscheidung. Also haben wir uns durch unzählige Tutorials und Manuals gewühlt, bis wir gefühlt ausreichend Wissen hatten, um eine Wahl unter Berücksichtigung von der Komplexität der einzelnen Blockchain-Systeme, unseres Anwendungsfalls und den zur Verfügung stehenden Ressourcen treffen zu können.

Letztlich entschieden haben wir uns für eine private Ethereum-Chain mit dem Proof of Authority Consensus Algorithmus. Durch den Verzicht auf einen Proof of Work Consensus war es für uns nicht notwendig, rechenintensives Mining zu betreiben, was bei nur sehr wenigen Transaktionen unwirtschaftlich wäre. Außerdem können wir mit dem PoA-Consensus fixe Blockzeiten garantieren und verbessern damit die User Experience.

Besonders hilfreich fanden wir die Dokumentation von Solidity und ein Tutorial von modal/duality.

Und was macht die Blockchain jetzt so?

Nicht viel. Oder anders formuliert: Genau das, was man ihr sagt, dass sie tun soll. Also haben wir uns ein wenig mit Smart Contracts befasst, dem Herzstück einer jeden Blockchain-Anwendung. Bei einer Ethereum-Blockchain werden solche Smart Contracts in einer eigenen high-level Programmiersprache namens Solidity geschrieben. Dabei handelt es sich um eine Mischung aus den Programmiersprachen JavaScript, C++ und Python, wobei Solidity sich hier und da einfach die Rosinen raus gepickt hat und sich dadurch mit statischer Typisierung, Vererbung und komplexe Datentypen hervortun kann. Die Sprache bzw. der Compiler für Solidity werden auch stetig weiterentwickelt, was zu immer neuen Features führt.

Ähnlich wie Klassen in der Objektorientierten Programmierung können in Solidity sogenannte Contracts erstellt und mit Funktionalität bestückt werden. Wer schon mal eine Klasse in JavaScript gesehen hat, sollte mit der Syntax von Solidity halbwegs etwas anfangen können. Nachfolgend daher nur ein sehr kurzes Beispiel für einen Contract, welcher letztlich nur aussagt, dass der Besitz des Vertrags bei der Erstellung desselbigen auf den Ersteller fixiert wird und dieser (und nur dieser) den Vertrag auch wieder auflösen kann:

    contract CreatorIsOwner {
        address owner;
        
        function CreatorIsOwner() public {
            owner = msg.sender;
        }

        function destroy() public {
            require(msg.sender == owner);
            selfdestruct(owner);
        }
    }

Zum Verständnis: Die Funktion CreatorIsOwner() ist der Konstruktor des Contracts und wird, aufgrund der Gleichnamigkeit zum Vertrag, bei der Erstellung des Vertrags aufgerufen (eine neuere Version von Solidity verwendet das Schlüsselwort constructor stattdessen). Die Funktion destroy() kann anschließend für einen bestehenden Vertrag aufgerufen werden, jedoch nur vom Besitzer des Vertrags wie durch require(msg.sender == owner) ausgedrückt. Außerdem wird durch den Aufruf von selfdestruct(owner) nicht nur der Vertrag aufgelöst, sondern es werden auch noch alle gebundenen Ether des Vertrags an den übergebenen owner übertragen. Dadurch ist sichergestellt, dass beim Auflösen des Vertrags kein Ether verloren geht bzw. unerreichbar wird.

Zum Veröffentlichen des Contracts kann dieser einfach mit Hilfe eines entsprechenden Tools (bspw. Ethereum Wallet) im Rahmen einer Transaktion an die Blockchain gesendet werden. Der Contract erhält dadurch eine eigene Adresse auf der Blockchain und kann in weiterer Folge von anderen Nutzern der Blockchain genutzt werden, sofern sie die Adresse und das nicht öffentliche Interface des Contracts kennen. In unsrem Falle wäre der Contract aber nicht von anderen Nutzern nutzbar, da er jegliche Transaktionen ablehnen würde, wenn sie nicht vom erstellenden Nutzer aus gesendet würden.

Den Contract selber kann man sich wie eine Art „instanziierte Klasse“ vorstellen. Ein Contract kann dabei wie eine Klasse unterschiedliche Eigenschaften besitzen; darunter Eigenschaften, Methoden, Events und weitere. Einzelne Funktionen des Contracts haben bei ihrer Ausführung (= Transaktionen) immer Zugriff auf die aktuellsten Informationen des Contracts. Es können auch mehrere Instanzen eines Contracts parallel existieren. Das erlaubt beispielsweise, innerhalb eines Contracts neue Contracts zu erstellen. Im Grunde passiert bei Contracts nichts anderes als in der objektorientierten Programmierung, nur eben, dass die Begrifflichkeiten etwas anders lauten.

Und weil das jetzt sehr technisch und doch etwas theoretisch war, kommt nachfolgend ein praktisches Beispiel.

Kaffeewirtschaft. Eigentlich simpel – oder doch eher total kompliziert?

Bei uns im Unternehmen gibt es sehr viele Kaffeemaschinen. Diese werden zwar vom Unternehmen bereitgestellt, müssen aber von den Mitarbeitern selber verwaltet und betrieben werden. Sprich es gibt jeweils einen Kaffeemaschinenbetreuer, welcher die ihm zugeteilte Maschine regelmäßig nachfüllt, entkalkt, und so weiter. Als Betreuer(in) hat man in der Regel auch die Hoheit über die Kaffeekasse und ist für die Abrechnung dieser zuständig.

Da der Kaffee zum Nachfüllen der Maschinen von den Mitarbeitern selber zu zahlen ist, erhebt der Kaffeemaschinenbetreuer in der Regel einen Beitrag für die Nutzung der Maschine. Das kann sich in Form einer monatlichen Flatrate, einer bedarfsbasierten Kalkulation oder in sonstiger Form äußern. Die bedarfsbasierte Kalkulation, auch bekannt als „Strichliste“, ist dabei die häufigste Abrechnungsform und wird von den verschiedenen Betreuern, zumeist mit Zettel und Stift, manchmal aber auch mit Prepaid-Kaffee-Sticks umgesetzt.

Obwohl der Ansatz gut funktioniert und für die Mitarbeiter leicht verständlich ist, gibt es ein paar Nachteile. So kann beispielsweise ein Mitarbeiter nicht einfach bei jeder Kaffeemaschine im Unternehmen einen Kaffee beziehen, da der Kaffeemaschinenbetreuer der unterschiedlichen Maschinen in der Regel nicht derselbe ist. Es müsste also für den spontanen Konsum in einer anderen Abteilung jeweils ein zusätzliches Guthaben bei einem anderen Maschinenbetreuer erstanden werden.

Um diesen Vorgang zu eliminieren und weitere Eigenheiten des jetzigen Systems zu verbessern, dachten wir uns, die Blockchain hilft weiter. Daher haben wir einen Smart Contract geschrieben, der es erlaubt, Kunden und Kaffeemaschinen anzulegen, Kaffeetokens zu kaufen, zu verkaufen und zu transferieren. Und natürlich kann man auch ganz einfach eine oder mehrere Tassen Kaffee bezahlen, jeweils für ein gewünschtes Programm an der jeweiligen Maschine.

Der Wechsel zwischen Echtgeld (Euros) und den Kaffeetoken darf dabei immer nur durch autorisierte Personen geschehen und erfolgt nach einem vorgegebenen Kurs (1 Euro = 100 Kaffeetoken). Es ist sicherzustellen, dass nur so viele Kaffeetoken im Umlauf sind, wie Geld von diesen zum Tausch berechtigten Personen eingesammelt wurde. Mit dem steten Rücktausch von Token zu Euros durch die Kaffeemaschinenbetreiber bleibt das Geld außerdem immer im Fluss.

Was ist mit Transaktionsgebühren?

Wie jedes andere Blockchain-Netzwerk bedarf es auch in unserem einer gewissen Gebühr zur Durchführung von Transaktionen. Die Ether zum Begleichen der Transaktionsgebühren werden jeweils von den „Wechselstuben“ beim Erstehen von Token an die Konsumenten mitgeliefert. Die Wechselstuben hingegen erhalten ihre Tokens regelmäßig von einer zentralen Autorität, welche auch die Validator Nodes des Netzwerks betreibt. Diese zentrale Autorität bekommt ihre Tokens durch die Validierung von Transaktionen. Dadurch bleiben die vorhandenen Ether immer in einem Kreislauf erhalten.

Durch den Einsatz eines einfachen Tokens mit einem fixen Wechselkurs zu unserer realen Währung ersparen wir es uns, eine komplizierte, wertbasierte Währung innerhalb unsrer Blockchain aufzuziehen. Wir möchten davon unter anderem auch deshalb Abstand nehmen, weil schwankende Währungskurse bei den Nutzern nur selten auf Verständnis stoßen, wenn der Kurs sinkt. Man stelle sich vor, gestern bekam man noch zwei Kaffee für dasselbe Geld, für das man heute nur noch einen bekommt.

Und wie komme ich nun an einen Kaffee?

Dafür braucht es erst einmal unsere App, welche sich zwar noch in Entwicklung befindet und nicht komplett fertig ist, die wichtigsten Features (insb. das Kaufen von Kaffee) aber bereits unterstützt. Zur Benutzung der App wird derzeit ein vorhandenes Managed Wallet (auf dem App Ethereum-Node) und ein angelegter Kunde im Contract vorausgesetzt.

Weil wir diesen Prozess – global betrachtet – eher intransparent finden, da jede Abteilung „ihr eigenes Süppchen kocht“, dachten wir uns, eine Blockchain könnte helfen, um ein einheitliches Abrechnungssystem zu schaffen. Dadurch könnte man nicht nur bei jenen Maschinen einen Kaffee konsumieren, wo man sich ein Guthaben durch eine Einlage in der Kaffeekasse erkauft hat; sondern es wäre möglich, im ganzen Konzern überall Kaffee zu trinken und trotzdem käme keiner zu kurz.

Also ab in die Umsetzung!

Bei unserem Smart Contract haben wir uns einige Gedanken gemacht, wie wir unterschiedliche Szenarien abbilden können, da nicht jeder Kaffeemaschinenbetreuer dasselbe Prinzip verwendet. Beispielsweise kostet der Kaffee, abhängig von den verwendeten Kaffeebohnen, nicht immer gleich viel. Daher sind wir zu folgendem, allgemeinen Szenario gekommen:

Als Kaffeemaschinenbetreiber kann man seine Kaffeemaschine(n) im neuen Smart Contract registrieren, mit einem Wallet auf der Blockchain versehen und zur Benutzung anderen Mitarbeitern zur Verfügung stellen. Es können außerdem sehr frei Programme der Kaffeemaschine definiert werden (z.B. Espresso, normaler Kaffee, etc.). Diese haben jeweils einen fix definierten Preis (in Kaffeetokens).

Ein(e) Konsument(in) kann dann in de CoffeeChain App die Kaffeemaschine, das gewünschte Programm sowie die Anzahl der gewünschten Tassen auswählen und eine Transaktion durchführen, welche Kaffeetokens von seinem bzw. ihrem Wallet auf das Wallet der Kaffeemaschine überträgt. „Intelligente Kaffeemaschinen“ (so wie unsere Nespresso Delonghi nach ein paar „Umbauarbeiten“) können nun auf Events (Transaktionen) in der Blockchain hören und, wenn eines empfangen wird, das richtige Kaffeeprogramm starten. Die Blockchain kann aber auch nur für die Abrechnung verwendet werden, ohne dass die einzelnen Kaffeemaschinen direkt mit ihr verknüpft sind.

Aaaaaaaaaalsooo?

Um die vielen Worte nochmal übersichtlich zusammenzufassen, hier ein paar Key Facts zu unserem Testprojekt:

  • Wir nutzen eine private Ethereum Blockchain mit einem Proof of Authority Consensus Algorithmus und drei autorisierten Wallets.
  • Das Netzwerk verfügt über drei Nodes, einer zur Verbindung von Apps, einer für die Kaffeemaschine und einer als Backup.
  • Eine erste Kaffeemaschine (Nespresso Delonghi, ca. 40 €) haben wir mit Hilfe eines Lötkolbens, ein paar Relays und eines RaspberryPis bereits eingebunden.
  • Unsere App wurde auf Basis von Xamarin.Forms entwickelt und sollte cross-platform lauffähig sein, allerdings wurde sie bisher nur auf Android getestet.
  • Transaktionen wie bspw. das Kaufen eines Kaffees werden innerhalb eines Smart Contracts auf der Blockchain gespeichert.
Fazit

Bereits für einen sehr einfachen Anwendungsfall wie die Verwaltung von Kaffeemaschinen in einem Unternehmen erfordert eine Blockchainlösung einiges an Hintergrundwissen. Wir haben gemerkt, dass das Designen und Schreiben von Smart Contracts ein Umdenken erfordert, wenn man von der traditionellen Softwareentwicklung herkommt. Abläufe funktionieren anders und man muss viel mehr Wert auf kleine Details legen, da Änderungen zu einem späteren Zeitpunkt nicht mehr möglich bzw. mit enormem Aufwand (und ggf. Kosten) verbunden sind.

Außerdem sind wir mittlerweile der Meinung, dass Blockchain nicht wie von vielen gedacht und angepriesen, die Lösung für jegliche Probleme der Menschheit ist. Wie auch bei vielen anderen Technologien gilt es, die richtigen Anwendungsfälle zu finden, bei denen Blockchain wirklich einen Mehrwert bietet und nicht nur dazu führt, dass Daten in einer dezentralen Datenbank – denn letztlich ist eine Blockchain nicht viel anderes – gespeichert werden. Bei unserer Kaffeewirtschaft könnte man darüber streiten, ob eine Blockchain wirklich notwendig ist – aus Sicht der Transparenz, insbesondere da es keinen Verwalter gibt, der für alle Kaffeemaschinen zuständig ist, macht es unserer Ansicht nach durchaus Sinn.

Andererseits haben wir aber auch gelernt, dass man vorzeigbare Prototypen bereits mit sehr geringem Aufwand erstellen kann. Klar, das Schreiben einer App und dergleichen erfordert Zeit – aber einen prototypischen Contract hat man recht schnell geschrieben. In unserem Beispiel haben wir einen ersten Prototyp der privaten Chain, des Smart Contracts und einer angeschlossenen Kaffeemaschine nach bereits circa zehn Arbeitsstunden gehabt. Das finale Produkt, welches auch auf den Bildern zu sehen ist, hat dann allerdings nochmals ein paar zusätzliche Stunden verschlungen. Das wäre allerdings auch dann der Fall gewesen, hätten wir keine Blockchain eingesetzt.

Falls euch der Beitrag gefallen hat und ihr mehr über das Thema erfahren wollt, könnt ihr bei uns im GitHub-Repository vorbeischauen. Wir haben das gesamte Projekt open-source zur Verfügung gestellt und stehen dort auch gerne für Fragen zur Verfügung.

Credis

Wir, Tobias und Marvin, möchten noch die Möglichkeit nutzen und uns bei allen Beteiligten für ihre Unterstützung bedanken. Besonderer Dank geht an den Bereich IT fürs Sponsoring der Hardware und an die Lehrwerkstatt für das zur Verfügung stellen von Arbeitsplatz, Arbeitsgeräten und Kleinmaterial. Wir haben uns über euer Interesse an diesem Projekt wirklich sehr gefreut!

Comments  / 1

Schreibe einen Kommentar

Your email address will not be published. Website Field Is Optional

8 + siebzehn =