Das Double-Spending-Problem und verteilte Ledger

Warum eine digitale Zahlung eine gemeinsame Historie benötigt

Eine digitale Datei lässt sich kopieren, ohne das Original zu entfernen. Bei Dokumenten und Fotografien ist das nützlich, doch es wird zum Problem, wenn die Datei einen knappen Wert darstellen soll. Stellen Sie sich vor, ein Konto kann eine Einheit nur einmal ausgeben. Wenn zwei miteinander unvereinbare Anweisungen dieselbe Einheit beanspruchen, lässt sich allein anhand der Bestätigung, dass jede Anweisung authentisch erscheint, nicht bestimmen, welche davon gelten soll. Das ist das Double-Spending-Problem: die Möglichkeit, denselben verfügbaren Wert in mehreren miteinander konkurrierenden Transaktionen zu verwenden. Es geht dabei um die Konsistenz der Aufzeichnungen, nicht zwangsläufig um Diebstahl oder vorsätzlichen Betrug; zwei Transaktionen können auch versehentlich miteinander in Konflikt stehen, etwa wenn eine Software eine Zahlung mit unterschiedlichen Parametern erneut übermittelt.

In einem herkömmlichen Zahlungssystem bestimmt üblicherweise ein autorisierter Ledger-Betreiber die Reihenfolge, in der Anweisungen verarbeitet werden. Der Betreiber prüft den Kontostand, weist eine Anweisung zurück, die den verfügbaren Saldo überschreiten würde, und führt die offizielle Aufzeichnung. Ein verteiltes Ledger hingegen speichert Aufzeichnungen auf mehreren Computern, die häufig von verschiedenen Parteien betrieben werden. Diese Computer werden üblicherweise als Nodes bezeichnet. Wenn sie Nachrichten in unterschiedlicher Reihenfolge empfangen können, benötigen sie eine Möglichkeit, sich darauf zu einigen, welche Transaktionen gültig sind und in welcher miteinander vereinbaren Reihenfolge diese Transaktionen erfolgen. Dieses Einigungsproblem bildet den Ausgangspunkt für den Blockchain-Konsens.

Ein Beispiel für konkurrierende Transaktionen

Angenommen, ein Ledger verzeichnet einen noch nicht ausgegebenen Output im Wert von zehn Einheiten. Der Inhaber sendet Transaktion A, die diesen Output Empfänger Eins zuweist. Bevor alle Netzwerkteilnehmer A verarbeitet haben, übermittelt der Inhaber außerdem Transaktion B, die denselben Output Empfänger Zwei zuweist. Beide Transaktionen können syntaktisch korrekt sein, aber sie können nicht beide als separate Ausgaben des ursprünglichen Outputs wirksam werden. Aufgrund von Netzwerkverzögerungen können verschiedene Nodes A und B in umgekehrter Reihenfolge empfangen. Ein Netzwerk, das einfach die erste Nachricht akzeptiert, die ein Computer erhält, würde riskieren, inkonsistente Historien zu führen.

Ein zuverlässiges Design trennt daher zwei Entscheidungen. Bei der Validierung wird anhand eines bestimmten Ledger-Zustands geprüft, ob eine vorgeschlagene Transaktion den Protokollregeln entspricht. Beim Konsens wird festgelegt, welche Historie die Teilnehmer als akzeptiert betrachten, wenn miteinander konkurrierende, gültig erscheinende Vorschläge vorliegen. Sobald das Ledger A akzeptiert, steht B im Konflikt mit dem daraus resultierenden Zustand und sollte nicht ebenfalls als Ausgabe desselben Outputs akzeptiert werden. Die Einzelheiten unterscheiden sich zwischen Systemen, die diskrete, noch nicht ausgegebene Outputs nachverfolgen, und solchen, die Kontostände und Transaktionszähler führen. Das gemeinsame Prinzip lautet, dass ein Zustandsübergang dieselbe Ausgabeberechtigung nicht zweimal verbrauchen kann.

Die Reihenfolge ist ebenso wichtig wie die Authentizität

Die Autorisierung ist nur eine der Entscheidungsgrundlagen. Eine Signatur kann anzeigen, dass eine Anweisung gemäß dem geltenden kryptografischen Verfahren autorisiert wurde. Für sich genommen belegt sie jedoch nicht, dass die Mittel zum Zeitpunkt der Verarbeitung noch verfügbar sind. Ebenso legt ein vom Absender angegebener Zeitstempel nicht zwangsläufig die offizielle Reihenfolge im Netzwerk fest. In späteren Modulen werden Schlüssel und Signaturen ausführlich behandelt. Für den Moment sollten Sie sich den Unterschied merken: Eine Transaktion muss sowohl autorisiert sein als auch mit dem akzeptierten Ledger-Zustand übereinstimmen. Der Konsens bietet eine gemeinsame Grundlage, um diesen Zustand auf unabhängigen Computern zu bewerten.

Was ein Ledger verteilt macht

Ein verteiltes Ledger ist eine gemeinsame Sammlung von Aufzeichnungen, die unter mehreren Teilnehmern repliziert, synchronisiert oder anderweitig koordiniert wird. Nodes speichern nicht unbedingt zu jedem Zeitpunkt identische Informationen. Einige können vorübergehend offline sein, manche Nachrichten nur verzögert empfangen und andere spezialisierte Kopien oder Teilansichten führen. Entscheidend ist, dass die Regeln den teilnehmenden Nodes unter den Annahmen des Systems eine Möglichkeit bieten, sich auf einen konsistenten Zustand oder eine konsistente Historie zuzubewegen. Eine Blockchain ist eine Form eines verteilten Ledgers, bei der Aufzeichnungen in geordneten, kryptografisch verknüpften Blöcken zusammengefasst werden. Nicht jedes verteilte Ledger verwendet Blöcke, und nicht jede Blockchain steht einer uneingeschränkten Teilnahme offen.

Das Design eines Netzwerks bestimmt außerdem, wer Aktualisierungen vorschlagen darf, wer sie überprüfen darf und wessen Nachrichten zum Konsens beitragen. Offene, erlaubnisfreie Netzwerke lassen im Allgemeinen Teilnehmer zu, ohne dass ein Administrator sie einzeln registrieren muss. In erlaubnispflichtigen Netzwerken können Validatoren identifiziert und Governance-Regeln für die Mitgliedschaft angewendet werden. Beide Arten müssen Koordinationsfragen lösen, auch wenn sich Bedrohungen, Leistungsanforderungen und Formen der Rechenschaftspflicht unterscheiden. Der NIST Interagency/Internal Report 8202, Blockchain Technology Overview, beschreibt Blockchains als verteilte und manipulationssichere Ledger, während ISO 23257:2022 eine Referenzarchitektur für Blockchain- und andere Distributed-Ledger-Systeme bietet.

Einigung ist nicht dasselbe wie Wahrheit

Der Konsens kann feststellen, dass eine Gruppe von Nodes eine bestimmte Aufzeichnung akzeptiert hat. Er kann jedoch nicht beweisen, dass jede darin enthaltene Aussage über die reale Welt wahr ist. Wenn ein Dokument besagt, dass ein Container gestern eingetroffen ist, kann das Ledger festhalten, wann die Aussage aufgezeichnet und wie sie genehmigt wurde; den physischen Container kann es nicht untersuchen. Ebenso klärt die Aufzeichnung von Eigentumsansprüchen nicht von sich aus die zugrunde liegende Rechtsanspruchsberechtigung. Für Fachkräfte im Rechtswesen und öffentlichen Sektor verhindert diese Unterscheidung die falsche Annahme, eine replizierte Datenbank schaffe automatisch verlässliche Beweise für Ereignisse außerhalb des Netzwerks.

Was Nodes unabhängig prüfen können

Ein vollständig validierender Node wendet den Regelsatz des Netzwerks auf vorgeschlagene Aktualisierungen an, anstatt dem Vorschlagenden zu vertrauen. Er kann häufig prüfen, ob ein Block die vorgeschriebene Struktur aufweist, ob Transaktionen die Zustandsübergangsregeln einhalten und ob die vorgeschlagene Historie korrekt verknüpft ist. Externe Fakten kann er nicht unabhängig verifizieren, es sei denn, das Protokoll bietet eine gesonderte, vertrauenswürdige Möglichkeit, diese festzustellen. Ein Beobachter könnte sehen, dass sich mehrere Nodes einig sind, und dabei übersehen, dass sie sich alle auf denselben fehlerhaften externen Bericht stützten. Die Einigung von Computern und die unabhängige Überprüfung physischer Sachverhalte sind unterschiedliche Kontrollmaßnahmen.

Designziele und unvermeidliche Kompromisse

Eine verteilte Einigung muss Nachrichtenverzögerungen, vorübergehende Netzwerkpartitionen und Teilnehmer berücksichtigen, die falsche oder widersprüchliche Nachrichten senden. Eine Netzwerkpartition liegt vor, wenn Node-Gruppen nicht normal miteinander kommunizieren können. Ein fehlerhafter oder böswilliger Teilnehmer kann ungültige Daten vorschlagen, Nachrichten zurückhalten oder verschiedenen Peers unterschiedliche Behauptungen übermitteln. Konsensmechanismen legen Regeln dafür fest, wie der Betrieb trotz einiger dieser Bedingungen fortgesetzt werden kann. Kein Mechanismus garantiert jedoch bei jedem Ausfallszenario einen ununterbrochenen Fortschritt. Ein Design muss Annahmen über die Konnektivität, das Verhalten der Teilnehmer, die verfügbaren Ressourcen und akzeptable Verzögerungen enthalten.

Drei praktische Ziele helfen bei der Bewertung. Konsistenz bedeutet, dass Teilnehmer nicht dauerhaft miteinander unvereinbare offizielle Historien akzeptieren. Verfügbarkeit bedeutet, dass legitime Nutzer weiterhin Aufzeichnungen einreichen und verarbeiten können, wenn das System bestimmungsgemäß funktioniert. Prüfbarkeit bedeutet, dass Betreiber erklären können, warum ein Zustandsübergang akzeptiert wurde, und die relevanten Prüfungen nachvollziehen können. Diese Ziele hängen von Architektur und Governance ab, nicht allein vom Wort Blockchain. Aussagen, ein Ledger sei einfach „dezentralisiert“, „unveränderlich“ oder „sofort“, sind unvollständig, wenn nicht angegeben wird, wer validiert, welche Ausfallbedingungen angenommen werden und wann ein Eintrag als endgültig gilt.

Ein institutionelles Beispielszenario

Stellen Sie sich eine öffentliche Behörde vor, die gemeinsam mit anderen Behörden die Ausstellung elektronischer Genehmigungen koordiniert. Zwei Ämter reichen widersprüchliche Aktualisierungen zum Status einer Genehmigung ein. Ein gemeinsames Ledger kann ihnen dabei helfen, sich auf die aufgezeichnete Reihenfolge autorisierter Änderungen zu einigen und einen überprüfbaren Verlauf abgelehnter Konflikte zu bewahren. Es kann jedoch nicht entscheiden, welches Amt über die maßgebliche rechtliche Befugnis verfügte, sofern diese Befugnis nicht in dokumentierten Richtlinien und durchsetzbaren Autorisierungsregeln festgehalten ist. Die Verantwortlichen müssen entscheiden, ob bekannte Institutionen Nodes betreiben, was geschieht, wenn ein Betreiber nicht verfügbar ist, und welche Institution einen fehlerhaften Eintrag durch einen neuen, sichtbaren Eintrag korrigieren kann.

In diesem Szenario könnte auch eine Standarddatenbank geeignet sein, die auf Grundlage einer klaren Vereinbarung verwaltet wird. Der Nutzen eines verteilten Konsenses wächst, wenn unabhängige Betreiber tatsächlich einen gemeinsamen Zustand benötigen, ohne sich auf eine einzelne Stelle zu verlassen, die Aktualisierungen vornimmt. Die zusätzlichen Betriebskosten sind schwerer zu rechtfertigen, wenn eine Behörde ohnehin jede Entscheidung kontrolliert. ISO 22739:2024, Blockchain and distributed ledger technologies — Vocabulary, ist eine hilfreiche Referenz für eine einheitliche Terminologie, ersetzt jedoch nicht die Prüfung der tatsächlichen Vertrauensannahmen des Designs.

Kurzreferenz

Was Lernende behalten sollten

Das Double-Spending-Problem erklärt, warum das Kopieren eines digital dargestellten Werts nicht dasselbe ist wie dessen gültige Ausgabe. Verteilte Systeme lösen das Problem durch Validierung und Einigung auf eine gemeinsame Abfolge oder einen gemeinsamen Zustand. Der Konsens beantwortet, welche konkurrierenden Aufzeichnungen das Netzwerk akzeptiert; er stellt weder die Wahrheit aller darin erwähnten Tatsachen fest noch beseitigt er jedes Betriebsrisiko. In den folgenden Lektionen untersuchen wir die Datenstrukturen und Regeln, die diese Koordination ermöglichen, anstatt die allgemeinen Anlagekategorien aus Modul 1 erneut zu behandeln.

Prüfungsschwerpunkt: Erklären Sie, warum Authentizität allein Double Spending nicht verhindern kann; unterscheiden Sie Validierung von Konsens und erkennen Sie, dass eine Blockchain eine Art verteiltes Ledger und kein Synonym für alle gemeinsam genutzten Datenbanken ist.

Quellenhinweise

Relevante Referenzen: NIST IR 8202 (2018), Blockchain Technology Overview; ISO 22739:2024, Blockchain and distributed ledger technologies — Vocabulary; und ISO 23257:2022, Blockchain and distributed ledger technologies — Reference architecture.