Schritt 2: Das große Ganze

Softwarearchitektur im Kontext der Blockchain

Dieser Schritt vermittelt nicht nur das Gesamtumfeld, in dem die Blockchain existiert, sondern zeigt auch auf, wo genau sie sich darin befindet. Damit Sie das große Ganze erkennen können, wird im Folgenden das Konzept der Softwarearchitektur vorgestellt und dargelegt, in welcher Beziehung sie zu dem Konzept der Aufteilung eines Systems in Schichten und relevante Aspekte steht. Damit Sie die Bedeutung der Blockchain im Gesamtkontext einordnen können, hebt dieser Schritt die Beziehung zwischen der Blockchain und der Softwarearchitektur hervor. Außerdem wird eine eingängige Definition für den Hauptzweck der Blockchain herausgearbeitet – den zu erkennen ein Grundpfeiler für das Verständnis der Blockchain sowie der weiteren Schritte ist.

Die Metapher

Haben Sie schon mal ein Auto gekauft? Das dürfte auf die meisten von uns zutreffen. Und sollten Sie tatsächlich noch niemals ein Auto gekauft haben, so wissen Sie dennoch gewiss, dass es unterschiedliche Motortechniken gibt, etwa Dieselmotoren, Benzinmotoren oder Elektromotoren. Dieses Beispiel zeigt den Vorgang der Modularisierung, bei dem das Aufteilen in Schichten auf Fahrzeuge angewandt wird. Beim Autokauf führt die Verfügbarkeit verschiedenartiger Motoren zu erstaunlichen Unterschieden zwischen den Wagen. Zwei auf den ersten Blick vollkommen identische Autos können gewaltige Unterschiede bei der Motorleistung und somit auch bei der Fahrleistung aufweisen. Außerdem wirkt sich die Entscheidung für einen bestimmten Motor auf eine Vielzahl weiterer Eigenschaften aus, darunter den Preis, die Betriebskosten, den benötigten Kraftstoff, die Abgasanlage und die Auslegung der Bremsen. Behalten Sie dieses Bild im Hinterkopf, denn es erleichtert Ihnen das Verständnis für die Bedeutung der Blockchain im Gesamtkontext.

Ein Zahlungssystem

Teilen wir nun ein Zahlungssystem in Schichten auf. Tabelle 2.1 enthält einige der Anwenderbedürfnisse sowie einige der nichtfunktionalen Aspekte der Anwendungs- und der Implementierungsschicht.

Schicht	Funktionale Aspekte	Nichtfunktionale Aspekte
Anwendung	Geld einzahlen Geld abheben Geld überweisen Kontostand überwachen	Die grafische Bedienoberfläche sieht schick aus Einfache Bedienung Überweisungen erfolgen schnell Das System hat viele Teilnehmer
Implementierung	?	Rund um die Uhr verfügbar Nicht anfällig für Betrug Integrität erhalten Datenschutz sicherstellen

Tabelle 2.1: Aspekte und Schichten eines Zahlungssystems

Haben Sie das Fragezeichen entdeckt? Hier sind normalerweise Informationen zur Technologie aufgeführt, mit der das System arbeitet. Der betreffende Bereich ist absichtlich nicht ausgefüllt, denn an dieser Stelle entscheiden Sie sich für den »Motor« Ihres Systems. Im nächsten Abschnitt erfahren Sie ein wenig mehr über das, was im Softwarekontext dem Motor entspricht.

Zwei Arten von Softwarearchitektur

Es gibt viele Möglichkeiten, Softwaresysteme zu implementieren. Allerdings betrifft eine der fundamentalen Entscheidungen bei der Systemimplementierung die Architektur, also die Art und Weise, wie die einzelnen Komponenten organisiert sind und miteinander in Beziehung stehen.

Die beiden wichtigsten Architekturansätze für Softwaresysteme sind der zentralisierte und der verteilte (oder auch dezentralisierte) Ansatz. ^[1]

In zentralisierten Softwaresystemen sind die Komponenten um eine zentrale bzw. Hauptkomponente angeordnet und mit dieser verbunden. Im Gegensatz dazu bilden die Komponenten in verteilten Systemen ein Netz aus untereinander verbundenen Komponenten ohne jegliches zentrales Element, das die Koordinierung oder Kontrolle übernimmt.

Abbildung 2.1 veranschaulicht diese gegensätzlichen Architekturen. Die Kreise stehen hierbei für Systemkomponenten (die auch »Knoten« genannt werden), während die Linien die Verbindungen zwischen den Komponenten darstellen. Hier kommt es im Augenblick nicht auf Details an: Was diese Komponenten tun und welche Daten zwischen den Knoten ausgetauscht werden, ist unwichtig. Vielmehr müssen Sie zunächst nur wissen, dass es diese zwei unterschiedlichen Möglichkeiten zum Organisieren von Softwaresystemen gibt. Die Grafik auf der linken Seite von Abbildung 2.1 zeigt eine verteilte Architektur, bei der sämtliche Komponenten untereinander und ohne zentrales Element verbunden sind. Beachten Sie auch, dass keine der Komponenten direkt mit allen anderen Komponenten verbunden ist – allerdings sind sämtliche Komponenten zumindest indirekt miteinander verbunden. Die Darstellung auf der rechten Seite von Abbildung 2.1 veranschaulicht eine zentralisierte Architektur, bei der jede Komponente eine Verbindung mit einer zentralen Komponente aufweist. In diesem Fall sind die Komponenten nicht direkt miteinander verbunden, stattdessen gibt es stets nur eine direkte Verbindung zur zentralen Komponente.

Abb. 2.1: Verteilte (links) und zentralisierte (rechts) Systemarchitektur

Vorteile verteilter Systeme

Die maßgeblichen Vorteile eines verteilten Systems gegenüber Einzelcomputern sind:^[2]

Höhere Rechenleistung
Kostensenkung
Höhere Zuverlässigkeit
Fähigkeit zu natürlichem Wachstum

Höhere Rechenleistung

Die Rechenleistung eines verteilten Systems ist das Ergebnis der kombinierten Rechenleistung aller verbundenen (oder vernetzten) Computer. Daher weisen verteilte Systeme normalerweise mehr Rechenleistung auf als ein einzelner Rechner. Das hat sich auch im direkten Vergleich zwischen verteilten Systemen, die aus relativ schwachen Computern bestehen, und isolierten Supercomputern als wahr erwiesen.

Kostensenkung

Die Preise von handelsüblichen Computern, Speichermodulen, Datenträgern und Netzgeräten sind in den letzten 20 Jahren drastisch gefallen. Da verteilte Systeme aus mehreren Computern bestehen, sind die Einstiegskosten hier höher als bei Einzelcomputern. Allerdings liegen die Kosten für die Fertigung, die Wartung und den Betrieb eines Supercomputers noch immer deutlich über denen für die Fertigung, die Wartung und den Betrieb eines verteilten Systems. Das gilt insbesondere seitdem der Austausch einzelner Computer in einem verteilten System ohne großartige Auswirkungen auf das Gesamtsystem erfolgen kann.

Höhere Zuverlässigkeit

Die gesteigerte Zuverlässigkeit eines verteilten Systems ist der Tatsache geschuldet, dass das gesamte Computernetzwerk auch bei einem Absturz einzelner Rechner weiterarbeiten kann. In einem verteilten System gibt es keinen »Single Point of Failure«, also keinen einzelnen Punkt, bei dem ein Fehler zum Versagen des Gesamtsystems führt. Wenn ein Element ausfällt, können die verbleibenden Elemente dessen Aufgabe übernehmen. Insofern liegt die Zuverlässigkeit bei einem einzelnen Supercomputer normalerweise unter der eines verteilten Systems.

Fähigkeit zu natürlichem Wachstum

Die Rechenleistung eines verteilten Systems ist das Ergebnis der kombinierten Rechenleistung all seiner Bestandteile, daher kann sie im Gesamtsystem durch das Einbinden weiterer Computer erhöht werden. Das bedeutet auch, dass sich die Rechenleistung nach und nach und sehr fein granuliert steigern lässt – und dies ist wiederum wichtig, weil die Anforderungen an die Systemrechenleistung in vielen Unternehmen und Organisationen in ähnlicher Weise zunehmen. Das inkrementelle Wachstum verteilter Systeme steht im Kontrast zur Zunahme der Rechenleistung von Einzelcomputern. Einzelcomputer bieten stets dieselbe Leistung, bis sie durch einen leistungsstärkeren Computer ersetzt werden – und dies führt wiederum zu einer diskontinuierlichen oder sprunghaften Steigerung der Rechenleistung, die Verbraucher der entsprechenden Dienstleistungen nur selten schätzen.

Nachteile verteilter Systeme

Gegenüber Einzelcomputern haben verteilte Systeme aber auch Nachteile:

Höherer Aufwand für die Koordinierung
Höherer Aufwand für die Kommunikation
Abhängigkeit von Netzenwerken
Höhere Programmkomplexität
Sicherheitsbelange

Höherer Aufwand für die Koordinierung

Verteilte Systeme verfügen nicht über zentrale Instanzen, die für die Koordinierung der Mitglieder verantwortlich sind – aus diesem Grund müssen Letztere diese Aufgabe selbst übernehmen. Das Koordinieren der Arbeit bei vielen Mitwirkenden in einem verteilten System ist eine Herausforderung, die Geld und Rechenleistung kostet – Ressourcen, die nicht mehr für die eigentliche Berechnungsaufgabe genutzt werden können. Man spricht hier auch von einem Mehraufwand oder Overhead.

Höherer Aufwand für die Kommunikation

Ohne Kommunikation keine Koordinierung. Daher müssen die Computer, die ein verteiltes System bilden, miteinander kommunizieren. Das geht allerdings nicht ohne ein vorhandenes Kommunikationsprotokoll und das Übermitteln, Empfangen sowie Verarbeiten von Nachrichten – und das wiederum verursacht Kosten und Rechenaufwand. Die dafür verwendeten Ressourcen können nicht mehr für die eigentliche Berechnungsaufgabe genutzt werden. Auch hier spricht man von einem Mehraufwand oder Overhead.

Abhängigkeit von Netzwerken

Jede Art von Kommunikation setzt ein Medium voraus, das die Daten zwischen den Entitäten überträgt, die miteinander kommunizieren. Computer in verteilten Systemen kommunizieren mithilfe von Nachrichten, die über ein Netz verteilt werden. Netze bringen ihre eigenen Herausforderungen und Widrigkeiten mit sich, die sich logischerweise auf die Kommunikation und Koordinierung zwischen den Computern auswirken, die das verteilte System bilden – aber ohne Netz kein verteiltes System, keine Kommunikation und keine Koordinierung zwischen den Knoten. Die Abhängigkeit von Netzen ist also ein notwendiges Übel.

Höhere Programmkomplexität

Zum Lösen eines Berechnungsproblems müssen Programme geschrieben und Software eingesetzt werden. Aufgrund der genannten Nachteile muss jede Software in einem verteilten System auch in der Lage sein, zusätzliche Probleme bezüglich der Koordinierung, Kommunikation und Netznutzung zu lösen – und das führt dann zu einer höheren Komplexität der Software.

Sicherheitsbelange

Die Kommunikation in einem Netz bedeutet, dass für die eigentliche Berechnungsaufgabe extrem wichtige Daten übermittelt und geteilt werden. Die Datenübertragung im Netzwerk wirft jedoch auch Sicherheitsfragen bezüglich des missbräuchlichen Zugriffs vonseiten unseriöser Entitäten bzw. unbefugter Dritter auf. Daher spielt die Sicherheit in jedem verteilten System eine wichtige Rolle. Je weniger Beschränkungen es für den Zugriff auf das Netz gibt, über das die verteilten Knoten miteinander kommunizieren, desto größer sind die Sicherheitsbedenken in Bezug auf das verteilte System.

Verteilte Peer-to-Peer-Systeme

Peer-to-Peer-Netze^[3] repräsentieren eine besondere Art der verteilten Systeme. Sie bestehen aus Einzelcomputern (die auch Knoten genannt werden), die ihre Berechnungsressourcen (wie Verarbeitungsleistung, Speicherkapazität, Daten oder Netzbandbreite) direkt für alle anderen Mitglieder in dem Netzwerk zur Verfügung stellen, ohne dass es eine zentrale Koordinierungsstelle gibt. Die Knoten im Netz sind bezüglich ihrer Rechte und Rollen im System gleich. Außerdem stellen alle Knoten Ressourcen zugleich bereit und verbrauchen sie.

Es gibt interessante Anwendungen für Peer-to-Peer-Systeme, darunter das Filesharing, die Content Distribution und den Datenschutz. Die meisten dieser Anwendungen machen sich eine einfache, aber mächtige Idee zunutze: Die Computer der Anwender werden zu Knoten, die so das gesamte verteilte System bilden. Je mehr Anwender oder Kunden die Software benutzen, desto größer und leistungsfähiger wird das System. Dieses Grundkonzept, seine Folgen und seine Herausforderungen werden in den nächsten Schritten behandelt.

Vermischen von zentralisierten und verteilten Systemen

Zentralisierte und verteilte Systeme sind architektonische Gegenpole – und technische Gegenpole haben die Ingenieure schon immer dazu inspiriert, Hybridsysteme zu konzipieren, in denen die Stärken beider »Elternteile« zur Geltung kommen. Das gilt natürlich auch für zentralisierte und verteilte Systeme. Grundsätzlich gibt es zwei archetypische Möglichkeiten, diese Gegenpole zu vereinen. Zum Verständnis der Blockchain-Anwendungen in der realen Welt ist es wichtig, beide zu kennen. Die eine Option wird als »Zentralität im verteilten System« bezeichnet, die andere als »verteiltes System im Zentrum«.

Die Grafik auf der linken Seite der Abbildung 2.2 zeigt eine Architektur, bei der eine zentrale Komponente in einem verteilten System vorliegt. Auf den ersten Blick sieht es aus, als würden die Komponenten ein verteiltes System bilden, bei genauerem Hinsehen ist aber zu erkennen, dass alle Kreise auch mit dem größeren Kreis in der Mitte verbunden sind. Ein solches System erscheint also nur oberflächlich verteilt – tatsächlich handelt es sich aber um ein zentralisiertes System.

Abb. 2.2: Vermischen der verteilten mit der zentralisierten Architektur

Die Darstellung auf der rechten Seite von Abbildung 2.2 repräsentiert den Gegenansatz. Ein solches System erscheint auf den ersten Blick zentralisiert, weil alle Kreise am äußeren Rand jeweils nur eine direkte Verbindung zu einer größeren, zentralen Komponente aufweisen. Allerdings steckt in der zentralen Komponente selbst ein verteiltes System. Die Komponenten im Außenbereich sind sich möglicherweise noch nicht einmal bewusst, dass in der zentralen Komponente ein verteiltes System vorliegt.

Die Gemeinsamkeit der beiden Ansätze besteht darin, dass ihre wahre Natur nur schwer zu bestimmen ist: Sind sie nun verteilt oder zentralisiert? Vielleicht ist es nicht nötig, diesen Architekturen eindeutige Namen zu geben, aber auf jeden Fall ist es wichtig, auf ihre duale Natur hinzuweisen. Das ist vor allem deswegen von Bedeutung, weil es nicht unbedingt einfach ist, die Zentralität oder die verteilte Natur darin zu erkennen. Ich komme später noch auf diesen Punkt zurück, wenn es um die Kommerzialisierung der Blockchain geht.

Identifizieren verteilter Systeme

Das Aufkommen von Hybridarchitekturen macht es schwierig, verteilte Systeme klar zu identifizieren. Es würde den Rahmen dieses Buchs sprengen, eine allgemein anerkannte Definition für verteilte Systeme aufzustellen, für den Lernpfad ist es jedoch wichtig, in etwa zu wissen, was ein verteiltes System ist und wie es sich von anderen Softwaresystemen unterscheidet. Wenn Sie sich nicht sicher sind, ob ein System verteilt ist, suchen Sie nach einer einzelnen Komponente (zum Beispiel einer Datenbank, einem Namens- oder Anwenderverzeichnis, einer An- oder Abmeldekomponente oder einem Not-Aus-Schalter), mit der sich das gesamte System abschalten lässt. Sollten Sie eine solche Komponente entdecken, handelt es sich nicht um ein verteiltes System.

Der Zweck der Blockchain

Beim Konzipieren eines Softwaresystems muss man sich, ähnlich wie bei der Motorvariante beim Auto, für eine Architektur entscheiden. Dabei kann diese Entscheidung völlig unabhängig von den funktionalen Aspekten der Anwendungsschicht erfolgen. Es ist also möglich, sowohl verteilte als auch zentralisierte Systeme zu erstellen, deren Funktion in der Anwendungsschicht identisch ist. Die Architektur ist lediglich Mittel zum Zweck für die Implementierung eines Systems. Das in Tabelle 2.1 beschriebene Zahlungssystem lässt sich demzufolge ganz nach Belieben als verteiltes oder als zentralisiertes System aufbauen.

Jede Architektur hat ihre eigenen Vor- und Nachteile und verfolgt eine ganz eigene Herangehensweise an die Dinge. Die Entscheidung für eine bestimmte Architektur wirkt sich darauf aus, wie die funktionalen und nichtfunktionalen Aspekte eines Systems umgesetzt werden können. Vor allem gibt es in den beiden Architekturkonzepten sehr unterschiedliche Ansätze zum Sicherstellen der Integrität. Und das ist der Punkt, an dem die Blockchain wichtig wird. Die Blockchain ist ein Tool, um Integrität in verteilten Softwaresystemen zu erzielen – und insofern kann sie als Werkzeug zum Erreichen eines nichtfunktionalen Aspekts der Implementierungsschicht betrachtet werden.

Ausblick

Das Erreichen von Integrität in einem verteilten System ist eine sehr technische Angelegenheit und erscheint vermutlich ein bisschen langweilig. Was diese Problemstellung für viele Menschen dennoch interessant macht, hängt damit zusammen, wozu das verteilte System dient und was für ein zentralisiertes System es ersetzt. Der nächste Schritt erläutert, wie ein Peer-to-Peer-System unsere Welt verändert hat und warum die Blockchain als Tool zum Erreichen von Integrität in verteilten Softwaresystemen ebenfalls das Potenzial hat, die Welt zu verändern.

Zusammenfassung

Die Architektur eines Softwaresystems entscheidet darüber, wie seine Komponenten organisiert sind und zueinander in Beziehung stehen.
Zentralisierte und verteilte Softwarearchitekturen können als Gegenpole betrachtet werden.
Ein verteiltes System besteht aus einer Anzahl unabhängiger Computer, die miteinander über ein Kommunikationsmedium kooperieren, um ein bestimmtes Ziel zu erreichen, ohne dass dabei ein zentralisiertes Element zur Kontrolle oder zur Koordinierung zum Einsatz kommt.
Generell lässt sich sagen, dass ein System, das sich über eine einzelne Komponente vollständig abschalten lässt, kein verteiltes System darstellt – und sei seine Architektur noch so komplex.
Die Blockchain ist ein Teil der Implementierungsschicht in einem verteilten Softwaresystem.
Der Zweck der Blockchain besteht darin, einen bestimmten nichtfunktionalen Aspekt eines verteilten Softwaresystems sicherzustellen, nämlich das Erreichen und Erhalten der Integrität.