This blog post is also available in English
Doch welche Chancen und Risiken die neuen Technologien für Softwarearchitektur bringen, wird selten diskutiert. Über diese Fragestellung möchte ich hier einen kleinen Überblick geben.
Blockchain, Ledger, Kryptowährung?
Im Begriffsdickicht der kontinuierlich neu entstehenden Technologien verschwimmt leicht die eigentliche zentrale Idee der Blockchains: der „Distributed Ledger“. Ein Ledger – oder deutsch „Kassenbuch“ – ist eine sehr alte Erfindung. Er zeichnet sich dadurch aus, dass neue Datensätze bzw. „Transaktionen“ nur angefügt werden können. Dies steht im Kontrast zu klassischen Datenbankmodellen, 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ägliche Manipulation – egal ob absichtlich oder versehentlich – wird dadurch erschwert. Denn Veränderungen einer vergangenen Transaktion beeinflussen alle nachfolgenden Transaktionen und müssten gleichermaßen auf allen beteiligten Knoten durchgeführt werden.
Wird diese Liste der Transaktionen auf mehreren unabhängigen Knoten verteilt gespeichert, spricht man nun vom Distributed Ledger. Der Schlüsselaspekt dabei ist, dass die Knoten nicht nur technisch, sondern auch organisatorisch unabhängig sein sollten. Durch solch eine dezentralisierte Architektur wird nun auch absichtlicher Manipulation ein Riegel vorgeschoben. Denn keine Partei kann eine Transaktion in ihrem lokal gespeicherten Ledger ändern, ohne dass dies den anderen auffällt. Aus technischer Sicht benutzt man Hashfunktionen – ähnlich wie bei Git – um das Verfahren abzusichern.
Eine Blockchain ist nun nichts weiter als ein Distributed Ledger, bei dem mehrere Transaktionen zu Blöcken zusammengefasst werden. Dies geschieht meist zur Verbesserung der Performance. Die meisten Kryptowährungen basieren auf diesem Verfahren; sie bündeln eine Reihe von Zahlungen und bilden in festen Zeitabständen neue Blöcke.
Blockchain oder Datenbank
Blockchain-Technologien können in vielen Organisationen ein hilfreiches Werkzeug sein, um fachliche Verfahren abzubilden. Dabei ist aber zu bedenken, dass sich nur wenige Anwendungsfälle dafür eignen. Denn während Blockchains aus technischer Sicht durchaus interessant sind, bringen sie auch Herausforderungen im Betrieb mit sich. Die Vor- und Nachteile von verschiedenen Architekturoptionen sind daher sorgfältig gegeneinander abzuwägen. Grob gesagt stehen drei solcher Optionen miteinander im Wettbewerb:
- öffentliche Blockchains als Applikationsplattform (wie z.B. Ethereum),
- private Blockchains mit Zugriffskontrole (wie z.B. Hyperledger Fabric oder R3 Corda),
- klassische Datenbanklösungen (wie z.B. PostgreSQL).
Die letzte Option wird sowohl von Softwarearchitekt:innen als auch Entwickler:innen üblicherweise gut verstanden und eignet sich daher insbesondere für Projekte, in denen existierende Systeme angebunden werden müssen. Auch bringen Datenbanksysteme eine hohe Flexibilität mit sich.
Kritisch ist jedoch zu sehen, dass der Betrieb von Datenbanken normalerweise zentralisiert erfolgt. Sind in einem Projekt mehrere Partnerorganisationen involviert, kann das zu Konflikten führen. In diesem Fall stellen private Blockchains (Option 2) eine Alternative dar, da jede beteiligte Partei Knoten betreiben kann. Die eingebauten Konsensverfahren stellen sicher, dass jederzeit eine global konsistente Sicht auf die gespeicherten Daten vorliegt und Diskrepanzen sofort erkannt werden können. Der klare Vorteil hierbei ist, dass kein Vertrauen zwischen den Parteien erforderlich ist; im Gegensatz zum Betrieb von verteilten Datenbanken.
Den letzten beiden Optionen ist gemein, dass sie speziell zu betreibende Infrastruktur erfordern. Dies fällt bei öffentlichen Blockchains (Option 1) weg, da weltweit interessierte Personen sich an der Fortschreibung des Systems beteiligen. Hierbei entsteht aber das größte Risiko, denn die Verfügbarkeit ist beileibe nicht garantiert. Auch die Transaktionsgeschwindigkeit und deren Kosten unterliegen starken Schwankungen.
Kostenfaktor Betrieb
Eine klare Einordnung, welche der genannten Möglichkeiten am günstigsten im Betrieb ist, lässt sich nur schwer machen. Betrachten wir beispielsweise private Blockchains: Hyperledger Fabric ist ein komplexes System, welches aus mehreren Knotentypen besteht. Man kann es durchaus in gängiger Container-Infrastruktur wie z.B. Kubernetes betreiben, doch dies benötigt Erfahrung in der Administration.
Bei verschiedenen Cloud-Anbietern kann man auch auf „Managed Blockchain“ zurückgreifen; jedoch stellt das einen Widerspruch in sich dar, da Blockchains ihre Stärken überhaupt nur in einer dezentralen Architektur ausspielen können. Man kommt um eine dedizierte Infrastruktur also nicht herum.
Entscheidet man sich für eine klassische Datenbank als Persistenzschicht, kommt zusätzlicher Aufwand bei der revisionssicheren Archivierung der Einträge hinzu.
Transaktionen & Datenschutz
Der Begriff „Transaktion“ suggeriert, dass Distributed Ledger sich für finanzielle Buchungen eignen. Bei diesen besteht oft ein regulatorisches Interesse, dass sie dauerhaft manipulationssicher vorgehalten werden.
Doch in vielen Organisationen besteht das Datenmodell eben nicht vorrangig aus solchen Ereignissen. Aus dem domänengetrieben Entwurf bekannte Techniken wie Event Sourcing können helfen, in einer fachlichen Domäne geeignete Ereignisse zu identifizieren, die auf einer Blockchain als atomare Transaktionen gespeichert werden können.
Gerade wenn personenbezogene Daten im Spiel sind, muss das Hauptaugenmerk darauf liegen, dass die Rechte der Betroffenen gewahrt werden: schließlich wäre es nicht DSGVO-konform, wenn man Löschanfragen per se ablehnt, weil sie technisch nicht umsetzbar sind. Eine gängige Lösung dafür ist es, Datenfelder wie Namen oder Adressen mit individuellen Schlüsseln verschlüsselt zu speichern und diese Schlüssel separat aufzubewahren. Alternativ kann man auch nur Hashes von Datensätzen in der Blockchain verwalten.
Architektur bedeutet Kompromiss
Auch die Blockchain macht Architekturarbeit nicht überflüssig, denn sie ist bei weitem nicht die Universallösung, als die sie oft angepriesen wird. Im Gegenteil: Distributed Ledger als Persistenz – oder gar Plattform für Smart Contracts – haben spezifische Herausforderungen, wodurch von ihrem Einsatz oftmals abzuraten ist.
Fest steht jedenfalls, dass in dem Bereich viel Innovation passiert. Vergleichbar ist ihre Entwicklung mit den NoSQL-Datenbanken. Früher belächelt, nehmen sie heute einen festen Platz im Werkzeugkasten der Softwareentwicklung ein. Dazu mussten sie ihre Kinderkrankheiten wie mangelhafte Transaktionssemantik zunächst heilen. Ganz ähnlich ist es mit Blockchain-Technologien, die insbesondere bei der Performance noch Nachholbedarf haben.
In der Praxis
Besonders die Geschäftsprozesse im Finanz- und Versicherungssektor sind Blockchain-tauglich. Im „B3i“-Konsortium haben sich Branchengrößen wie Allianz, Munich RE und Generali zusammengeschlossen, um Risikotransfers über eine Distributed-Ledger-Plattform abzuwickeln. 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 Investitionsbank zusammen mit der Banque de France eine 100 Millionen Euro schwere Anleihe aufgelegt, deren Anteile über die Ethereum-Blockchain verkauft worden sind.
Fazit
In verteilten Organisationen, bei denen mehrere voneinander unabhängige Parteien Daten lesen und schreiben, lohnt sich ein Blick auf die verschiedenen Blockchain-Technologien. Man sollte sich aber bewusst sein, dass die Architektur und die Integration mit Umsystemen einiges an Umdenken erfordern.
Dieser Artikel ist ursprünglich am 07.06.2021 auf isaqb.org erschienen. Die Veröffentlichung auf innoq.com erfolgt mit freundlicher Genehmigung des iSAQB.