MSTR Cat

Blockchain/Niveau III · Das Netzwerk/3.1 Nodes/Lektion 4

Pruned Nodes und Light Clients (SPV)

Die Architektur des Vertrauens: von vollständiger Überprüfung bis zu Merkle-Proofs

MaterialienEin Bitcoin-Core-Node, der mit prune=550 konfiguriert ist (optional)Eine Light WalletEin Block-Explorer

Neugier

  1. Wie kann ein Node die gesamte Geschichte von Bitcoin validieren, ohne jeden Block für immer zu speichern?
  2. Welcher konkrete kryptografische Mechanismus ermöglicht es einer Smartphone-Wallet, ihr Guthaben zu überprüfen, ohne Hunderte Gigabyte an Daten herunterzuladen?
  3. Warum gaben die ursprünglichen, eigentlich privatsphäreschonenden Filter für Light Wallets die Identität der Nutzer preis, und wie wurde diese Schwachstelle behoben?

Erkunden

  1. Vollständige Validierung und vollständige Speicherung lassen sich trennen. Jeder validierende Node muss jeden Block einmal verarbeiten, um das aktuelle Set der nicht ausgegebenen Outputs aufzubauen, muss alte Blöcke danach aber nicht behalten. Manche Clients gehen weiter und verzichten ganz auf die Validierung; sie prüfen nur, ob Transaktionen in Blöcken mit ausreichendem Proof of Work enthalten sind. Bei diesen Entscheidungen werden Speicherplatz, Bandbreite und Privatsphäre gegen Unabhängigkeit abgewogen.
  2. Ein Pruned Node führt dieselbe initiale Validierung jedes Blocks ab dem Genesis-Block durch, löscht danach aber alte Blockdaten, um Speicherplatz zu sparen. Die Einstellung `prune` in Bitcoin Core behält mindestens 550 MB an jüngsten Blöcken und verwirft ältere, sobald sie verifiziert sind. Der Node bleibt ein vollwertiger Validator, der die Konsensregeln durchsetzen und die Wallet seines Besitzers mit unabhängig geprüfter Wahrheit schützen kann. Allerdings kann er anderen Peers keine historischen Blockdaten mehr bereitstellen und keine Funktionen unterstützen, die tiefe Abfragen in der Chain erfordern, etwa `txindex`.
  3. Light Clients, auch SPV-Nodes genannt, verfolgen einen anderen Ansatz: Sie validieren nicht das vollständige Regelwerk. Sie laden nur Block-Header herunter, die die Merkle-Root aller Transaktionen des jeweiligen Blocks enthalten. Um zu prüfen, ob eine bestimmte Transaktion enthalten ist, fordert der Client bei einem Peer einen Merkle-Proof an und gleicht ihn mit der Root im Header ab. Das beruht auf der Annahme, dass die Chain mit der meisten kumulierten Arbeit gültig ist; die unabhängige Durchsetzung der Regeln wird so gegen drastisch geringeren Speicher- und Bandbreitenbedarf eingetauscht.
  4. Frühe SPV-Implementierungen nutzten BIP37-Bloom-Filter, damit Wallets bei Peers nur relevante Transaktionen anfordern konnten. Die Wallet sendete einen Filter, der ihre Adressen beschrieb; die Peers durchsuchten ihren Mempool und schickten passende Transaktionen. Dieses Design gab Privatsphäre preis: Durch Beobachten der Filter konnte ein bösartiger Peer ableiten, welche Adressen dem Nutzer gehörten, und dessen Aktivitäten verfolgen. Bitcoin Core stellte Bloom-Filter 2019 (Version 0.19) standardmäßig nicht mehr bereit.
  5. Compact Block Filters (BIP157/158) kehrten diesen Ablauf um, um die Privatsphäre wiederherzustellen. Statt dass die Wallet ihre Adressen preisgibt, veröffentlichen Full Nodes für jeden Block einen kompakten Filter; der Client lädt diese Filter herunter und prüft sie lokal gegen seine eigenen Schlüssel. Passt ein Filter, lädt der Client den gesamten Block herunter, denn die Anforderung einer einzelnen Transaktion würde diese dem Peer verraten. So erfahren Peers nicht, welche Adressen die Wallet überwacht, was die Privatsphäre der Nutzer deutlich verbessert und dennoch eine effiziente Synchronisation ermöglicht.
  6. Viele mobile Wallets beziehen ihre Daten von einem Server Dritter, etwa einem Electrum-Server, prüfen die Merkle-Proofs aber selbst anhand der Block-Header. Der Zielkonflikt ist klar: Bequemlichkeit und geringer Ressourcenverbrauch gegenüber unabhängiger Überprüfung und Privatsphäre. Wer einen Pruned Node betreibt, behält die volle Validierungsfähigkeit, kann historische Daten aber nur eingeschränkt bereitstellen; eine SPV-Wallet bleibt minimal im Ressourcenbedarf, ist aber darauf angewiesen, dass Peers ihr jede relevante Transaktion zeigen, und nimmt ungeprüft an, dass die Chain mit der meisten Arbeit gültig ist.

Kernfakten

  • Ein Pruned Node validiert alle Blöcke ab dem Genesis-Block, löscht aber alte Daten und behält mindestens 550 MB an jüngsten Blöcken.
  • SPV-Clients laden nur Block-Header herunter und prüfen Transaktionen mithilfe von Merkle-Proofs gegen den Root-Hash des Headers.
  • BIP37-Bloom-Filter gefährdeten die Privatsphäre der Nutzer, weil sie den Peers verrieten, welche Adressen eine Wallet überwachte.
  • Compact Block Filters (BIP157/158) ermöglichen es Clients, vom Server bereitgestellte Filter lokal zu prüfen, und wahren so die Privatsphäre der Adressen.
  • SPV-Wallets vertrauen darauf, dass die Chain mit dem meisten kumulierten Proof of Work gültig ist, statt alle Konsensregeln unabhängig durchzusetzen.
  • Pruned Nodes bleiben vollwertige Validatoren und können die Gelder ihres Besitzers schützen, aber anderen Peers keine historischen Blockdaten bereitstellen.

Übung neun, sechs, drei, eins

9SammelnListen Sie 9 Arten von Bitcoin-Nodes oder Client-Implementierungen auf. Notieren Sie jeweils: Speicherbedarf, Validierungsfähigkeit (vollständig vs. SPV) und den wichtigsten Anwendungsfall.
6GruppierenGruppieren Sie die 9 nach dem Grad ihrer unabhängigen Überprüfung und Datenvorhaltung in 6 Kategorien.
3VerdichtenReduzieren Sie die 6 Gruppen auf 3 unterschiedliche Kompromisse zwischen Privatsphäre, Sicherheit und Ressourcenverbrauch.
1KristallisierenSchreiben Sie 1 Satz, der erklärt, warum sich das Vertrauensmodell eines Light Clients grundlegend von dem eines Full Nodes unterscheidet.

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

In der interaktiven Akademie öffnen →

EN PT ES ZH JA KO RU FR MS