Full Node

Was ist ein Node?

„Das Bitcoin-Netzwerk“ klingt oft wie eine Cloud. Technisch ist es ein Netzwerk aus vielen Computern mit derselben Software, die miteinander reden.

Ein Node führt Bitcoin-Software aus (meist Bitcoin Core) und ist mit anderen Nodes verbunden. Das P2P-Netzwerk hat keine Mitte: viele gleichberechtigte Teilnehmer tauschen Daten aus.

Jeder Node ist autonom: Niemand befiehlt deinem Client etwas. Er prüft nach eingebauten Regeln und leitet nur weiter, was passt. Alle folgen denselben Konsensregeln, deshalb landen sie beim gleichen Ergebnis.

Bitcoin ähnelt in Teilen BitTorrent: viele Rechner halten dieselben Daten (die Blockchain) und verteilen sie weiter.

Kein zentraler Server. Peers mit verschiedener Software und Speicherstrategie tauschen trotzdem Blöcke und Transaktionen. Orange: aktive Verbindungen deines Nodes. Blau = Archival, Grün = Pruned.

Verschiedene Versionen, ein Netz

Im Diagramm: Archival (volle Chain), Pruned (ältere Blöcke weg, Validierung voll), verschiedene Core-Versionen (z. B. v28, v27, v26).

Trotzdem verbunden. Zwei Ebenen:

Konsensregeln: Was ist ein gültiger Block/Tx? Darauf müssen sich alle einigen.
Software: Version, archival/pruned, Peer-Limits dürfen differieren, solange dieselben Regeln gelten und das P2P-Protokoll abwärtskompatibel bleibt.

Kurz: v25 und v28 können Peers sein; Pruned und Archival tauschen dieselben Blöcke/Txs aus. Soft Forks verschärfen Regeln schrittweise; Hard Forks sind selten. Beim Verbinden handeln Clients Dienste aus (version-Message); Ungültiges wird verworfen, nicht „der Peer“.

Trotzdem: nicht ewig auf alter Version bleiben (Sicherheit, P2P-Dialekt). Das Netz ist ein Mix aus Versionen, gehalten durch gemeinsame Regeln.

Was macht ein Node?

Drei Jobs, egal ob Full Node oder leichte Wallet:

1. Den Regeln folgen

Tx und Blöcke werden gegen Konsensregeln geprüft. Beispiel: nicht mehr ausgeben als im UTXO-Set vorhanden. Ungültiges wird nicht weitergeleitet. Das ist Trustlessness: du prüfst selbst.

2. Informationen teilen

Relay: nur geprüfte Tx/Blöcke an Peers. Frisch = unbestätigt im Mempool; bestätigt = im Block gebündelt.

3. Einen Stand der Kette vorhalten

Die Blockchain speichert bestätigte Tx. Beim ersten Start: Sync mit dem Netz, dann neue Daten gegen diesen Stand prüfen.

Brauchst du einen eigenen Node?

Nein zum Nutzen (Wallet reicht Tx ins Netz). Ja zum Selbst-Prüfen. Gründe: Vertrauen, Privatsphäre, Netz stützen, Lernen/bitcoin-cli.

Welche Node-Arten gibt es?

Kernfrage: Validiert selbst oder verlässt sich auf andere?

Hält mit der Chain Schritt, validiert jeden Block und jede Tx. Aktiver Teilnehmer, rechnet nach. Referenzpunkt auf BitcoinVonInnen.

Archival Node

Behält jeden Block auf Platte. Kann Chain analysieren und anderen beim Sync helfen. Braucht viel Speicher (Chain hunderte GB, eher 2 TB+ langfristig).

Pruned Node

Validiert alles, löscht aber alte Rohblöcke. Behält UTXO/Chainstate. Kann keine volle Chain mehr ausliefern, spart aber Platte.

	Archival	Pruned
Validiert alles	ja	ja
Volle Historie auf Platte	ja	nein
Chain an andere seeden	ja	eingeschränkt
Plattenbedarf	hoch	geringer

Lightweight Node (Thin Client)

Folgt der Chain, validiert nicht. Kann Existenz in der Chain prüfen, nicht Regelkonformität. Eher Client als Node.

SPV-Wallet

Lädt Block-Header, holt Merkle-Proof von einer Full Node. Praktisch, aber Vertrauen in den Proof-Lieferanten nötig.

Miner

Packt Mempool-Txs in Blöcke, Proof of Work. Heute getrennt von der Node-Rolle (empfangen/validieren/relay), oft aber auf einer Maschine. Beim Lernen trennen: Node ≠ Miner.

Was braucht eine Full Node?

Rechner + Internet. Archival grob: 2 TB+ Platte, 2 GB+ RAM, spürbare Bandbreite (maxuploadtarget begrenzbar). Läuft oft auf Raspberry Pi oder altem PC.

Full Node im Detail

Interne Schichten (siehe Icon): Netzwerk rein, Verarbeitung, Persistenz.

P2P: Rohdaten von Peers (Tx, INV, GetData). Pipeline: empfangen → prüfen → weitergeben → Zustand aktualisieren.

Speicherpool (Mempool)

Unbestätigte, vorläufig valide Tx. Themen: Gebühren, RBF, erste Transaktionsprüfung.

Relais

Weitergeben per INV / GetData, kompakte Blöcke. Mempool sammelt, Relais gossiped.

Konsens

Skript-, Signatur-, Konsensregeln. Nur Valides ändert den Chainstate.

Blockchain / UTXO

Chainstate, UTXO-Set, Reorgs bei längerem Zweig.

Speicher (Festplatte)

blocks/, Chainstate, Indizes. Display-Kette = Blöcke auf der SSD.

Ablauf: P2P → Mempool → Relais → Konsens → Blockchain/UTXO → Speicher.

bitcoind -daemon
bitcoin-cli getblockchaininfo

getblockchaininfo: Sync-Stand, aktive Chain, Netzwerk-Übereinstimmung. Von dort in Blöcke, Tx, Mempool.

Diese Bausteine werden auf BitcoinVonInnen Schritt für Schritt mit Diagrammen vertieft.