Dezentrale Geldschöpfung und das Konsensproblem von b-money

Dezentrale Geldschöpfung und das Konsensproblem von b-money

Wie b-money Kontostände öffentlich bestätigt, dezentrale Geldschöpfung an Rechenaufgaben koppelt und Transaktionen nur bei Einigung aller Teilnehmer zustande kommen.

Kontostände öffentlich bestätigen

Eine Datenbank, die niemandem allein gehört, klingt zunächst widersprüchlich. Wenn keine zentrale Instanz die Kontostände verwaltet, muss jeder Teilnehmer selbst prüfen können, ob die Zahlen stimmen. Genau hier setzt das b-money Konsens-Modell an, das Wei Dai 1998 skizzierte.

Die Idee ist einfach formuliert: Alle Teilnehmer führen eine eigene Kopie der Kontostände und veröffentlichen regelmäßig ihren Stand. Stimmen die Meldungen überein, gilt der Kontostand als bestätigt. Weicht eine Meldung ab, muss das Netzwerk klären, welche Version korrekt ist. Erst wenn genügend Teilnehmer denselben Stand melden, gilt er als gesichert.

An die Stelle von Bank oder Zahlungsdienstleister als Kontrollinstanz tritt diese öffentliche Bestätigung. Vertrauen entsteht nicht durch eine Institution, sondern durch den Abgleich vieler unabhängiger Kopien. Das war 1998 ein ungewöhnlicher Gedanke, weil digitales Geld bis dahin fast immer einen Betreiber im Zentrum hatte.

Ohne diesen laufenden Abgleich könnte jeder Teilnehmer behaupten, über beliebig viel Guthaben zu verfügen. Die regelmäßige Veröffentlichung macht solche Behauptungen überprüfbar und damit wertlos.

Dezentrale Geldschöpfung durch Rechenaufgaben

Ohne Zentralbank stellt sich sofort die Frage, wer neues Geld schöpfen darf und nach welcher Regel. Wei Dais Antwort war radikal: Dezentrale Geldschöpfung sollte an eine Rechenaufgabe gekoppelt werden, die jeder Teilnehmer lösen kann, aber niemand beliebig oft.

Wer die Aufgabe löst, erschafft eine festgelegte Menge Geld und veröffentlicht das Ergebnis zusammen mit dem Beweis der Rechenarbeit. Das Original-Dokument beschreibt dieses Verfahren im Detail (b-money-Papier) und macht deutlich, dass Aufwand die einzige Eintrittskarte zur Geldschöpfung sein sollte.

Im Kern der dezentralen Geldschöpfung bei b-money steht diese Kopplung an Rechenaufwand. Sie ersetzt eine politische Entscheidung durch eine mathematische Regel. Niemand kann per Beschluss mehr Geld schöpfen, als die Rechenaufgabe erlaubt.

Damit die dezentrale Geldschöpfung nicht zu Chaos führt, muss jede neu geschöpfte Menge ebenfalls veröffentlicht und von den anderen Teilnehmern akzeptiert werden. Erst die Bestätigung durch das Netzwerk macht aus einer gelösten Rechenaufgabe tatsächlich neues Geld.

Ohne Einigung keine Transaktion

Eine Transaktion von A zu B klingt banal, verlangt aber in einem dezentralen System einiges an Koordination. Bevor B das Geld akzeptiert, prüfen die übrigen Teilnehmer, ob A tatsächlich über ausreichend Guthaben verfügt.

Diese Prüfung läuft über einen Hash der Transaktion, der an das Netzwerk verteilt wird. Jeder Teilnehmer vergleicht den Hash mit seiner eigenen Kopie der Kontostände und meldet Zustimmung oder Widerspruch zurück.

Kommt keine Einigung zustande, wird die Transaktion schlicht verworfen. Es gibt keine übergeordnete Instanz, die im Streitfall entscheidet. Das Konsensprinzip von b-money macht die Zustimmung der Teilnehmer zur Voraussetzung für jede Bewegung von Geld.

Dieses Prinzip war ein früher Entwurf für das, was später als Konsensmechanismus bekannt wurde. Die Grundfrage blieb dieselbe: Wie einigen sich Fremde ohne Vermittler auf einen gemeinsamen Kontostand.

Wie berichteten wir über Das b-money Protokoll: Geld durch Rechenaufwand.

Das b-money Protokoll: Geld durch Rechenaufwand

Das b-money Protokoll: Geld durch Rechenaufwand

Wei Dais b-money Protokoll von 1998 beschreibt, wie Teilnehmer über eigene Datenbanken und Rechenaufwand dezentral Geld erzeugen, ganz ohne Zentralbank.

Eigene Datenbank für jeden Teilnehmer

Das b-money Protokoll entstand 1998, als der Informatiker Wei Dai einen Vorschlag für ein digitales Geldsystem auf einer Cypherpunk-Mailingliste veröffentlichte. Anders als bei einer Bank mit zentralem Kontobuch sollte jeder Teilnehmer eine eigene, vollständige Datenbank führen, in der alle Kontostände des Netzwerks vermerkt sind.

In dieser Datenbank steht, wie viele Geldeinheiten jeder Teilnehmer im Netzwerk besitzt. Findet eine Transaktion statt, tragen alle Teilnehmer die Änderung gleichzeitig in ihre eigene Kopie ein. Niemand muss einer einzelnen Instanz vertrauen, weil jeder die Kontostände selbst nachvollziehen und prüfen kann.

Diese Idee einer verteilten Buchführung ist einer der Kerngedanken, die das b-money Protokoll später für die Entwicklung digitalen Geldes so bedeutsam gemacht haben. Wer Geld senden wollte, musste seine Anweisung an alle anderen Teilnehmer verbreiten, damit jeder seine Datenbank aktualisieren konnte.

Geldschöpfung im b-money Protokoll

Neben der Kontoführung beschreibt das b-money Protokoll auch, wie neues Geld überhaupt entsteht. Die Grundregel ist einfach: Ein Teilnehmer löst ein rechenintensives Problem, das bisher ungelöst war, und veröffentlicht die Lösung samt Nachweis gegenüber den anderen Teilnehmern im Netzwerk.

Die Menge der neu erzeugten Geldeinheiten richtet sich dabei nach den Kosten des Rechenaufwands, der für die Lösung nötig war. Wer mehr Rechenleistung investiert, erzeugt mehr Geld. Wer weniger investiert, entsprechend weniger. Dieser Mechanismus sorgt für eine dezentrale Geldschöpfung, ohne dass eine Zentralbank oder ein Emittent über die Menge entscheidet.

Für das b-money Protokoll war das ein Weg, Knappheit ohne Institution herzustellen. Die Kosten der Rechenarbeit setzen der Geldmenge eine natürliche Grenze, da niemand beliebig viel Rechenleistung kostenlos zur Verfügung hat. Details zum ursprünglichen Vorschlag lassen sich im Originaltext von Wei Dai nachlesen, den er 1998 veröffentlichte.

Server und Sicherheiten als zweiter Weg

Wei Dai skizzierte im b-money Protokoll noch eine zweite Variante, weil die erste in der Praxis kaum umsetzbar war. Alle Teilnehmer müssten dafür permanent online sein und jede Transaktion jedes anderen Teilnehmers verarbeiten, was bei vielen Nutzern schnell an Grenzen stößt.

In der zweiten Variante übernehmen ausgewählte Teilnehmer mit eigenen Servern die Verarbeitung der Transaktionen. Damit diese Server nicht betrügen, mussten sie zuvor Geld als Sicherheit hinterlegen, die bei nachweisbarem Fehlverhalten verloren ging und an ehrliche Teilnehmer verteilt wurde.

Im Ergebnis blieb der Grundgedanke des b-money Protokolls erhalten: Jeder Teilnehmer kann durch eigene Arbeit Geld erzeugen, unabhängig davon, ob er über die einfache oder die serverbasierte Variante am Netzwerk teilnimmt. Beide Wege verzichten auf eine zentrale Ausgabestelle.

Wei Dais Entwurf blieb ein theoretisches Papier und wurde nie vollständig umgesetzt. Dennoch griffen spätere Konzepte zentrale Bausteine des b-money Protokolls auf, etwa die Kopplung von Geldschöpfung an nachweisbaren Rechenaufwand. Zuvor berichteten wir über Digitale Knappheit: BitGold und der Arbeitsnachweis.

Digitale Knappheit: BitGold und der Arbeitsnachweis

Digitale Knappheit: BitGold und der Arbeitsnachweis

Wie Hal Finneys BitGold-Konzept mit Zeitstempeln erstmals digitale Knappheit und begrenzte Produktionskosten für digitale Token nachweisbar machte.

Hal Finney und der wiederverwendbare Arbeitsnachweis

HashCash von Adam Back löste das Spam-Problem, hatte aber eine Schwäche: Jeder berechnete Arbeitsnachweis war nur einmal verwendbar und danach wertlos. Der Kryptograf Hal Finney griff diese Lücke 2004 auf und veröffentlichte ein System namens RPOW, kurz für Reusable Proofs of Work. Es sollte den einmaligen Arbeitsnachweis in ein wiederverwendbares, handelbares Gut verwandeln.

Die Idee dahinter: Ein einmal berechneter Arbeitsnachweis sollte nicht verfallen, sondern als Token weitergereicht und erneut eingelöst werden können. Damit näherte sich Finney einem Konzept, das später als BitGold bekannt wurde und digitale Knappheit erstmals technisch greifbar machte.

Entscheidend war, dass der Code für die Ausgabe und Prüfung der Token nicht bei Finney selbst lag, sondern auf einem entfernten, für Dritte einsehbaren Server lief. Niemand, auch nicht der Betreiber, sollte die Ausgabe neuer Token nach Belieben manipulieren können. Diese Kontrolle durch Dritte war für ein digitales System dieser Zeit neu.

Zeitstempel als Nachweis digitaler Knappheit

Ein zentrales Element von BitGold war der Zeitstempel. Jeder Arbeitsnachweis wurde mit dem Zeitpunkt seiner Berechnung versehen, sodass sich im Nachhinein rekonstruieren ließ, wann ein Token entstanden ist und welcher Schwierigkeitsgrad zu diesem Zeitpunkt galt. Der BitGold-Zeitstempel verband so Herstellungszeit und Aufwand in einem einzigen Datensatz.

Diese Verknüpfung von Zeitstempel und Schwierigkeitsgrad war mehr als eine technische Fußnote. Sie erlaubte es, den tatsächlichen Rechenaufwand hinter einem digitalen Token nachzuweisen, ohne einer zentralen Stelle vertrauen zu müssen. Wer den Zeitstempel prüfte, konnte die Produktionskosten des Tokens gut einschätzen.

Damit rückte digitale Knappheit in greifbare Nähe: Ein Token war nicht mehr beliebig kopierbar und wertlos, sondern an einen nachweisbaren, zeitlich verorteten Aufwand gebunden. Für rein digitale Güter war das ein neuer Ansatz, denn bis dahin ließ sich digitale Knappheit kaum glaubhaft herstellen.

Begrenzte Inflation durch Produktionskosten

Aus dem Zeitstempel-Mechanismus ergab sich ein weiterer Effekt: Weil sich Herstellungszeitpunkt und Schwierigkeitsgrad jedes Tokens nachvollziehen ließen, konnte auch der Zufluss neuer Token erstmals über nachweisbare Produktionskosten begrenzt werden.

Wollte jemand viele Token gleichzeitig erzeugen, musste er auch entsprechend viel Rechenaufwand tatsächlich erbringen. Ein Ausweichen auf billigere Abkürzungen ließ sich über den Zeitstempel und den dokumentierten Schwierigkeitsgrad erkennen. So entstand ein System, in dem Inflation nicht durch Regeln allein, sondern durch echten, nachprüfbaren Aufwand begrenzt war.

BitGold selbst wurde nie als laufendes Netzwerk umgesetzt und blieb ein Konzept auf dem Papier und in Finneys Code-Entwürfen. Spätere Systeme griffen die zugrunde liegenden Bausteine auf: Arbeitsnachweis, Zeitstempel und darüber begrenzte Produktionskosten, um digitale Knappheit ohne zentrale Ausgabestelle zu erzeugen.

Bereits berichteten wir über den HashCash-Arbeitsnachweis: Adam Backs Antwort auf Spam.

HashCash Arbeitsnachweis: Adam Backs Antwort auf Spam

HashCash Arbeitsnachweis: Adam Backs Antwort auf Spam

1997 entwickelte Adam Back mit HashCash ein System gegen E-Mail-Spam, das Rechenleistung als Nachweis nutzte und den Proof-of-Work Ursprung markiert.

Adam Backs Kampf gegen E-Mail-Spam

1997 veröffentlichte der britische Kryptograf Adam Back eine Idee, die auf den ersten Blick nichts mit Geld zu tun hatte. Er suchte eine Lösung gegen ein Problem, das damals viele Nutzer des frühen Internets nervte: E-Mail-Spam, der mit wachsender Netzverbreitung rasant zunahm.

Back stellte sein Konzept am 28. März 1997 auf der Cypherpunks-Mailingliste vor. Der Grundgedanke war einfach: Wer eine Nachricht verschicken will, muss zuvor eine kleine Rechenaufgabe lösen. Für einen einzelnen Absender kostet das kaum Zeit, für Massenversender mit Millionen Nachrichten wird der Aufwand schnell unpraktikabel.

Back nannte seine Lösung HashCash. Der Name verweist auf zwei Dinge zugleich: die kryptografische Hashfunktion, die für die Berechnung genutzt wird, und das Bild von Cash, also Bargeld, das erst durch Aufwand entsteht. Anders als klassisches Geld lässt sich dieser Aufwand jedoch von jedem beliebigen Rechner aus erbringen.

Rechenleistung als HashCash Arbeitsnachweis

Technisch funktioniert der HashCash Arbeitsnachweis über sogenannte partielle Hash-Kollisionen. Ein Absender muss einen Wert finden, dessen Hash mit einer bestimmten Anzahl von Nullen beginnt. In der ursprünglichen Version legte Back die Schwelle auf 20 Bit fest, was im Schnitt rund eine Million Rechenschritte erfordert.

Das Prinzip lässt sich mit einer Lotterie vergleichen: Es gibt keinen schnelleren Weg zum passenden Wert als einfaches Ausprobieren. Diese Eigenschaft macht den HashCash Arbeitsnachweis überprüfbar mit einem einzigen Rechenschritt, aber teuer in der Erzeugung. Details dazu beschrieb Back später in seinem Paper, das die Methode formal ausarbeitet.

Für E-Mails bedeutete das: Jede Nachricht trägt einen Stempel, der beweist, dass CPU-Zeit investiert wurde. Ein Mailserver kann diesen Stempel in Millisekunden prüfen und Nachrichten ohne gültigen HashCash Arbeitsnachweis automatisch aussortieren.

Für Privatnutzer mit wenigen E-Mails pro Tag blieb der Aufwand unbemerkbar. Für Spam-Versender, die auf Masse angewiesen sind, summierte sich die Rechenzeit dagegen zu einem echten Hindernis.

Vom Spamschutz zum Proof-of-Work

Was als Werkzeug gegen lästige Werbemails begann, erwies sich als Vorlage für ein deutlich größeres Konzept. Der Proof-of-Work Ursprung liegt genau in dieser Idee: Zugang oder Ressourcen werden an nachweisbare Rechenarbeit gekoppelt, statt an Vertrauen oder eine zentrale Instanz.

Spätere Systeme griffen dieses Muster auf und übertrugen es auf andere Probleme, etwa auf die Frage, wie ein Netzwerk ohne zentrale Kontrolle Einigkeit über die Reihenfolge von Transaktionen herstellen kann. Der Grundmechanismus blieb dabei erstaunlich nah am Original: Rechenaufwand als Filter, der billig zu prüfen und teuer zu fälschen ist.

Bemerkenswert ist, wie lange dieser Gedanke unbemerkt blieb, bevor er zur Grundlage eines globalen Netzwerks wurde. Back selbst hat die Idee nie patentiert, sondern frei zur Verfügung gestellt.

Wie stark dezentrale Systeme schon vor diesem Schritt experimentierten, zeigten frühere Netzwerke abseits von HashCash. So berichteten wir über Dezentrale Netzwerke vor Bitcoin: Napster, Gnutella, Tor.

Dezentrale Netzwerke vor Bitcoin: Napster, Gnutella, Tor

Napster, Gnutella und Tor zeigten schon vor Bitcoin, wie dezentrale Netzwerke ohne zentrale Kontrollstelle funktionieren.

Napster und Gnutella als Filesharing-Pioniere

1999 ging Napster online und zeigte einem Massenpublikum zum ersten Mal, wie dezentrale Netzwerke funktionieren können. Nutzer tauschten MP3-Dateien direkt untereinander aus, ohne dass die Musik selbst über einen zentralen Server lief.

Napster nutzte dafür eine Mischform: Eine zentrale Datenbank verwaltete, wer welche Datei besitzt. Der eigentliche Datentransfer fand aber als Peer-to-Peer-Technologie zwischen den Rechnern der Nutzer statt. Der Dienst wuchs rasant und zählte auf seinem Höhepunkt rund 80 Millionen registrierte Nutzer weltweit.

Genau diese zentrale Datenbank wurde Napster zum Verhängnis. Da eine einzelne Stelle existierte, die abgeschaltet werden konnte, gelang es Rechteinhabern per Klage, den Dienst 2001 stillzulegen.

Gnutella, das im Jahr 2000 startete, zog daraus die technische Konsequenz und baute dezentrale Netzwerke ganz ohne zentralen Server. Jeder Teilnehmer war zugleich Client und Server und leitete Suchanfragen an andere Teilnehmer weiter.

Weil es bei Gnutella keine zentrale Anlaufstelle gab, ließ sich das Netzwerk nicht durch eine einzige Klage oder Abschaltung stoppen. Diese Erfahrung prägte spätere Systeme, die bewusst ohne verwundbaren Mittelpunkt entworfen wurden.

Tor und die Verschleierung von Identität

2002 folgte mit Tor ein weiteres dezentrales Netzwerk, das allerdings nicht Dateien, sondern Identitäten schützen sollte. Tor verschleiert die IP-Adresse eines Nutzers, indem der Datenverkehr über mehrere Knoten geleitet wird.

Diese Knoten werden von Freiwilligen auf der ganzen Welt betrieben. Technische Details beschreibt das Tor Project auf seiner offiziellen Seite. Jede Verbindung wird dabei mehrfach verschlüsselt, sodass kein einzelner Knoten die komplette Route kennt.

Ein Knoten weiß nur, von wem er ein Datenpaket erhalten hat und an wen er es weiterleitet, nicht aber den ursprünglichen Absender oder das endgültige Ziel. So entsteht Anonymität, ohne dass eine zentrale Instanz Nutzer identifizieren oder sperren könnte.

Damit stand Tor für einen zweiten Anwendungsfall dezentraler Netzwerke: Es ging nicht mehr nur darum, Daten auszutauschen, sondern darum, den Zugriff auf ein Netzwerk gegen Zensur und Überwachung abzusichern.

Dezentrale Netzwerke als technisches Vorbild

Napster, Gnutella und Tor zeigen, wie sich dezentrale Netzwerke innerhalb weniger Jahre technisch weiterentwickelten. Napster bewies, dass Millionen Nutzer direkt miteinander Dateien austauschen können, scheiterte aber an seiner zentralen Schwachstelle.

Gnutella entfernte diese Schwachstelle und bewies, dass ein Netzwerk auch ganz ohne Mittelpunkt funktioniert. Tor ergänzte das Prinzip um den Schutz der Identität der Teilnehmer.

Bitcoin griff wenige Jahre später genau diese drei Bausteine auf: viele gleichberechtigte Knoten, keine zentrale Stelle, die abgeschaltet werden kann, und ein Netzwerk, das seine Teilnehmer nicht öffentlich preisgibt. Ohne die technischen Vorarbeiten dieser frühen Projekte wäre der Entwurf eines Zahlungsnetzwerks ohne zentrale Bank kaum denkbar gewesen.

Über die Cypherpunk-Bewegung und den Weg zur Dezentralität berichteten wir bereits.

Die Cypherpunk Bewegung und der Weg zur Dezentralität

Die Cypherpunk Bewegung und der Weg zur Dezentralität

Nach dem Ende von DigiCash lebte die Idee digitalen Geldes ohne zentrale Kontrolle weiter. Die Cypherpunk Bewegung trug sie über ihre Mailingliste in viele Richtungen weiter, getragen vom Gedanken radikaler Dezentralität.

Nach DigiCash leben die Ideen weiter

Der Konkurs von DigiCash im Jahr 1998 markierte das Ende eines der ambitioniertesten Versuche, digitales Bargeld auf zentralisierter Basis anzubieten. Die zugrunde liegende Vision blieb trotzdem bestehen. Die Cypherpunk Bewegung, aus der viele der beteiligten Kryptografen stammten, sah in diesem Scheitern keinen Grund aufzugeben.

Stattdessen wurde das Ende von DigiCash als Bestätigung gelesen: Sobald eine einzelne Firma oder ein einzelner Server im Zentrum eines Zahlungssystems steht, hängt das gesamte System an dessen Fortbestand. Fällt dieser eine Punkt aus, fällt das System mit ihm. Wer digitales Geld dauerhaft unabhängig von einzelnen Institutionen betreiben wollte, musste also einen anderen Weg suchen.

Aus dieser Lehre heraus verschob sich der Fokus innerhalb der Cypherpunk Bewegung weg von einzelnen Firmenprojekten. Die Suche nach digitalem Geld ohne vertrauenswürdige Mittelspersonen ging weiter, nur eben verteilt auf viele Köpfe statt auf ein einzelnes Unternehmen.

Die Cypherpunk-Mailingliste als Ideenschmiede

Ab Ende der 1980er und verstärkt in den 1990er Jahren traf sich ein Kreis aus Kryptografen, Programmierern und Aktivisten auf einer Mailingliste, die schlicht als Cypherpunk-Liste bekannt wurde. Hier wurden technische Entwürfe offen diskutiert, kritisiert und weiterentwickelt, oft binnen Stunden nach der ersten Veröffentlichung.

Eric Hughes fasste die gemeinsame Haltung 1993 in seinem Manifest zusammen. Wer sich für die Ursprünge dieser Denkweise interessiert, findet den Text im Original bis heute frei zugänglich. Er beschreibt Privatsphäre als etwas, das man sich technisch erarbeiten muss, statt es von Institutionen zu erwarten.

Auf der Liste kursierten Vorschläge für digitale Signaturen, Zeitstempel-Systeme und anonyme Übertragungswege wie Remailer. Keine dieser Ideen war für sich allein eine Lösung, doch zusammen bildeten sie den Werkzeugkasten, aus dem spätere Systeme schöpften. Die Cypherpunk Bewegung funktionierte dabei weniger wie eine feste Organisation und mehr wie ein offenes Labor.

Radikale Dezentralität als Leitgedanke

Was die Beiträge der Mailingliste verband, war kein gemeinsamer Code, sondern eine gemeinsame Skepsis gegenüber zentralen Kontrollpunkten. Diese radikale Dezentralität wurde zum Leitgedanken: Kein Server, keine Firma und keine Behörde sollte in der Lage sein, eine Transaktion zu blockieren oder eine Nutzerin zu identifizieren.

Diese Haltung unterschied die Cypherpunk Bewegung von früheren Projekten wie DigiCash, die trotz kryptografischer Innovation letztlich auf einen zentralen Ausgeber setzten. Radikale Dezentralität bedeutete, Vertrauen so weit wie möglich durch Mathematik und offene Protokolle zu ersetzen statt durch eine vertrauenswürdige Instanz.

Ein einheitliches System entstand aus dieser Phase nicht. Stattdessen hinterließ die Mailingliste ein Netz an Konzepten, das erst Jahre später zu einem funktionierenden Ganzen zusammengeführt wurde. Die einzelnen Bausteine blieben jedoch dokumentiert und für jeden nachlesbar erhalten.

Über die zentrale Schwäche des Vorgängerprojekts berichteten wir bereits: eCash-Zentralisierung und das Henne-Ei-Problem digitalen Geldes.