Dezen­tra­li­sierte Archi­tektur: Was steckt hinter Blockchains?

Befeuert von immer neuen Kurshöhen der Krypto­wäh­rungen, findet derzeit eine lebhafte Debatte über Block­chains statt. Die einen preisen die „autarken“ Währungen als Heils­bringer in Krisen­zeiten, die anderen sehen im exzes­siven Strom­ver­brauch einen Klimakiller.

Doch welche Chancen und Risiken die neuen Techno­logien für Software­architektur bringen, wird selten disku­tiert. Über diese Frage­stellung möchte ich hier einen kleinen Überblick geben.

Block­chain, Ledger, Kryptowährung?

Im Begriffs­di­ckicht der konti­nu­ierlich neu entste­henden Techno­logien verschwimmt leicht die eigent­liche zentrale Idee der Block­chains: der „Distri­buted Ledger“. Ein Ledger – oder deutsch „Kassenbuch“ – ist eine sehr alte Erfindung. Er zeichnet sich dadurch aus, dass neue Daten­sätze bzw. „Trans­ak­tionen“ nur angefügt werden können. Dies steht im Kontrast zu klassi­schen Daten­bank­mo­dellen, bei denen Einträge auch verändert oder gelöscht werden können. Der Vorteil einer solchen „Append-Only“-Speicherung liegt auf der Hand: nachträg­liche Manipu­lation – egal ob absichtlich oder verse­hentlich – wird dadurch erschwert. Denn Verän­de­rungen einer vergan­genen Trans­aktion beein­flussen alle nachfol­genden Trans­ak­tionen und müssten gleicher­maßen auf allen betei­ligten Knoten durch­ge­führt werden.

Wird diese Liste der Trans­ak­tionen auf mehreren unabhän­gigen Knoten verteilt gespei­chert, spricht man nun vom Distri­buted Ledger. Der Schlüs­sel­aspekt dabei ist, dass die Knoten nicht nur technisch, sondern auch organi­sa­to­risch unabhängig sein sollten. Durch solch eine dezen­tra­li­sierte Archi­tektur wird nun auch absicht­licher Manipu­lation ein Riegel vorge­schoben. Denn keine Partei kann eine Trans­aktion in ihrem lokal gespei­cherten Ledger ändern, ohne dass dies den anderen auffällt. Aus techni­scher Sicht benutzt man Hashfunk­tionen – ähnlich wie bei Git – um das Verfahren abzusichern.

Eine Block­chain ist nun nichts weiter als ein Distri­buted Ledger, bei dem mehrere Trans­ak­tionen zu Blöcken zusam­men­ge­fasst werden. Dies geschieht meist zur Verbesserung der Perfor­mance. Die meisten Krypto­wäh­rungen basieren auf diesem Verfahren; sie bündeln eine Reihe von Zahlungen und bilden in festen Zeitab­ständen neue Blöcke.

Block­chain oder Datenbank

Block­chain-Techno­logien können in vielen Organi­sa­tionen ein hilfreiches Werkzeug sein, um fachliche Verfahren abzubilden. Dabei ist aber zu bedenken, dass sich nur wenige Anwen­dungs­fälle dafür eignen. Denn während Block­chains aus techni­scher Sicht durchaus inter­essant sind, bringen sie auch Heraus­for­de­rungen im Betrieb mit sich. Die Vor- und Nachteile von verschie­denen Archi­tek­tur­op­tionen sind daher sorgfältig gegen­ein­ander abzuwägen. Grob gesagt stehen drei solcher Optionen mitein­ander im Wettbewerb:

1. öffent­liche Block­chains als Appli­ka­ti­ons­plattform (wie z.B. Ethereum),
2. private Block­chains mit Zugriffs­kon­trole (wie z.B. Hyper­ledger Fabric oder R3 Corda),
3. klassische Daten­bank­lö­sungen (wie z.B. PostgreSQL).

Die letzte Option wird sowohl von Softwarearchitekt:innen als auch Entwickler:innen üblicher­weise gut verstanden und eignet sich daher insbe­sondere für Projekte, in denen existie­rende Systeme angebunden werden müssen. Auch bringen Daten­bank­systeme eine hohe Flexi­bi­lität mit sich.

Kritisch ist jedoch zu sehen, dass der Betrieb von Daten­banken norma­ler­weise zentra­li­siert erfolgt. Sind in einem Projekt mehrere Partner­or­ga­ni­sa­tionen invol­viert, kann das zu Konflikten führen. In diesem Fall stellen private Block­chains (Option 2) eine Alter­native dar, da jede betei­ligte Partei Knoten betreiben kann. Die einge­bauten Konsens­ver­fahren stellen sicher, dass jederzeit eine global konsis­tente Sicht auf die gespei­cherten Daten vorliegt und Diskre­panzen sofort erkannt werden können. Der klare Vorteil hierbei ist, dass kein Vertrauen zwischen den Parteien erfor­derlich ist; im Gegensatz zum Betrieb von verteilten Datenbanken.

Den letzten beiden Optionen ist gemein, dass sie speziell zu betrei­bende Infrastruktur erfordern. Dies fällt bei öffent­lichen Block­chains (Option 1) weg, da weltweit inter­es­sierte Personen sich an der Fortschreibung des Systems betei­ligen. Hierbei entsteht aber das größte Risiko, denn die Verfüg­barkeit ist beileibe nicht garan­tiert. Auch die Trans­ak­ti­ons­ge­schwin­digkeit und deren Kosten unter­liegen starken Schwankungen.

Kosten­faktor Betrieb

Eine klare Einordnung, welche der genannten Möglich­keiten am günstigsten im Betrieb ist, lässt sich nur schwer machen. Betrachten wir beispiels­weise private Block­chains: Hyper­ledger Fabric ist ein komplexes System, welches aus mehreren Knoten­typen besteht. Man kann es durchaus in gängiger Container-Infrastruktur wie z.B. Kuber­netes betreiben, doch dies benötigt Erfahrung in der Administration.

Bei verschie­denen Cloud-Anbietern kann man auch auf „Managed Block­chain“ zurück­greifen; jedoch stellt das einen Wider­spruch in sich dar, da Block­chains ihre Stärken überhaupt nur in einer dezen­tralen Archi­tektur ausspielen können. Man kommt um eine dedizierte Infrastruktur also nicht herum.

Entscheidet man sich für eine klassische Datenbank als Persis­tenz­schicht, kommt zusätz­licher Aufwand bei der revisi­ons­si­cheren Archi­vierung der Einträge hinzu.

Trans­ak­tionen & Datenschutz

Der Begriff „Trans­aktion“ sugge­riert, dass Distri­buted Ledger sich für finan­zielle Buchungen eignen. Bei diesen besteht oft ein regula­to­ri­sches Interesse, dass sie dauerhaft manipu­la­ti­ons­sicher vorge­halten werden.

Doch in vielen Organi­sa­tionen besteht das Daten­modell eben nicht vorrangig aus solchen Ereig­nissen. Aus dem domänen­ge­trieben Entwurf bekannte Techniken wie Event Sourcing können helfen, in einer fachlichen Domäne geeignete Ereig­nisse zu identi­fi­zieren, die auf einer Block­chain als atomare Trans­ak­tionen gespei­chert werden können.

Gerade wenn perso­nen­be­zogene Daten im Spiel sind, muss das Haupt­au­genmerk darauf liegen, dass die Rechte der Betrof­fenen gewahrt werden: schließlich wäre es nicht DSGVO-konform, wenn man Lösch­an­fragen per se ablehnt, weil sie technisch nicht umsetzbar sind. Eine gängige Lösung dafür ist es, Daten­felder wie Namen oder Adressen mit indivi­du­ellen Schlüsseln verschlüsselt zu speichern und diese Schlüssel separat aufzu­be­wahren. Alter­nativ kann man auch nur Hashes von Daten­sätzen in der Block­chain verwalten.

Archi­tektur bedeutet Kompromiss

Auch die Block­chain macht Archi­tek­tur­arbeit nicht überflüssig, denn sie ist bei weitem nicht die Univer­sal­lösung, als die sie oft angepriesen wird. Im Gegenteil: Distri­buted Ledger als Persistenz – oder gar Plattform für Smart Contracts – haben spezi­fische Heraus­for­de­rungen, wodurch von ihrem Einsatz oftmals abzuraten ist.

Fest steht jeden­falls, dass in dem Bereich viel Innovation passiert. Vergleichbar ist ihre Entwicklung mit den NoSQL-Daten­banken. Früher belächelt, nehmen sie heute einen festen Platz im Werkzeug­kasten der Software­ent­wicklung ein. Dazu mussten sie ihre Kinder­krank­heiten wie mangel­hafte Trans­ak­ti­ons­se­mantik zunächst heilen. Ganz ähnlich ist es mit Block­chain-Techno­logien, die insbe­sondere bei der Perfor­mance noch Nachhol­bedarf haben.

In der Praxis

Besonders die Geschäfts­pro­zesse im Finanz- und Versi­che­rungs­sektor sind Block­chain-tauglich. Im „B3i“-Konsortium haben sich Branchen­größen wie Allianz, Munich RE und Generali zusam­men­ge­schlossen, um Risiko­transfers über eine Distri­buted-Ledger-Plattform abzuwi­ckeln. Das Projekt verwaltet sogenannte „Property Catastrophe Excess of Loss“-Vereinbarungen, angefangen von deren Aushandlung bis hin zur Buchhaltung. Ein weiteres Beispiel: Erst kürzlich hat die Europäische Inves­ti­ti­onsbank zusammen mit der Banque de France eine 100 Millionen Euro schwere Anleihe aufgelegt, deren Anteile über die Ethereum-Block­chain verkauft worden sind.

Fazit

In verteilten Organi­sa­tionen, bei denen mehrere vonein­ander unabhängige Parteien Daten lesen und schreiben, lohnt sich ein Blick auf die verschie­denen Block­chain-Techno­logien. Man sollte sich aber bewusst sein, dass die Archi­tektur und die Integration mit Umsys­temen einiges an Umdenken erfordern.