Ein Beitrag von: René Peinl, Hochschule für angewandte Wissenschaften Hof

Die Grundidee ist bestechend einfach: in allen Fällen, in denen bisher ein menschlicher oder organisatorischer Intermediär benötigt wurde, oder ein Vertrauensvorschuss für den Geschäftspartner notwendig war, sollen in Zukunft Blockchain-basierte Anwendungen die Lösung darstellen. Dies betrifft neben Banken auch Versicherungen [1], Notare, das Katasterwesen [2] und die Logistik [3]. Um herauszufinden warum und wie eigene Geschäfte und Geschäftsmodelle auf Blockchain-Basis funktionieren können, müssen zunächst die grundlegenden gewünschten und unerwünschten Eigenschaften der Blockchain analysiert und deren Wichtigkeit für die jeweiligen Anwendungsfälle untersucht werden.

Im Grunde kann Blockchain als eine verteilte, dezentrale NoSQL Datenbank betrachtet werden, die einige Besonderheiten aufweist. Aus der technischen Dezentralität folgt jedoch nicht notwendigerweise auch eine fehlende zentrale Kontrolle. In einigen Fällen haben Blockchain-Plattformen trotzdem einen zentralen Betreiber, der sich über Mechanismen in der Software zum Beispiel für jede durchgeführte Transaktion eine Transaktionsgebühr sichert. Die Zentralisierung kann sich auf den einzelnen Dienstanbieter beziehen, oder auf einen Verifizierer, der den Zugang zur Plattform regelt [4]. Oft kontrolliert auch der zentrale Betreiber der Blockchain-Plattform deren Source-Code, wodurch dieser großen Einfluss hat.

Diese technische Eigenschaft wird in der Blockchain rein über Software, Kryptografie und die redundante Datenhaltung garantiert, während herkömmliche Lösungen zum Beispiel für die Archivierung auf entsprechende Hardware mit Löschschutz angewiesen sind, um Unveränderbarkeit zu garantieren. Unveränderbarkeit kann aber auch eine nachteilige Eigenschaft sein, wenn personenbezogene Daten aus juristischen Gründen gelöscht werden müssen, was in der Blockchain schwierig ist [5].

Jeder Teilnehmer an der Blockchain kann grundsätzlich alle Transaktionen sehen. Es gibt jedoch auch Varianten, die mit Zugriffsrechten [6], Sidechains [7] oder ähnlichem arbeiten, um diese universelle Transparenz einzuschränken.

Ähnlich wie bei Kontonummern verzeichnen Transaktionen in der Blockchain keine Klartextnamen, sondern Adressen. Diese können wie bei IP-Adressen mal einfacher, mal schwieriger einer realen Person zugeordnet werden. Anders als bei Bankkonten, ist es bei vielen Blockchain-Lösungen problemlos möglich, dutzende oder hunderte Adressen zu benutzen, um nicht über die Historie der Transaktionen einer Adresse leichter identifiziert werden zu können.

Jedes verteilte System braucht einen Mechanismus zur Konsensfindung und Vermeidung des Split-Brain-Problems [8]. Der gebräuchlichste Mechanismus für öffentliche Blockchain-Lösungen heißt Proof of Work. Ein nur durch Ausprobieren vieler Möglichkeiten zu lösendes mathematisches Problem, das aber mit der richtigen Lösung leicht überprüft werden kann, dient zur Absicherung, dass nur gültige Transaktionen in der Blockchain verzeichnet werden. Dadurch wird aber auch viel Energie benötigt, was sich wiederum in hohen Transaktionsgebühren auswirkt. Andere Verfahren wie „Proof of Stake“ oder „Federated Byzantine Agreement“ haben dieses Problem nicht und sind für Unternehmenslösungen besser geeignet [9]. Tendermint kombiniert die beiden letztgenannten geschickt [4].

Im Grundmodell der Blockchain hat jeder Teilnehmer eine vollständige Kopie der gesamten Datenbasis. Dies ist im Gegensatz zu kontrollierter Redundanz, wo man typischerweise zwischen zwei und fünf Kopien der Daten vorhält, eine pure Verschwendung von Speicherplatz, da (hundert-) tausende Kopien vorgehalten werden. Dadurch steigt auch die Netzwerklast und Clients mit wenig Speicherplatz bleiben außen vor, weil sie die schnell Dutzende von Gigabyte große Datenbasis nicht lokal speichern können.

In der Literatur werden sieben Klassen von Anwendungsfällen diskutiert [10]:
(1) Bezahlung durch Transaktion von Währungs-Tokens (Ripple),
(2) Individuelle Informationsverwaltung, mittels derer Informationen aggregiert, gespeichert und durch den Besitzer verwaltet werden und der die Blockchain als Verzeichnis dient (Patientenakte),
(3) Transaktionshistorie mit Informationen über Objekte oder deren Referenzen, etwa bzgl. Existenz, Eigentum oder Transaktionsdatum (Kataster, Car Sharing, Supply Chain),
(4) Kommunikation, bei welcher Inhalte dezentral verwaltet werden, was Datenschutz befördert und die Macht des Kommunikationsintermediärs beschränkt,
(5) Ergebnisbasierte, automatisierte Transaktionen, die Ereignissen folgend als Smart Contracts durch die Blockchain abgewickelt werden (Versicherung),
(6) Transaktionsmediär, zur Vermittlung von Partnern, der Erfassung, Überwachung und Abwicklung von Vereinbarungen sowie möglicher Schlichtung bei Rückabwicklungen (Strommarkt) und
(7) Communitymanager, bei welchem Algorithmen die Koordination gleichgestellter Akteure so regeln, dass Kooperationsregeln erfasst, aber nur gemeinschaftlich geändert werden können (DAO, decentral autonomous organization).
Im Folgenden werden ausgewählte Beispiele intensiver diskutiert.

Ein zentrales Register der Eigentumsrechte von (juristischen) Personen kann sinnvoll mit Blockchain-Technologie abgebildet werden. Bisher dafür vorgeschlagene Lösungen haben aber noch Probleme [2]. Transparenz ist in diesem Fall nur bedingt hilfreich. Einerseits regelt die Grundbuchordnung §12 ein Auskunftsrecht bei berechtigtem Interesse. Andererseits ist es gerade nicht gewünscht, dass sämtliche Eigentumsverhältnisse und Hypotheken von Grundstücken öffentlich einsehbar sind. Auch Pseudonymisierung ist nicht gewollt. Vorausgesetzt nur Berechtigte dürfen die Transaktionen sehen, soll es einfach möglich sein, die wahre Identität zu ermitteln. Die Dezentralität ist nicht nötig, da der Staat als zentrale Vertrauensstelle hinter der Lösung steht. In Ländern, in denen man dieses Vertrauen in den Staat nicht als durchgängig gegeben ansehen kann, wäre eine technische Lösung wünschenswert. Die Unveränderbarkeit getätigter Transaktionen ist hier sinnvoll. Eine sichere Lösung für die gesamte Abwicklung von Eigentumsübertragungen wäre nur dann gewährleistet, wenn auch die Bezahlung über die Blockchain läuft oder es verlässliche Schnittstellen zu den Zahlungsnetzwerken gibt. Ansonsten könnten Eigentümer leicht erpresst werden das Eigentum ohne entsprechende Gegenleistungen zu übertragen. Dieses Problem gilt bei allen Blockchain-Lösungen. Die garantierte Ausführung von Smart Contracts unter bestimmten Bedingungen kann durch Betrug an den Schnittstellen ausgehebelt werden. Der Einsatz von Blockchain im Katasterwesen birgt weniger Potenzial für neue Geschäftsmodelle denn als Gefahr für etablierte Berufsgruppen wie Notare.

Smart Contracts sind ein Code, der analog einem Datenbanktrigger ausgeführt wird, wenn ein bestimmtes Ereignis eintritt und der in der Blockchain hinterlegt ist. Darüber können Versicherungsbedingungen transparent hinterlegt und zum Beispiel die Zahlung von Entschädigungen bei Flugausfall automatisiert abgehandelt werden, wie das bei InsurETH auf Ethereum-Basis passiert [1]. Wichtig ist dafür, dass verlässliche Informationsquellen vorliegen, auf deren Grundlage die Ansprüche automatisiert entschieden werden können. Während die Blockchain-Technologie selbst als weitgehend fälschungssicher eingestuft wird, könnte ein Flugauskunftssystem, das stattgefundene oder ausgefallene Flüge meldet eventuell leichter zu fälschen sein, zum Beispiel über Man-in-the-Middle-Attacken. Im Gegensatz zu diesem endkunden-orientierten Szenario hat sich die Blockchain-Insurance-Industrie Initiative zum Ziel gesetzt, den Austausch zwischen Erst- und Rückversicherern über Blockchain abzubilden [1]. In beiden Fällen stehen Effizienzverbesserungen bei der Abwicklung bestehender Geschäftsmodelle im Vordergrund.

Erfolgte ärztliche Behandlungen eines Patienten, verschriebene Medikamente und ermittelte Befunde sind unveränderlich in ihrer Natur. Verschiedene Parteien, wie der Patient selbst, die behandelnden Ärzte, Pflegedienste und die Krankenkasse sind involviert und würden von einem einheitlichen System profitieren [11]. Da das Gesundheitswesen in vielen Ländern staatlich organisiert oder zumindest beaufsichtigt wird, könnte der Staat auch ohne Blockchain ein zentrales System aufbauen. Ein dezentrales System, das von Krankenkassen oder großen Krankenhäusern betrieben wird, hätte aber durchaus seinen Charme. Problematisch ist das Thema Transparenz, da die Gesundheitsdaten eines Menschen sehr persönlich sind [12] und eine Offenlegung gegenüber Dritten wie dem Arbeitgeber sehr heikel wäre. Abweichend von dem üblichen Blockchain-Modell bräuchte es also eine vollständig verschlüsselte Datenhaltung und feingranulare Zugriffsberechtigungen, die zeitlich befristet werden können und in einer zweiten Blockchain verwaltet werden könnten. Große Daten wie Röntgenaufnahmen müssten gesondert gespeichert werden (off-chain). Anonymität ist aus Patientensicht sicherlich wünschenswert, für die anderen Beteiligten aber kontraproduktiv und unter der Voraussetzung des Zugriffsschutzes auch unnötig. Pseudonymisierung, die durch gesonderten Identitätsnachweis und den Besitz des privaten Schlüssels der Patientenakte ergänzt wird ist jedoch denkbar. Trotz dieser Herausforderungen wurden entsprechende Lösungen vorgeschlagen [13].

Die dezentrale Blockchain-Technologie mit ihrem Versprechen, Vertrauen in unbekannte Transaktionspartner durch unbestechliche Technik zu ersetzen, scheint für alle auf Sharing basierende Geschäftsmodelle geradezu ideal geeignet. Diese sind im 21. Jahrhundert stark im Kommen wie der Erfolg von Uber und AirBnB zeigen. Car Sharing wird als Beispiel in der Literatur mehrfach genannt [14, 15]. Konkret umgesetzt werden solche Projekte aber gerade erst [16], meist von Start-ups wie der Firma Darenta. Auf Youtube finden sich auch Videos von Demonstratoren [17]. Die Schwierigkeit besteht in der Absicherung der Schnittstellen zwischen Blockchain und Auto, sowie den regulatorischen Aspekten. Dem Autor ist keine in Deutschland zugelassene Lösung bekannt, die eine Weiterfahrt nach Verbrauch des überwiesenen Geldes durch eine automatische Abschalteinrichtung im Auto verhindert. Davon abgesehen erscheint das Szenario tatsächlich gut geeignet. Transparenz ist für den Autonutzer kein Problem, solange die Pseudonymisierung hinreichend gut ist. Für den Autoanbieter ist wiederum Anonymität des Kunden kein Problem, solange die Zahlung sicher erfolgt und eventuelle Schäden am Fahrzeug durch eine Versicherung abgedeckt sind. Allerdings ist es juristisch gesehen zumindest eine Grauzone, einen nicht illegalen Vertrag mit Unbekannten abzuschließen und eine Versicherung für diese Fälle dürfte sehr teuer sein, so dass sich die Frage nach der Rentabilität des Geschäftsmodells stellt.

Bei Softwarelizenzen muss der Lizenzgeber darauf vertrauen, dass der Lizenznehmer genügend Lizenzen erworben hat und nicht unter-lizensiert ist. Auch der legale Weiterverkauf von Lizenzen ist derzeit schwierig und durch enge juristische Regeln eingeschränkt [19]. Weiterhin brauchen sowohl Softwarehersteller als auch Unternehmen, die viele Lizenzen kaufen eine eigene Software, die hilft den Überblick zu behalten. Lizenzaudits werden zusätzlich eingesetzt, um die korrekte Lizensierung sicherzustellen. Eine Blockchain- Lösung dafür könnte allen Beteiligten die erwünschte Transparenz bieten, den Weiterverkauf vereinfachen und eine automatische Überprüfung der Lizenz beim Start der Software ermöglichen. Die Hochschule Hof entwickelt gerade zusammen mit SBB Software eine solche Lösung. Im Gegensatz zum Ansatz von Blocher et al. [19] soll dabei aber die Energieeffizienz berücksichtigt werden, so dass Proof-of-Work-basierte Blockchains als Grundlage ausscheiden. Auch das Thema Transparenz bzw. Anonymität soll berücksichtigt werden, so dass nicht jeder alle Lizenztransaktionen einsehen kann. Um die gewünschten Eigenschaften zu erreichen, wird eine zugriffsbeschränkte Konsortiallösung entwickelt (permissioned), die nur verifizierte Teilnehmer zulässt und die Anzahl an „validating Peers“ beschränkt. Hyperledger Fabric und Burrow wurden als geeignete Basistechnologien identifiziert, müssen jedoch beide aufwändig angepasst werden. Bei Fabric fehlt ein Coin-Mechanismus, der jedoch wichtig ist, um die Abhängigkeit nach außen zu verringern. Bei Burrow muss dagegen ein Token-Konzept (Colored Coins [9]) implementiert werden, um GeldÜberweisungen von Softwareübertragungen zu unterscheiden, sowie die Übertragung von Lizenzen von Software A von solchen von Software B zu unterscheiden. Entwickler so einer Lösung können Einnahmen über Transaktionsgebühren generieren, die zwischen den Betreibern der validating Peers aufgeteilt werden sollten, um Anreize für die Teilnahme zu schaffen. Eine weitere Möglichkeit wäre die Monetarisierung von Identitätsüberprüfungen oder der Überprüfung der Rechtmäßigkeit eines Lizenzerwerbs außerhalb der Blockchain, der zum Weiterverkauf in der Blockchain berechtigt.

Außerhalb fachlicher Anwendungsfälle gibt es eine Reihe neuer Technologieanbieter und ein ganzes Ökosystem an Integratoren und Beratern darum. Rückeshauser et al. [20] identifizieren fünf Typen von Geschäftsmodellen:

1. Infrastrukturanbieter wie BigChainDB, die Cloud-basiert die Nutzung einer Blockchain anbieten, ohne dass der Kunde sich um Installation und Betrieb kümmern muss.

2. Plattformanbieter wie IBMs Blockchain Plattform, die ähnlich wie Infrastruktur-Anbieter eine Blockchain Lösung in der Cloud anbieten, aber darüber hinaus die Entwicklung eigener Applikationen auf der Plattform ermöglichen.

3. Applikationsanbieter wie Kodak mit der FotoBlockchain, die fertig entwickelte Applikationen anbieten, die einen speziellen Anwendungsfall unterstützen. Die ersten drei Typen können analog zu den Cloud Betreibermodellen IaaS, PaaS und SaaS gesehen werden.

4. Integratoren wie Factom, die Unternehmen helfen eigene, maßgeschneiderte Blockchain-Lösungen auf Basis verfügbarer Implementierungen zu erstellen.

5. Anbieter komplementärer Dienste wie Blockchain University, die Schulungen, Trainings oder andere Dienstleistungen und Informationen rund um Blockchain anbieten. Die Anzahl der Möglichkeiten zum Generieren von Einnahmen mit diesen Geschäftsmodellen sind noch höher. Abonnements wie bei Cloudanbietern sind gängig. Eine Blockchainspezifische Möglichkeit der Finanzierung ist das Initial Coin Offering. Dabei wird ähnlich wie bei der Aktienausgabe eine Anzahl an plattformspezifischen Coins ausgegeben. Die Nachfrage bestimmt den Preis. Dies kann auch als eine Art Crowdfunding gesehen werden. Einmalige Gebühren pro Benutzer sind weitere Einnahmequellen. Durch das verbreitete Erheben von Transaktionsgebühren lösen Blockchain-Anwendungen das Versprechen der Cloudanbieter ein, dass Nutzungsabhängig gezahlt wird, was bei SaaS Diensten selten der Fall ist.