Leseprobe. Dies ist das vollständige erste Thema aus dem Kurs Blockchain Professional, mit Audio-Fassung, Grafiken und interaktiven Elementen. Es ist das erste von 16 Themen.
Nach diesem Thema können Sie erklären, worin sich Client-Server-Systeme und Peer-to-Peer-Netzwerke unterscheiden und welche Stärken und Schwächen beide Bauweisen haben. Sie können die drei Netzformen nach Paul Baran auseinanderhalten, das Doppelausgabe-Problem digitalen Geldes beschreiben und einordnen, wie ein verteiltes Kontobuch die zentrale Instanz ersetzt. Und Sie können mit nachvollziehbaren Kriterien beurteilen, für welche Aufgaben Dezentralität ihren Preis wert ist und wann eine zentrale Datenbank die bessere Wahl bleibt.
Zum Hören, auch unterwegs: Die Audio-Fassung erzählt das komplette Thema. Vertiefen Sie das Gehörte anschließend mit den Grafiken, dem interaktiven Überblick und den Checks am Ende dieser Seite.
Client-Server: Bauweise mit Mitte
Fast alles, was Sie täglich im Internet nutzen, folgt demselben Bauplan: dem Client-Server-Modell. Ihr Gerät, der Client, stellt eine Anfrage; ein zentraler Rechner, der Server, beantwortet sie. Der Server hält die Daten, prüft die Berechtigungen und entscheidet über jeden Eintrag. Dieses Muster stammt aus der Forschungswelt der 1970er-Jahre und wurde in den 1980ern mit der Verbreitung der PCs zum Standard der Unternehmens-IT.
Die Stärken des Modells erklären seinen Erfolg. Daten liegen an einer Stelle und lassen sich dort pflegen, sichern und durchsuchen. Es gibt einen Verantwortlichen, der Fehler beheben und Fragen beantworten kann. Und zentrale Systeme sind schnell: Die deutschen Zahlungssysteme verarbeiteten nach Angaben der Deutschen Bundesbank schon 2017 über 75 Millionen Transaktionen pro Geschäftstag.
Die Schwächen sind die Kehrseite derselben Bauweise. Fällt die zentrale Instanz aus, steht alles: 2020 lag TARGET2, das Großbetragszahlungssystem des Eurosystems, stundenlang still, 2024 traf eine Störung das britische Pendant CHAPS; die zweite Fallstudie ordnet beide Ereignisse ein. Zentrale Server sind zudem lohnende Angriffsziele, und wer sie betreibt, kontrolliert den Zugang: Er kann Einträge ändern, Nutzer ausschließen und Regeln einseitig setzen. Alle Beteiligten müssen ihm vertrauen. Diese Vertrauensbindung ist das Konstruktionsprinzip, und über Jahrzehnte gab es dazu keine Alternative.
Drei Netzformen nach Baran
Wie verwundbar eine Netzstruktur ist, wurde bereits 1964 systematisch untersucht, lange vor dem Internet. Der Ingenieur Paul Baran verglich bei der amerikanischen RAND Corporation Kommunikationsnetze daraufhin, ob sie Ausfälle und Angriffe überstehen. Er unterschied drei Formen: das zentralisierte Netz, in dem alle Verbindungen an einem Knoten zusammenlaufen, das dezentralisierte Netz mit mehreren Zentren in einer Hierarchie, und das verteilte Netz, in dem die Knoten gitterförmig untereinander verbunden sind. Sein Befund: Im zentralisierten Netz zerstört der Ausfall des einen Zentrums die gesamte Kommunikation, das verteilte Netz überlebt am meisten Schaden.
Für dieses Thema lohnt eine Begriffsschärfung, die auch die Deutsche Bundesbank so zieht. Verteilt heißt zunächst nur: Daten oder Rechner stehen an mehreren Orten. Eine verteilte Datenbank kann trotzdem einen einzigen Administrator haben, der allein schreiben darf. Dezentral heißt darüber hinaus: Es gibt keine zentrale Kontrollinstanz. Erst diese zweite Eigenschaft unterscheidet ein Blockchain-Netzwerk von der gespiegelten Firmendatenbank, und um sie geht es in diesem Kurs.
Was der Ausfall eines Knotens jeweils bedeutet, zeigt der Vergleich zum Durchklicken:
Jede Verbindung läuft über den einen Mittelpunkt: effizient, wartbar, mit klarer Verantwortung. Fällt das Zentrum aus, steht das gesamte Netz, und sein Betreiber kontrolliert jeden Austausch. Beispiele: eine klassische Bankdatenbank, ein einzelner Firmenserver.
Regionale Knoten bündeln den Verkehr und reichen ihn weiter. Der Ausfall eines Zentrums legt seinen Bereich lahm, der Rest arbeitet weiter. Die Kontrolle bleibt bei wenigen Betreibern. Beispiele: das Bankensystem mit Zentral- und Geschäftsbanken, große E-Mail-Anbieter.
Jeder Knoten hält mehrere Verbindungen, Nachrichten finden viele Wege. Einzelne Ausfälle verkraftet das Netz, eine Kontrollstelle fehlt, und dieselbe Eigenschaft macht Wartung und Änderungen aufwendiger. Beispiele: BitTorrent, das Bitcoin-Netzwerk.
Peer-to-Peer-Netzwerke
Das Gegenmodell zum Client-Server-Muster heißt Peer-to-Peer, kurz P2P: ein Netzwerk aus Gleichrangigen, in dem jeder Teilnehmer beides zugleich ist, Anbieter und Nachfrager. Es gibt keinen dedizierten Server; wer eine Datei lädt, stellt sie zugleich anderen bereit. Massentauglich wurde diese Idee um die Jahrtausendwende durch den Musiktausch, und die Fallstudien am Ende dieses Themas zeichnen die Geschichte dieser Dienste nach.
Technisch reifte das Prinzip schnell. Das 2001 von Bram Cohen entworfene BitTorrent-Protokoll zerlegt Dateien in kleine, per Prüfsumme gesicherte Stücke, die sich Teilnehmer gegenseitig zuliefern; jeder Empfänger wird selbst zur Quelle. Ein Betreiber, an dem Gerichte oder Angreifer ansetzen können, kommt in diesem Verkehr nicht mehr vor. Übrig bleibt ein Protokoll ohne Eigentümer und ohne Betreiber.
Digitales Geld und die Doppelausgabe
Digitale Information lässt sich beliebig und perfekt kopieren. Für Musikdateien ist das die Stärke des Mediums. Eine digitale Münze, die ihr Besitzer zweimal ausgeben kann, ist dagegen wertlos. Fachleute nennen das das Doppelausgabe-Problem (Double Spending). Jedes digitale Geldsystem muss sicherstellen, dass dieselbe Einheit nur einmal den Besitzer wechselt.
Die klassische Lösung ist ein zentraler Kontoführer. Die Bank prüft jede Zahlung gegen ihr Register, und was dort verbucht ist, gilt. Das funktioniert und bindet das Geldsystem an die zentrale Instanz samt Vertrauensfrage, um die es in diesem Thema geht. Digitales Bargeld nach diesem Muster wurde ab 1989 gebaut und scheiterte. In einem offenen Netz aus Gleichrangigen galt die Aufgabe dagegen als unlösbar, denn ohne Zentrale konnte niemand verbindlich feststellen, welche Kopie einer Münze die echte ist.
Am 31. Oktober 2008 kündigte eine bis heute unbekannte Person oder Gruppe unter dem Namen Satoshi Nakamoto auf einer Kryptografie-Mailingliste ein Konzeptpapier an, dessen Titel das Programm war: „Bitcoin: A Peer-to-Peer Electronic Cash System“. Der Vorschlag: Alle Teilnehmer führen das Kontobuch gemeinsam. Jede Transaktion wird mit Zeitstempel in eine fortlaufende Kette von Datenblöcken eingetragen, die alle Knoten in Kopie halten und gemeinsam fortschreiben. Was in dieser Kette steht, hat das ganze Netzwerk beglaubigt, und eine bereits ausgegebene Münze lässt sich kein zweites Mal ausgeben, weil jeder Knoten ihre Geschichte kennt.
Ein solches gemeinsames Register heißt verteiltes Kontobuch, englisch Distributed Ledger; die amerikanische Standardisierungsbehörde die amerikanische Standardisierungsbehörde NIST beschreibt Blockchains als manipulationserkennbare und manipulationsresistente digitale Kontobücher, in der Regel ohne zentrale Autorität. Der Aufbau der Blockkette folgt im nächsten Thema, die Einigung der Knoten im Thema Konsensmechanismen.
Wann sich Dezentralität lohnt
Dezentralität hat einen Preis. Tausende Knoten, die dieselben Daten speichern und jede Änderung gemeinsam beglaubigen, brauchen mehr Speicher und mehr Zeit als eine gepflegte zentrale Datenbank; die Bundesbank hielt schon 2017 fest, dass verteilte Kontobücher für den Hochvolumen-Zahlungsverkehr zentralen Systemen unterlegen sind. Wer Dezentralität wählt, kauft Widerstandsfähigkeit und Unabhängigkeit und bezahlt mit Effizienz. Zu entscheiden ist deshalb, ob der Verzicht auf die zentrale Instanz den Aufwand wert ist.
Dafür gibt es erprobte Prüffragen. Das oft zitierte Entscheidungsschema der Forscher Karl Wüst und Arthur Gervais von 2018 fragt: Muss überhaupt ein gemeinsamer Datenbestand geführt werden? Schreiben mehrere, voneinander unabhängige Parteien? Und vor allem: Steht eine vertrauenswürdige Instanz zur Verfügung, der alle folgen können? Lautet die letzte Antwort Ja, ist die zentrale Datenbank fast immer die bessere Wahl, schneller und günstiger. Erst wenn mehrere Parteien ohne gemeinsames Vertrauen und ohne akzeptierten Mittelsmann auf einen Datenbestand schreiben, spielt ein verteiltes Kontobuch seine Stärke aus. Auch die Standardisierungsbehörde NIST warnt: Blockchain ist kein Allheilmittel, die richtige Frage lautet, wo die Technik hilft, und keine Aufgabe gehört in das Blockchain-Schema gepresst.
Vertiefung: Fallstudien
Fallstudie 1: Napster und Gnutella
1999 bis 2001
Im Juni 1999 startete Napster den Musiktausch von Rechner zu Rechner und wuchs auf 26,4 Millionen Nutzer im Februar 2001. Vollständig dezentral war der Dienst zu keinem Zeitpunkt: Welche Datei bei welchem Teilnehmer lag, verzeichnete ein zentraler Indexserver der Firma. Dort setzte die Musikindustrie an. Im Verfahren A&M Records gegen Napster bestätigte das Berufungsgericht im Februar 2001 die einstweilige Verfügung im Kern, im Juli 2001 stellte Napster den Betrieb ein: Über den Index ließ sich der gesamte Dienst abschalten. Anders das Protokoll Gnutella, das im März 2000 erschien und ohne jede zentrale Komponente auskam. Der Eigentümer AOL nahm das Programm einen Tag nach Veröffentlichung offline, doch das Protokoll war in der Welt und ließ sich niemandem mehr wegnehmen; BitTorrent führte diese Linie ab 2001 fort.
Die Lehre: Angreifbar ist ein Netzwerk dort, wo es zentral ist. Napster fiel über seinen Index, Gnutella und BitTorrent überlebten als reine Protokolle ohne Betreiber. Auf dieser Beobachtung baut die Blockchain-Idee auf: Was keinen Mittelpunkt hat, lässt sich weder abschalten noch übernehmen.
Fallstudie 2: Die Ausfälle von TARGET2 und CHAPS
Oktober 2020 und Juli 2024
Am 23. Oktober 2020 fiel TARGET2 aus, das System, über das die Zentralbanken des Euroraums Großbeträge abwickeln. Ein Softwarefehler in einem Netzwerkgerät legte den Zahlungsverkehr für fast 10 Stunden lahm; die Europäische Zentralbank ordnete anschließend eine unabhängige Untersuchung an. Im Juli 2024 traf es das britische Gegenstück CHAPS der Bank of England: Eine Störung verzögerte zeitkritische Großzahlungen, darunter Immobilienkäufe, bis der Dienst am selben Tag wiederhergestellt war. Beide Systeme sind hochprofessionell betrieben und gelten zu Recht als zuverlässig, und doch gilt in beiden Fällen: Fällt die zentrale Instanz aus, ruht der gesamte Verkehr, so gut die Redundanz dahinter auch sein mag.
Die Lehre: Auch eine sorgfältig betriebene zentrale Infrastruktur bleibt ein einzelner Ausfallpunkt. Ein verteiltes Netzwerk erkauft sich mit höherem Aufwand die Eigenschaft, die Baran 1964 nachwies: Es gibt keinen einen Ort, dessen Ausfall alles anhält.
Fallstudie 3: DigiCash und das zentrale digitale Bargeld
1989 bis 1998
Der Kryptograf David Chaum gründete 1989 die Firma DigiCash, deren „ecash“ Zahlungen mit beachtlicher Privatsphäre ermöglichte, technisch seiner Zeit weit voraus. Das Doppelausgabe-Problem löste ecash auf klassischem Weg: Jede Münze musste bei jeder Zahlung in Echtzeit von der ausgebenden Bank geprüft werden. Damit hing das System an zentralen Partnern, brauchte Banken, die mitmachten, und einen Betreiber, der durchhielt. Die Verbreitung blieb gering, 1998 meldete DigiCash Konkurs an. Ein Jahrzehnt später wählte das Bitcoin-Konzept den entgegengesetzten Weg: ein Kontobuch, das alle Teilnehmer gemeinsam führen, ganz ohne Kontoführer.
Die Lehre: DigiCash scheiterte an der Abhängigkeit von zentralen Trägern, die Kryptografie funktionierte. Digitales Bargeld mit Bank im Rücken blieb abschaltbar wie Napster; erst das gemeinsam geführte Kontobuch machte den Verzicht auf die Zentrale möglich.
- Client-Server ist das Standardmodell des Internets: effizient, wartbar, mit klarer Verantwortung, und zugleich an eine Mitte gebunden, die Ausfallpunkt und Kontrollstelle zugleich ist (TARGET2 2020, CHAPS 2024)
- Paul Baran unterschied 1964 zentralisierte, dezentralisierte und verteilte Netze; verteilte Gitter überstehen Ausfälle am besten. Verteilt heißt nur „an mehreren Orten“, dezentral heißt zusätzlich „ohne zentrale Kontrollinstanz“
- In Peer-to-Peer-Netzen ist jeder Teilnehmer Anbieter und Nachfrager zugleich. Die Geschichte von Napster (zentraler Index, per Gericht beendet) und Gnutella/BitTorrent (reine Protokolle, nicht abschaltbar) zeigt: Angreifbar ist die zentrale Komponente
- Digitale Daten sind beliebig kopierbar, deshalb braucht digitales Geld einen Schutz vor Doppelausgabe. Zentrale Kontoführer lösen das Problem um den Preis der Vertrauensbindung (DigiCash 1989 bis 1998); das Bitcoin-Konzept von 2008 löst es erstmals ohne Mitte, über ein von allen Knoten gemeinsam geführtes verteiltes Kontobuch
- Dezentralität wird mit Effizienz bezahlt. Nach Wüst/Gervais (2018) lohnt eine Blockchain erst, wenn mehrere Parteien ohne vertrauenswürdige Instanz gemeinsam schreiben; gibt es die vertrauenswürdige Instanz, bleibt die zentrale Datenbank die bessere Wahl
Prüfen Sie sich selbst
Worin unterscheiden sich „verteilt“ und „dezentral“?
Verteilt beschreibt nur den Ort der Daten: mehrere Rechner statt einem, auch mit einem einzigen Administrator. Dezentral kommt erst hinzu, wenn keine zentrale Instanz das Netz kontrolliert. Eine gespiegelte Firmendatenbank ist verteilt; ein Blockchain-Netzwerk ist beides.
Aus welchem Grund endete Napster, während BitTorrent weiterlief?
Napster führte den Suchindex auf firmeneigenen Servern, und gegen diese Firma konnte ein Gericht vollstrecken. BitTorrent ist ein Protokoll ohne Betreiber; einzelne Tracker und Indexseiten lassen sich abschalten, das Protokoll selbst nicht.
Was besagt das Doppelausgabe-Problem?
Digitale Einheiten lassen sich perfekt kopieren. Ein digitales Geldsystem muss deshalb verhindern, dass dieselbe Einheit mehrfach ausgegeben wird. Ohne Schutzmechanismus kann niemand unterscheiden, welche Kopie einer Münze gültig ist.
Wie lösten Systeme vor Bitcoin die Doppelausgabe, und was war der Preis?
Ein zentraler Kontoführer prüfte jede Zahlung gegen sein Register, bei DigiCash die ausgebende Bank in Echtzeit. Der Preis war die Bindung an diese Mitte: Vertrauen in den Betreiber, Abhängigkeit von seinem Fortbestand, Abschaltbarkeit.
Welche Idee steckt hinter dem verteilten Kontobuch?
Alle Knoten halten eine Kopie desselben Registers und schreiben es gemeinsam fort. Beglaubigt wird ein Eintrag vom Netzwerk statt von einer Zentrale; eine bereits ausgegebene Einheit fällt beim Abgleich mit dem gemeinsamen Register sofort auf.
Wann ist eine zentrale Datenbank die bessere Wahl?
Sobald eine vertrauenswürdige Instanz existiert, der alle Beteiligten folgen können, oder nur eine Partei schreibt. Dann liefert die zentrale Lösung dasselbe Ergebnis schneller und günstiger; das Entscheidungsschema von Wüst und Gervais führt in diesen Fällen ausdrücklich zur Datenbank.
- Beschreiben Sie das Client-Server-Modell mit seinen Stärken und Schwächen.
- Erläutern Sie die drei Netzformen nach Baran und ordnen Sie je ein Beispiel zu.
- Grenzen Sie die Begriffe verteilt und dezentral voneinander ab.
- Erklären Sie am Vergleich von Napster und BitTorrent, an welcher Stelle Netzwerke angreifbar sind.
- Definieren Sie das Doppelausgabe-Problem und stellen Sie die zentrale und die dezentrale Lösung gegenüber.
- Nennen Sie die Prüffragen, mit denen sich entscheiden lässt, ob eine Blockchain die passende Lösung ist.
Wer diese Fragen frei beantworten kann, versteht, welches Problem die Blockchain löst und wo ihre Grenzen liegen.
- Paul Baran: „On Distributed Communications“ – das RAND-Memorandum von 1964 mit den drei Netzformen, der Urtext der Verteiltheits-Debatte. Englisch, kostenlos bei rand.org
- Satoshi Nakamoto: „Bitcoin: A Peer-to-Peer Electronic Cash System“ – das Konzeptpapier von 2008; Abstract und Einleitung genügen für dieses Thema. Englisch, kostenlos; deutsche Übersetzungen frei verfügbar
- Deutsche Bundesbank: „Distributed-Ledger-Technologien im Zahlungsverkehr und in der Wertpapierabwicklung“ – Monatsbericht September 2017; nüchterne deutsche Einordnung von DLT gegenüber zentralen Systemen. Deutsch, kostenlos als PDF
- Karl Wüst, Arthur Gervais: „Do you need a Blockchain?“ – der Aufsatz von 2018 mit dem Entscheidungsschema dieses Themas. Englisch, kostenlos als Preprint
Wissens-Check
Dezentrale Netzwerke
Das war Thema 1 von 16
Der vollständige Kurs führt weiter über Netzwerke und Konsens, Smart Contracts und Token bis zu Anwendung, Sicherheit, Prüfung und digitalem Zertifikat.
Blockchain Professional ansehen