Die Blockchains wie Bitcoin, Ripple oder Ethereum funktionieren bereits seit einigen Jahren stabil im globalen Kontext. Unternehmen oder der öffentliche Bereich nutzen sie jedoch kaum. Wie erklärt sich die Zurückhaltung und wie passt dies zum disruptiven Charakter der Technologien?
Warum verwenden Unternehmen die Blockchain-Technologie nicht?
Partner des Bank Blogs
Hypes spalten…
Wie bei echten Hypes üblich teilt das jeweilige Thema schnell die Gemeinschaft: in die Enthusiasten und die Kritiker. Meist stellt sich letztlich heraus, dass die Annahmen beider Gruppen grundverschieden waren und bei dem sich langsam entwickelnden, durchdringenden Verständnis der Technologie die Meinungen beider Gruppen sich auch wieder annähern. In dieser Phase entscheidet sich dann auch, wie tragfähig die Versprechungen der neuen Technologie wirklich sind und wo ihre Nutzen und Grenzen tatsächlich liegen.
Die Blockchain-Technologie hat die zweite Phase schon erreicht, die Enthusiasten haben die technischen und regulatorischen Hürden entdeckt und die Kritiker haben verstanden, dass es sich nicht um eine Blockchain und auch nicht nur um eine Technologie dreht, sondern dass die allgemeineren Distributed Ledger Technologien (DLT) viele Ausprägungen und Implementierungen haben und diese sorgfältig gegeneinander abzuwägen sind.
Eine mögliche Klassifizierung von Distributed Ledger Technologien bzw. Blockchain-Implementierungen.
Zudem ist vielen Verantwortlichen mittlerweile klar, dass das Potential von DLT nur ganzheitlich genutzt werden kann, d.h. nur bei einer konzernübergreifenden Prozessrestrukturierung, die der Verwendung einer DLT vorausgehen muss, kann diese Technologie überhaupt einen echten Nutzen bringen.
Transformation der Prozessorganisation in Unternehmen.
Technik first!
Wir wollen uns hier auf einen kleinen Bereich der DLT konzentrieren und aufzeigen, welche technischen Hürden für die großflächige Verwendung der Blockchain-Technologie es geben kann. Weder regulatorische, juristische, noch gesellschaftliche Probleme werden angesprochen, wobei diese natürlich ebenfalls vorhanden und potentiell viel dringender sein können.
Ausführbare dezentrale Logik mit Ethereum
Ethereum ist neben Bitcoin und Ripple eine der großen und etablierten Implementierungen einer offenen Blockchain-Technologie, unter den etablierten Blockchains ist Ethereum die einzige Implementierung eines turing-vollständigen Systems, so dass beliebige Logik in der Blockchain ausgeführt werden kann, ähnlich zur Anwendungsentwicklung in bekannten Umgebungen wie Java oder .NET.
Diese Eigenschaft macht die Ethereum Blockchain zur Basis für dezentrale Programmlogiken (Smart Contracts) und dezentralen Anwendungen (dapps), die beliebige Aufgaben ausführen können, im Gegensatz zur Bitcoin Blockchain, die spezialisiert auf Werteübertragungen bzw. einfachen Transaktionen ist (dies ist technisch nicht ganz korrekt, aber als Verallgemeinerung zur Verständlichkeit zu sehen).
Und wieder mal, Willkommen Alice und Bob!
Während Alice Bob also nur Bitcoins überweisen kann, können sich beide bei Ethereum auf eine beliebige Logik einigen: wenn Bob 1.000 Euro an Alice am 01.01.2018 zu dem abgestimmten Smart Contract transferiert und der DAX bis März 2019 nie über 10.000 Basispunkten liegt, kann Bob am 31.03.2019 1.200 Euro einziehen. Vertrauen muss man hier nur auf die korrekte Datenquelle für den DAX, die aber vorher von beiden Parteien abgestimmt werden kann.
Diese Logik wird dann unveränderlich und permanent in der Blockchain abgelegt und unabhängig von äußeren Einflüssen garantiert ausgeführt.
Dies ermöglicht mannigfaltige Anwendungsfälle, z.B. im Bereich des IoT: wenn Bob jeden Monat 1.000 Euro an Alice transferiert, öffnet sich das Türschloss seiner Wohnung, sonst nicht.
Gemeinsam ist allen Blockchains, dass diese permanente Verfügbarkeit garantieren (100 Prozent statt 99,99x Prozent), nicht zentral beeinflussbar oder zensierbar sind und die Beteiligten keiner dritten Partei vertrauen müssen. Gerade Ethereum ist deshalb aus juristischem Blickwinkel sehr interessant, da zwei Parteien einen Vertrag schließen können, den keine dritte Partei verhindern oder verändern kann (daher der Ausdruck „Smart Contract”). Dies ist möglich ohne dass die beiden Parteien sich einander vertrauen müssen, da die Ausführungslogik in der Blockchain liegt und von keiner Partei verändert werden kann. Damit sind drastische Kosteneinsparungen und Effizienzsteigerungen durch Ausschluss der Intermediäre und Vollautomatisierung von Prozessen möglich.
…und warum ist die Blockchain dann nicht schon überall?
Wenn die Technologie also so viele unbestreitbare Vorteile hat, warum wird sie nicht schon massiv genutzt?
Gehen wir davon aus, dass tatsächlich die Vorarbeit geleistet wurde und es einen von allen Parteien abgestimmten Prozess und eine spezifizierte einheitliche Domäne gibt, dann gibt es “nur noch” technische Herausforderungen:
- Geschwindigkeit/Skalierbarkeit
- Vertraulichkeit/Datenschutz
- Reifegrad/Unternehmenseignung
Geringe Geschwindigkeit/Skalierbarkeit
Eine Blockchain-Lösung ist um Größenordnungen langsamer als eine Lösung mit herkömmlichen Technologien. Dies ist eine konzeptionelle Einschränkung, die sich nur marginal mit Fortschritt der Technologie ändern wird, dafür haben alle Parteien den gleichen Stand der Daten und Prozessabläufe, es wird also, naiv ausgedrückt, die Sicherheit und Konsistenz der Daten der Geschwindigkeit geopfert.
Keine Vertraulichkeit/Datenschutz
Allgemein betrachtet ergeben Blockchains nur einen Sinn, wenn alle Beteiligten alle Transaktionen sehen können, da sonst kein Konsens möglich ist. Dies ist nicht immer korrekt, z.B. können sich zwei Partner darauf einigen, dass ein Attribut einer Transaktion “a5b81f9cf47b4f7b244c110c37305dab85944c2b” ist, wobei nur die beiden wissen können, dass diese Information der SHA-1-Hash von “Guten Tag!” ist. Bei einer Transaktion werden jedoch immer beide Parteien bekannt sein, auch wenn zunächst nur als anonyme Adressen (wie “0xdbdcdb5972e88e5273e46290c0d6bb3a96c23628”). Wird die Identität einer Adresse jedoch aufgedeckt, ist die gesamte Transaktionshistorie für alle einsehbar.
Lösungsansätze gibt es hier schon einige, die allerdings aktuell aufgrund ihrer Komplexität zu aufwändig uns damit teuer sind. Es gibt aber auch spezialisierte Blockchain-Implementierungen wie Z-Cash oder Monero, die auch Empfänger von Transaktionen echt anonymisieren.
Geringer Reifegrad/Unternehmenseignung
Unternehmensanwendungen erfüllen viele nicht-funktionale Anforderungen, die in Blockchain-Implementierungen nicht berücksichtigt wurden, beispielsweise werden Unternehmensanwendungen entsprechend RBAC mit komplexen Zugriffkontrollen und Identitätsmanagementlösungen ausgestattet, diese müssen bei Ethereum erst nachgebaut werden. Auch der Umgang mit privaten Schlüsseln usw. muss neu überdacht werden, wenn technisch kein zentraler, d.h. administrativer, Eingriff möglich ist.
Lösungsansätze für Ethereum
Im folgenden wird nur auf mögliche Lösungen zur Skalierbarkeit eingegangen, in einer Fortsetzung gehen wir auf die beiden anderen Punkte ein. Allgemein wird die Skalierbarkeit aber als drängendstes Problem angesehen.
Off-Chain Payment Channels
Nach seinem Deal mit den 200 Euro Gewinn geht Bob in die Kneipe nebenan und plant, einige Drinks auf seinen Gewinn zu trinken. Die Kneipe ist sehr gut besucht und Bob kennt den Barkeeper gut. Statt also jedes Getränk direkt zu bezahlen, schreibt Bob an: für jedes Getränk macht der Barkeeper einen Strich auf Bobs Bierdeckel, Bob begleicht die Rechnung erst ganz am Schluss.
Wie hängt das mit der Blockchain zusammen? Wichtig ist, dass es nur eine “echte” Transaktion gibt, nämlich beim Begleichen des Deckels. Beiden Beteiligten ist somit eine Menge Zeit für Geldzusammenzählen, Geldwechsel usw. erspart worden. Für die Blockchain gilt: Bob und der Barkeeper kennen sich nicht, deshalb muss vorher eine Einlage hinterlegt werden. Diese ersetzt das nicht vorhandene gegenseitige Vertrauen („trustless”). Die Striche auf dem Bierdeckel sind hier Signaturen des aktuellen Betrages zwischen den Parteien mit dem privaten Schlüssel des Senders. Wichtig ist also, dass der Großteil der Interaktionen zwischen den Parteien nicht on-chain (langsam und teuer), sondern off-chain (beliebig schnell und kostenlos) erfolgt. Erst im Fall eines Konflikts bzw. am Ende der Vertragslaufzeit wird die Gesamtrechnung, die bis max. der Einlagenhöhe gehen kann, beglichen. Dies erfolgt wieder vollautomatisch und unbeeinflussbar durch einen Smart Contract.
Darstellung von On-chain und Off-chain Komponenten bei Payment- oder State-Channels.
Plasma
Nehmen wir an, Bob und Alice hätten nicht über Smart Contracts interagiert, sondern auf dem normalen Rechtsweg und Alice will Bob verklagen, weil der DAX einen Tag im Februar eben doch bei 9.998 Punkten lag und nun in einem Zivilprozess geklärt werden muss, wer Recht hat. Momentan würde, auf die Ethereum Blockchain übertragen, dies bedeuten, dass der Fall vor dem höchsten Gericht behandelt werden müsste. Dieses wäre entsprechend völlig überlastet oder, in der freien Marktwirtschaft, sehr teuer aufgrund der hohen Nachfrage.
Aktuell wird jede Transaktion, wie klein (im Sinne geringer Betrag) und unbedeutend (bspw. Alice kauft einen Kaffee bei Bob) sie auch sein mag, von der höchsten (und aktuell einzigen) Hierarchiestufe bearbeitet.
Plasma will hier Hierarchien aufbauen, so dass zwar die endgültige Absicherung auf der höchsten Ebene hinterlegt wird und dort auch im Zweifelsfall die letztlich gültige Entscheidung getroffen wird (natürlich wieder vollautomatisch per Smart Contract), aber der Betrieb der dezentralen Anwendungen in den Child chains, d.h. den hierarchisch unteren Stufen abläuft. Das ermöglicht um Größenordnungen schnellere Transaktionen und entlastet die höchste Stufe massiv.
Hierarchische Struktur einer Ethereum Blockchain für Transaktionen und Logikausführung.
Sharding
Sharding ist eine aus der Softwareentwicklung und -betrieb bekannte Massnahme, große Datenmenge und Cluster zu unterteilen. Sehr vereinfacht dargestellt wird die Blockchain in N Teile aufgeteilt, wobei jeder Teil nur 1/N Größe und Anzahl Transaktionen der Ursprungschain zu bearbeiten hat und dadurch entsprechend schneller und parallelisiert arbeiten kann. Wichtig ist hierbei die sinnvolle Einteilung der Shards, außerdem müssen die Überprüfer (“Collators”) sinnvoll zugeteilt werden, z.B. echt zufällig, damit ein Angriff nicht durch die geringere Menge der Gesamtteilnehmer und Verifizierer vereinfacht wird.
Los geht’s!
Dieser Überblick ist naturgemäß sehr oberflächlich und vereinfachend, es ist aber hoffentlich klar geworden, dass es unterschiedliche Blockchain-Technologien bzw. DLT gibt, die verschiedene nicht-funktionale, aber im Unternehmensumfeld unabdingbare Anforderungen nur unzureichend erfüllen, dass aber an Lösungen gearbeitet wird und es auch schon unterschiedliche valide Lösungsansätze gibt.
Auch wenn es noch viele Entscheider denken, sich zurücklehnen und erstmal abwarten ist vermutlich nicht die beste Strategie im Bezug auf Blockchain-Technologien. Die Umstellung interner Systeme auf diese Technologien ohne den notwendigen und sehr zeitaufwändigen organisatorischen Umbau der implementierten Prozesse aber mit Sicherheit auch nicht.
