Node

Was ist eine Node?

In einem Netzwerk ist eine Node (Knoten) ein Teilnehmer, ein Rechner, der mit anderen verbunden ist, Daten empfängt, weiterreicht und dabei die Regeln dieses Netzes befolgt. Ob Torrent, Chat oder Blockchain: ohne Nodes kein verteiltes System.

Eine Bitcoin-Node macht dasselbe für Bitcoin. Sie führt Bitcoin-Software aus. Üblich ist Bitcoin Core, im Netz laufen aber auch andere Implementierungen (Übersicht auf Coin.Dance). Sie hängt im P2P-Netzwerk an anderen Nodes, prüft nach festen Konsensregeln und leitet nur weiter, was passt, ohne zentralen Server.

Was macht eine Node?

Drei Aufgaben, unabhängig von Archival oder Pruned:

1. Regeln durchsetzen

Jede eingehende Transaktion und jeder Block wird lokal geprüft: Script, Signatur, UTXO und die Konsensregeln. Passt alles, nimmt die Node die Daten auf. Passt etwas nicht, wird verworfen und nicht an Peers weitergeleitet. Beispiel: mehr ausgeben, als die UTXOs hergeben.

Das ist Trustless Validation („don't trust, verify“): Ungültige Daten bleiben auf der Node und gehen nicht ins Netz.

Mehr dazu: Validation.

2. Informationen teilen

Erst prüfen, dann weitergeben: An Peers gehen nur geprüfte Daten. Transaktionen werden nach lokaler Prüfung im Mempool zwischengespeichert und weiterverbreitet. Blöcke werden über das P2P-Netz angekündigt, angefordert, geprüft und bei Gültigkeit an die lokale Chain angehängt.

Gossip („Tratsch“, „Geplauder“) ist das „Weitererzählen“ im P2P-Netz: Eine Node kündigt Neues an (INV), Nachbarn holen bei Bedarf nach (GetData) und leiten es an ihre Peers weiter. So verteilt sich eine Transaktion oder ein Block schrittweise durch viele Nodes, ohne zentralen Server.

Ungültige Objekte werden nicht verbreitet. Jede Node entscheidet für sich, was sie annimmt und weiterreicht.

Mehr dazu: Relay, Mempool.

3. Chain-Stand halten

Die Node hält den eigenen Bitcoin-Zustand aktuell. Beim Initial Block Download (IBD) holt sie Blöcke von Peers, findet den Chain-Tip und pflegt Chainstate sowie UTXO Set. Die Blockhistorie speichert sie voll (Archival) oder gekürzt (Pruned).

So bleibt die lokale Sicht mit dem Netz konsistent, ohne einer zentralen Quelle zu vertrauen.

Mehr dazu: Blockchain, Chainstate, Archival und Pruning.

Wie wird eine Node betrieben?

Bitcoin-Nodes einigen sich auf dieselben Konsensregeln. Unterschiede entstehen vor allem bei Software, Speicher, Peers und Relay-Policies nicht bei der Frage, was ein gültiger Block ist.

Was die meisten Full Nodes gemeinsam haben

• wenden dieselben Konsensregeln an
• akzeptieren nur Blöcke und Transaktionen, die diesen Regeln entsprechen
• leiten lokal gültige, selbst akzeptierte Daten an Peers weiter (Relay)

Bei bestätigten Blöcken ist das Ergebnis im Netz gleich. Im Mempool kann die Auswahl unbestätigter Transaktionen je Node abweichen.

Wo Unterschiede entstehen

• Software: meist Bitcoin Core, daneben btcd, Bitcoin Knots und andere Clients
• Speicherung: volle Chain oder Pruned (Archival und Pruning)
• Relay / Mempool: welche Tx weitergegeben werden (Fees, Standardness, blocksonly, Client-Policy)
• Netzwerkverbindungen: Listening oder Outbound-only (Peers)
• Zusatzfunktionen: Wallet, Mining, Indexing (Wallets, Mining Pools, Indexes)
• Ressourcenverbrauch: Platte, RAM, Bandbreite (abhängig von Archival, Pruned und Indizes)

Dadurch bleibt das Netzwerk kompatibel, obwohl Nodes unterschiedlich konfiguriert sein können.

Zusätzlich gibt es Validierungstiefe jenseits der Full Node: Full Validation vs. SPV (siehe Validation und Trust Model).

BitcoinVonInnen-FullNode-Konfiguration

Innenleben einer Full Node

Intern arbeitet eine Full Node in Schichten, von Netzwerk bis Speicher:

Datenfluss: Über P2P empfängt die Node Transaktionen und Blöcke von Peers. Transaktionen werden gegen Policy und relevante Konsensregeln geprüft und bei Akzeptanz im Mempool zwischengespeichert. Blöcke werden nach den Konsensregeln geprüft und verändern bei Gültigkeit den Chainstate und das UTXO-Set. Akzeptierte Daten können anschließend per Relay an andere Peers weitergegeben werden. Blockdaten, Chainstate und Indizes landen im Speicher.

• P2P: Bytes von Peers empfangen, gültige Objekte weitergeben
• Mempool: unbestätigte Transaktionen vor dem Block
• Policy: Standardness, Relay-Gebühr, RBF (lokal, nicht Konsens)
• Relay: INV, GetData, Gossip im P2P-Netz
• Konsens: Script, Signatur, UTXO, Konsensregeln (verwerfen oder akzeptieren)
• UTXO / Chain: Chain-Tip, Chainstate, UTXO Set
• Speicher: Blocks auf Disk, Archival oder Pruned

Die drei Aufgaben oben stecken in diesen Schichten. Wallet, Mining und Indexing sind Zusatzfunktionen, nicht der Kern der Validierung.

Speicherung: Archival (alternativ Pruned). Client: Bitcoin Core.

Früher lagen Wallet, Node, Mining und Relay oft näher beieinander. Heute sind diese Rollen meist getrennt. Mehr dazu: Bitcoin Core (Überblick).

Verschiedene Nodes, ein Netz

Archival vs. Pruned, verschiedene Core-Versionen: trotzdem ein gemeinsames Netz, weil alle dieselben Konsensregeln anwenden.

Mehr dazu: Konsens Regeln. Regeländerungen: Soft Forks.

Brauchst du einen eigenen Node?

Nein: Um Bitcoin zu nutzen, brauchst du meist nur eine Wallet . Die Wallet sendet deine Transaktion an eine fremde Node (oft eines Anbieters) diese verteilt sie im P2P-Netzwerk. Mehr zum Vertrauen: Trust Model.

Ja: Wenn du Transaktionen und Regeln selbst prüfen willst, statt einer fremden Node zu vertrauen.

Deine Wallet kannst du dabei an deine eigene Node anbinden: Hardware-Wallet oder separate Software nutzt dann deinen Node für Broadcast und Chain-Stand, statt eine fremde Node eines Anbieters.

Eigene Nodes verbessern außerdem:

• Privatsphäre
• unabhängige Validierung („Don’t trust, verify“)
• Verständnis des Netzwerks
• die Verteilung und Robustheit des P2P-Netzes

Wie synchronisiert sich eine neue Node?

Beim ersten Start kennt eine Bitcoin-Node weder den Chain-Tip, also den letzten Block ihrer aktiven Blockchain, noch den aktuellen Zustand des UTXO-Sets. Deshalb lädt sie die Blockchain von anderen Peers herunter und überprüft jeden einzelnen Block selbst. Dieser Vorgang heißt Initial Block Download (IBD).

1. Peers finden

Zunächst verbindet sich die Node mit anderen Teilnehmern im P2P-Netzwerk.

Beim ersten Start nutzt sie dafür unter anderem fest eingetragene DNS-Seeds, die erreichbare Nodes vermitteln. Anschließend erhält sie über ihre Peers weitere Adressen und baut ihren eigenen AddrMan auf.

2. Block-Header herunterladen

Anschließend lädt die Node zunächst die Block-Header von einem ihrer verbundenen Peers herunter. Da ein Header lediglich 80 Byte groß ist, kann sie sich so schnell einen Überblick über die bekannte Blockchain verschaffen.

Dabei überprüft sie, ob die Blöcke korrekt miteinander verkettet sind und ob jeder Header einen gültigen Proof-of-Work für das jeweilige Target besitzt. Aus allen bekannten gültigen Header-Ketten wählt sie anschließend diejenige mit der größten Chainwork aus.

3. Blöcke herunterladen und validieren

Nachdem die passende Header-Kette feststeht, fordert die Node die fehlenden Blöcke bei mehreren geeigneten Peers an. Dadurch können verschiedene Abschnitte der Blockchain parallel von unterschiedlichen Peers heruntergeladen werden. Antwortet ein Peer nicht zuverlässig, kann die Node die noch fehlenden Blöcke bei anderen Peers anfordern.

Jeder empfangene Block wird anschließend lokal nach den Konsensregeln überprüft. Dabei validiert die Node unter anderem den Proof-of-Work, die Coinbase-Transaktion, sämtliche Transaktionen, deren Signaturen und Scripts sowie die verwendeten UTXOs. Mehr zur Prüfung: Validation.

Erst wenn alle Prüfungen erfolgreich sind, wird der Block akzeptiert. Gespeicherte Blöcke kann die Node später wiederum an andere Peers ausliefern, die diese anfordern.

4. Chainstate aufbauen

Nach jedem gültigen Block aktualisiert die Node ihren Chainstate. Dabei entfernt sie ausgegebene UTXOs, fügt neu entstandene UTXOs hinzu und setzt den lokalen Chain-Tip auf den verarbeiteten Block.

So rekonstruiert sie Block für Block das aktuelle UTXO-Set und damit den gegenwärtigen Zustand des Bitcoin-Netzwerks.

Was passiert danach?

Sobald der aktuelle Chain-Tip erreicht ist, wechselt die Node in den normalen Betrieb. Von nun an empfängt sie neue Blöcke und Transaktionen, validiert sie lokal und gibt nur gültige Daten an ihre Peers weiter.