Ein Bitcoin-Node speichert standardmäßig nur so viel, wie er wirklich braucht, um Regeln zu prüfen und die eigene Wallet zu bedienen. Bestimmte, durchaus nützliche Fragen ("wo genau in der Geschichte der letzten 17 Jahre taucht diese eine Transaktion auf?") wären damit nur über einen extrem aufwendigen, kompletten Durchgang durch die gesamte Kettenhistorie zu beantworten. Für genau solche Fälle bietet Bitcoin Core zusätzliche, rein optionale Register an, die du gezielt einschalten kannst. Dieser letzte Beitrag der Serie stellt die drei wichtigsten vor.
Ein Rückblick: was ein Node ohne jeden Zusatz-Index bereits kann
Bevor wir zu den Erweiterungen kommen, lohnt sich eine kurze Erinnerung daran, was ein ganz gewöhnlicher Node schon "out of the box" leistet, ganz ohne jeden der folgenden optionalen Indizes: Er kann jederzeit vollständig eigenständig prüfen, ob eine neue Transaktion oder ein neuer Block sämtlichen in Teil 2 und Teil 3 dieser Serie beschriebenen Regeln entspricht. Er kann den aktuellen Kontostand jeder in seiner eigenen Wallet verwalteten Adresse zuverlässig ermitteln. Und er kann feststellen, ob ein bestimmter, ihm bereits bekannter einzelner UTXO aktuell noch unverbraucht ist. Für den täglichen Betrieb als "stimmberechtigter" Netzwerkteilnehmer und für die eigene Wallet reicht das vollkommen aus, die drei folgenden Indizes lösen ausschließlich Zusatzbedürfnisse, die über diesen Kern hinausgehen.
Warum ein Node nicht einfach "alles" speichert
Das mag zunächst überraschen: Wäre es nicht einfacher, ein Node würde grundsätzlich alles indexieren, was er sieht? Der Grund dagegen ist simpel: Speicherplatz und Rechenzeit. Jeder zusätzliche Index bedeutet zusätzliche Datenbank-Einträge, die bei jedem neuen Block aktualisiert werden müssen, und zusätzlichen Festplattenplatz, der bei einer mittlerweile über 700 Gigabyte großen Blockchain durchaus ins Gewicht fällt. Bitcoin Core überlässt daher jedem Betreiber die freie Wahl: Wer die Zusatzfunktion braucht, schaltet den passenden Index gezielt ein, alle anderen sparen sich den Aufwand.
Der Transaktions-Index: das gesamte Geschichtsbuch durchsuchbar machen
Ohne besondere Einstellung kann ein Node nur Transaktionen nachschlagen, die entweder seine eigene Wallet betreffen oder sich noch im aktuellen Mempool befinden. Der optionale Transaktions-Index (txindex, standardmäßig ausgeschaltet, siehe src/index/txindex.h) ändert das: Einmal aktiviert, merkt sich der Node für jede einzelne jemals bestätigte Transaktion in der kompletten Kettenhistorie, an welcher genauen Stelle auf der Festplatte sie zu finden ist, gespeichert in einer separaten, sehr effizienten Datenbank (LevelDB). Dienste wie Blockexplorer (siehe Teil 7 dieser Serie) sind darauf praktisch angewiesen, denn sie müssen ja beliebige, fremde Transaktionen nachschlagen können, nicht nur eigene.
Kompakte Filter für schlanke Clients (BIP157/158)
Nicht jeder, der Bitcoin nutzen möchte, kann oder will 700 Gigabyte Blockchain-Daten auf dem eigenen Gerät vorhalten, man denke an ein Smartphone. Für solche "leichten" Clients gab es historisch bereits einen Lösungsansatz namens Bloom-Filter (BIP37): Der leichte Client baute aus den eigenen Adressen einen kompakten, absichtlich leicht ungenauen Filter (ein platzsparendes Bit-Array) und schickte diesen an einen Full Node, der ihm daraufhin alle möglicherweise passenden Blöcke zurücklieferte. Die eingebaute Ungenauigkeit war dabei durchaus gewollt: Ein Treffer im Filter bedeutet nur "möglicherweise relevant" (echte Treffer eingeschlossen, aber auch falsche Positive), während ein Nicht-Treffer hundertprozentig sicher bedeutet "definitiv nicht relevant", dieses bewusste Verrauschen sollte eigentlich etwas Unschärfe zugunsten der Privatsphäre einbauen. In der Praxis erwies sich das aber als zu schwach: Ein Beobachter, der über längere Zeit denselben Filter derselben Wallet sieht, kann durch wiederholte Beobachtung die tatsächlich gesuchten Adressen mit wachsender Sicherheit eingrenzen, ein Privatsphäre-Kompromiss, der sich mit der Zeit verschlimmert statt stabil zu bleiben.
Der modernere Compact-Block-Filter-Index (BIP157/158, src/index/blockfilterindex.h) dreht das Prinzip um: Der Full Node erstellt für jeden einzelnen Block von sich aus einen kompakten, mathematisch cleveren Filter (ein sogenanntes Golomb-codiertes Set, GCSFilter in src/blockfilter.h) und veröffentlicht ihn. Ein leichter Client lädt sich diese (recht kleinen) Filter selbst herunter und prüft rein lokal auf seinem eigenen Gerät, ob ein bestimmter Block potenziell relevante Transaktionen für ihn enthalten könnte. Nur wenn ein Filter einen möglichen Treffer anzeigt, fragt der Client gezielt den vollständigen Block nach. Der entscheidende Unterschied: Der Full Node erfährt zu keinem Zeitpunkt, wonach der Client überhaupt sucht: die gesamte "Suche" findet ausschließlich lokal beim Client statt.
CoinStatsIndex: eine Prüfsumme über Millionen Guthaben, die sich nicht komplett neu berechnen muss
Der dritte optionale Index löst ein eher subtiles Problem: Wie stellt man effizient eine kryptografische "Prüfsumme" über den kompletten, aktuellen Bestand aller existierenden, unverbrauchten Bitcoin-Guthaben weltweit auf (den sogenannten UTXO-Satz), ohne bei jeder neuen Transaktion alles von Grund auf neu durchzurechnen? Die Lösung heißt MuHash (src/crypto/muhash.h): eine spezielle Hashfunktion über Mengen, die es erlaubt, ein einzelnes neues Element zur bestehenden Prüfsumme einfach hinzuzurechnen oder ein verbrauchtes Element wieder herauszurechnen, ohne die riesige Gesamtmenge erneut komplett verarbeiten zu müssen. Aktiviert man den CoinStatsIndex, hält der Node diese laufend aktuelle Prüfsumme ständig bereit, nützlich z.B., um schnell zu verifizieren, dass zwei unabhängige Nodes tatsächlich exakt denselben UTXO-Bestand sehen, ohne dafür jeweils eine sehr rechenintensive Vollprüfung anstoßen zu müssen.
Ein praktischer Kompromiss: Pruning als Gegenstück zur Indexierung
Interessant ist, dass Bitcoin Core in die genau entgegengesetzte Richtung ebenfalls eine Option anbietet: den sogenannten "Pruned Mode". Statt zusätzliche Indizes zu aktivieren und damit MEHR Speicherplatz zu belegen, kann ein Node auch so konfiguriert werden, dass er ältere, bereits vollständig geprüfte Blockdaten nach der Validierung wieder von der Festplatte löscht und nur die für die laufende Konsensprüfung unbedingt nötigen Informationen behält. Ein derart "beschnittener" Node kann weiterhin vollwertig jede neue Transaktion und jeden neuen Block eigenständig nach denselben, in Teil 2 dieser Serie beschriebenen Regeln prüfen; er kann nur eben keine sehr alten, historischen Anfragen mehr beantworten, weil die entsprechenden Rohdaten schlicht nicht mehr vorhanden sind. Für jemanden, der einfach nur einen vollwertigen, souveränen Node für die eigene Wallet betreiben möchte, ohne selbst als Blockexplorer-Backend zu dienen, ist das ein völlig legitimer, ressourcenschonender Kompromiss, ein schönes Beispiel dafür, dass "vollständige Regelprüfung" und "vollständige Datenspeicherung" zwei unabhängige Dinge sind, die man getrennt voneinander konfigurieren kann.
Praxisbeispiel: warum ein Lightning-Node auf txindex angewiesen sein kann
Ein konkretes Beispiel macht den Nutzen des Transaktions-Index greifbar: Ein Lightning-Node (siehe Teil 3 dieser Serie zu den technischen Grundlagen von Zahlungskanälen) muss gelegentlich prüfen können, ob eine bestimmte, unter Umständen schon lange zurückliegende Kanal-Eröffnungstransaktion tatsächlich wie erwartet in der Blockchain verankert wurde, auch wenn diese Transaktion nichts mit der eigenen Wallet des Node-Betreibers zu tun hat, weil der Kanalpartner sie ursprünglich eingereicht hat. Ohne aktivierten Transaktions-Index müsste der zugrundeliegende Bitcoin-Node dafür im ungünstigsten Fall die gesamte Kettenhistorie durchsuchen; mit aktiviertem txindex ist die Antwort dagegen in Sekundenbruchteilen da. Das ist einer der Gründe, warum Anleitungen zum Betrieb eines eigenen Lightning-Node fast immer empfehlen, den zugrundeliegenden Bitcoin-Node gleich mit aktiviertem Transaktions-Index zu betreiben.
Fazit der Serie: Ein System, das seine eigenen Hausaufgaben zeigt
Mit diesem letzten Baustein schließt sich der Kreis dieser achtteiligen Serie. Wir haben gesehen, wie Bitcoins Konsensregeln unbestechlich im Code verankert sind, wie sich das Skriptsystem über Taproot bis hin zu mehr Privatsphäre weiterentwickelt hat, nach welchen Regeln der Mempool arbeitet, wie sich Nodes ganz ohne Zentrale finden, wie eine Wallet intelligent Guthaben auswählt, wie Software von außen mit einem Node spricht, und jetzt, wie optionale Indizes bestimmte Fragen erst praktikabel beantwortbar machen.
Der eigentliche Punkt dieser gesamten Serie war nie, dass du dir jede einzelne Codezeile merkst. Er war, dir zu zeigen: Jede hier beschriebene Behauptung lässt sich an einer konkreten, öffentlich einsehbaren Stelle im Code nachprüfen, nichts davon musst du irgendjemandem einfach glauben. Genau das unterscheidet ein System, dem man vertrauen soll, von einem, das man selbst überprüfen kann. Und genau darin liegt, technisch betrachtet, der eigentliche Wert von Bitcoin.
