Auf der Cloud Academy der IBM bot sich mir eine gute Gelegenheit einmal wieder mit den Entwicklern der IBM zu sprechen. Im Grunde haben sich meine bisherigen Annahmen bestätigt: Der Hype kühlt langsam ab und insbesondere die Public Blockchain setzt sich noch nicht richtig durch. Es gibt dafür einfach keinen Business Case. Zudem ist unsere Gesellschaft nun einmal nicht dezentral organisiert. Das Vertrauensverhältnis basiert immer auf einer zentralen Instanz, die im Notfall auch die Durchsetzungskraft hat.

Hyperledger

Was sich ebenfalls zeigt, dass sich private Blockchains weiter durchsetzen. Dabei kommen allerdings andere Organisationsformen zum Einsatz. Die Usecases basieren durchweg auf dem Hyperledger Projekt, dass 2015 durch die Linux Foundation ins Leben gerufen wurde. Hyperledger implementiert ein Framework auf Basis von offenen Protokollen. Dabei werden neben den Mechanismen der Blockchain und Smart Contracts auch Identity und Access belange berücksichtigt. Das Indy Projekt ist mittlerweile im HyperLedger Projekt aufgegangen und sorgt hier für ein verteiltes, User-Centric Identity Management. Dazu in einem weitern Beitrag mehr. Einen guten Überblick gibt Jonas Verholen in einem Beitrag.

Usecases

Im Gegensatz zu Token Chain sind hier keine Miner notwendig. Die Kryptooperationen sind wesentlich weniger rechenintensiv und damit deutlich kostengünstiger. Zudem werden Der eigentliche Vorteil jedoch, die Information steht allen Teilnehmern zur Verfügung und ist schnell nachvollziehbar bleibt. So haben zum Beispiel etliche Retailer sich mit Lieferanten in einem Blockchain zusammengeschlossen, um die Lieferkette verfolgen zu können. Insbesondere bei immer einmal wieder vorkommenden Problemen mit einem Produkt, etwa verunreinigten Lebensmitteln, lässt sich so nachvollziehen, wo das Problem entstanden ist und schnell beheben. In diesem Beispiel konnte mit der Blockchain die Nachvollziehbarkeit von 7 Tagen auf wenige Sekunden reduziert werden. Natürlich hätte als Technologie auch eine herkömmliche DB eingesetzt werden können. Die teilnehmenden Unternehmen hätten dann allerdings einem neutralen, externen Dienstleister vertrauen müssen oder darauf, dass jeder Teilnehmer die DB mit den richtigen Daten füttert und die Firma, die sie betreibt auch keine unerlaubten Änderungen vornimmt. Durch die Blockchain kann jeder Teilnehmer unverzüglich sehen, wie andere Teilnehmer der Supplychain die Ware verarbeiten. So können nicht nur Qualitätsprobleme gelöst, sondern auch Fakeprodukte identifiziert werden.

Hochwertige Waren oder auch sensible medizinische Produkte lassen sin per App von Endverbraucher auf Echtheit prüfen. Dazu werden QR Codes auf der Verpackung oder auch Farbcodes des eigentlichen Produkts mit den erwarteten und in der Chain gespeicherten Ergebnissen verglichen. Wurde z.B. eine Packung an einen definierten Standort ausgeliefert und wird nun an einem anderen gescannt, ist die Wahrscheinlichkeit sehr hoch, dass es sich um ein Fake-Produkt handelt.

Es gibt eine Reihe weiterer sinnvoller Ansätze von Hyperledger Blockchains im Business. So wird vermutlich der Public Ansatz noch einige Zeit auf sich warten lassen, die Technologie erobert dennoch langsam sinnvolle und wirtschaftlich interessante Einsatzgebiete.

Identity

Eigentlich wird hier die Blockchain also eingesetzt, um die Identität eines Produktes nachvollziehbar zu machen und seine Eigenschaften unveränderbar zu speichern. Das dies insbesondere mit einem Hyperledger eine gute Idee ist zeigt sich daran, dass es mittlerweile eine ganze Reihe erfolgreicher Hyperledger Projekte gibt.

Was aber, wenn man einen Hyperledger zur Speicherung von personenbezogenen Daten einsetzen würde und welche Voraussetzungen müsste es dafür geben? Bisherige Ansätze gingen weitgehend ins Leere – einfach personenbezogenen Daten statt in einer DB in einer Blockchain zu speichern macht wenig Sinn und ändert nichts an den Kernproblemen zentraler Identitätsverwaltung, die Personenbezogenen Daten werden in vielen Silos gespeichert und jede Firma macht es für sich selber. Ein nachvollziehbarer Grund, denkt man an die Skandale z.B. mit offen gespeicherten Passworten bei Facebook.

Schlimmer ist bei dem Ansatz, die Löschung der Daten wäre nicht mehr möglich. Der vermeintliche Vorteil verkehrt sich ins Gegenteil. Was aber wäre, wenn man die Daten so abspeichert, dass nur Validierungsabfragen möglich sind, nicht jedoch die Daten selber preisgegeben werden? Was, wenn der User, also die Person selber für jeden einzelnen Client freigeben könnte, welche Abfragen er stellen kann?

Das Prinzip dabei ist ähnlich dem, was wir heute schon von Open ID als Consens kennen. Wenn ich z.B. ein Social Login mit Facebook mache, werde ich von Facebook gefragt, ob ich der App die angefragten Daten du Optionen freigeben möchte. Ärgerlich dabei ist, dass ich nur alle angeforderten freigeben kann oder die Anfrage ablehnen.

Bei Hyperledger Indy ist der Ansatz ein anderer. Durch einen erweiterten Namensraum auf Basis von URN’s kann jede einzelne Beziehung zwischen einer Identität und einem Client in Bezug auf einzelne Rechte verwaltet werden. Indy wird bei der IBM schon eingesetzt und ist mittlerweile Bestandteil diverser Blockchain Projekte und des Bluemix.

Indy verfolgt den Ansatz der Self Sovern Identity. Damit sind der Besitzer und Verwalter der personenbezogenen Daten nicht mehr ein Unternehmen oder eine andere, dritte Instanz, sondern die Person selber. Die Speicherung der Daten erfolgt so, dass Sie nicht direkt ausgelesen werden können. Neben den Kerndaten können diese durch zugelassene Teilnehmer der Blockchain weiter angereichert werden. So könnte z.B. hinterlegt werden, welchen Führerschein die Person besitzt. Anhand der Datensignatur lässt sich sicherstellen, dass die Führerscheindaten von einem autorisierten Partner gepflegt werden. Auch hier würden keine Klardaten, wie z.B. die Klasse des Führerscheins hinterlegt, sondern lediglich die Möglichkeit über Validierungsanfragen herauszufinden, ob der Inhaber der Identität berechtigt ist das gewünschte Fahrzeug zu lenken. Indy ist die nächste Stufe des digitalen Identitätsmanagements und beseitigt eine Reihe der Schwächen vorheriger Systeme. Natürlich muss die Identität auch hier ebenso durch eine vertrauenswürdige Instanz bestätigt werden. Am Registrierungsprozess ändert sich dementsprechend wenig und auch das wird im Indy deutlich, es gibt unterschiedliche Level of Assurance für eine Identität.