Nodes sind die Netzwerkknoten einer Blockchain. Sie tauschen Daten aus und übernehmen je nach Ausführung unterschiedliche Aufgaben. Full Nodes prüfen Blöcke und Transaktionen selbstständig. Wer einen eigenen Node mit seiner Wallet verbindet, kann dadurch kontrollieren, welche Zahlungen und welcher Netzwerkzustand nach den verwendeten Regeln gültig sind.
Was macht ein Blockchain-Node?
Ein Node ist eine laufende Instanz einer Netzwerksoftware, des sogenannten Clients. Er verbindet sich mit anderen Teilnehmern, den Peers, und verarbeitet die vorgesehenen Netzwerkdaten. Eine physische Maschine kann mehrere Node-Instanzen betreiben. Node-Anzahl, Gerätezahl und Zahl unabhängiger Betreiber sind deshalb unterschiedliche Größen.
Bei einer Blockchain hält ein Full Node einen überprüften Zustand des Systems vor. Bei Bitcoin gehört dazu das UTXO-Set, also die Menge noch nicht ausgegebener Transaktionsausgänge. Bei Ethereum umfasst der Ausführungszustand unter anderem Kontostände, Nonces, Programmcode und den Speicher von Smart Contracts.
Ein Node ist damit mehr als eine Datenkopie. Entscheidend ist, ob er Informationen selbst nach den Protokollregeln prüft oder lediglich Angaben eines Servers übernimmt. Der Bitcoin Developer Guide unterscheidet entsprechend zwischen vollständiger Validierung und vereinfachten Prüfverfahren.
Wie prüfen Nodes Transaktionen und Blöcke?
Eine Bitcoin-Transaktion muss unter anderem gültige Ausgabebedingungen erfüllen und auf verfügbare Inputs verweisen. Der Node prüft beispielsweise Signaturen, Beträge und zeitliche Beschränkungen. Bei einem neuen Block kommen Regeln für den Header, den Arbeitsnachweis, die Blockkapazität und die zulässige Ausgabe neuer Coins hinzu.
Bei Ethereum führt der Ausführungsclient die Transaktionen eines Blocks lokal aus. So berechnet er selbst, ob die behaupteten Änderungen an Konten und Smart Contracts korrekt sind. Eine vom Blockproduzenten angegebene Zustandswurzel ersetzt diese Ausführung nicht.
Mempool-Policy ist kein Konsensgesetz: Bitcoin-Nodes können für unbestätigte Transaktionen zusätzliche lokale Annahme- und Weiterleitungsregeln verwenden. Eine Transaktion kann deshalb am lokalen Gebührenfilter scheitern und später trotzdem Teil eines gültigen Blocks sein. Die Bitcoin-Core-Dokumentation zur Relay-Policy hält diese Trennung ausdrücklich fest.
Es gibt folglich keinen einzigen globalen Mempool. Verbindungen, Empfangszeitpunkte, Speichergrenzen und Policies bestimmen, welche unbestätigten Transaktionen eine einzelne Instanz vorhält.
Eine lokale Mempool-Ablehnung bedeutet nicht automatisch, dass eine Transaktion gegen die Konsensregeln verstößt. Das folgende Beispiel zeigt, weshalb derselbe Node einen späteren Block mit dieser Transaktion dennoch akzeptieren kann.
Full Node, Pruned Node, Archive Node und Light Client
Die Begriffe beschreiben teils die Prüfweise, teils die Datenspeicherung. Sie bilden keine einheitliche Rangliste. Insbesondere unterscheiden sich die Anforderungen an ein Bitcoin-Blockarchiv und ein Ethereum-Zustandsarchiv.
| Typ | Wesentliche Eigenschaft | Grenze oder Besonderheit |
|---|---|---|
| Full Node | Prüft neue Blöcke und die relevanten Zustandsänderungen selbst. | Muss nicht alle historischen Daten dauerhaft speichern. |
| Pruned Bitcoin-Node | Full Node, der ältere Blockdateien nach der Verarbeitung löscht. | Kann gelöschte Blöcke nicht an andere Peers ausliefern. |
| Archiv-Node | Hält zusätzliche historische Daten für spätere Abfragen bereit. | Bei Ethereum sind historische Zustände entscheidend, nicht nur alte Blöcke. |
| Light Client | Prüft ausgewählte Daten anhand von Headern und kryptografischen Nachweisen. | Führt nicht sämtliche Transaktionen wie ein Full Node aus. |
Pruning reduziert die Aufbewahrung, nicht den Anspruch an die laufende Validierung. Beim klassischen Bitcoin-Erstabgleich müssen die historischen Blöcke trotzdem heruntergeladen und verarbeitet werden. Der geringere dauerhafte Speicherbedarf bedeutet daher keinen entsprechend kleinen Erstdownload.
Ein Ethereum-Zustandsarchiv ermöglicht dagegen Abfragen wie: Welchen Tokenbestand hatte eine Adresse bei einem bestimmten alten Block? Ob solche Daten direkt verfügbar sind oder aufwendig rekonstruiert werden müssten, hängt vom Client und seiner Konfiguration ab.
Bitcoin-SPV-Clients können mit Merkle-Nachweisen die Aufnahme einer Transaktion in einen Block prüfen. Das beweist für sich genommen nicht die Gültigkeit sämtlicher Transaktionen dieses Blocks. Ethereum-Light-Clients nutzen andere, zum PoS-Protokoll passende Nachweise. Ihre Sicherheitsannahmen lassen sich nicht pauschal mit denen eines Full Nodes gleichsetzen.
Nodes, Miner und Validatoren: Wer entscheidet was?
Bei Proof of Work stellen Miner Blockkandidaten zusammen und suchen einen passenden Arbeitsnachweis. Full Nodes entscheiden unabhängig, ob sie einen angebotenen Block nach ihren Konsensregeln akzeptieren. Unter gültigen Bitcoin-Ketten bevorzugen sie diejenige mit der höchsten kumulierten Arbeit.
Eine Abstimmung nach dem Prinzip „ein Node, eine Stimme“ findet dabei nicht statt. Tausend zusätzlich gestartete Instanzen können einen regelwidrigen Block für einen anderen Full Node nicht gültig machen.
Bei Proof of Stake erhalten ausgewählte Validatoren Aufgaben wie Blockvorschläge und Abstimmungen. Die Gewichtung richtet sich nach dem jeweiligen Protokoll und dem eingesetzten Stake. Eine bloße Vermehrung gewöhnlicher Nodes erzeugt kein zusätzliches Stimmgewicht.
Protokolländerungen erfordern entsprechend kompatible Software und tatsächliche Akzeptanz durch die Beteiligten. Bei einem Hard Fork können unterschiedliche Regelwerke zu getrennten Netzwerken führen.
Warum ein Ethereum-Node aus mehreren Clients besteht
Ein regulärer Full Node auf Ethereum kombiniert einen Execution Client mit einem Consensus Client. Laut der Ethereum-Dokumentation zur Node-Architektur verarbeitet der Execution Client Transaktionen, führt die EVM aus und verwaltet den Ausführungszustand. Der Consensus Client verfolgt unter anderem Blockfolge und Finalisierung.
Beide kommunizieren über die Engine API. Zusätzlich verfügen sie über eigene Peer-to-Peer-Verbindungen für ihre jeweiligen Aufgaben. Erst die zusätzliche Validator-Funktion übernimmt eigene Blockvorschläge und Attestierungen.
Ein Ethereum-Full-Node ohne Validator benötigt deshalb keinen eigenen Staking-Einsatz. Er prüft das Netzwerk, erhält aber keine Validator-Belohnungen. Staking ist eine zusätzliche wirtschaftliche und technische Rolle mit eigenen Pflichten und Risiken.
Eigener Node oder fremder RPC-Anbieter?
Wallets benötigen Netzwerkdaten, etwa Kontostände, Bestätigungen oder Gebühreninformationen. Häufig beziehen sie diese über einen fremden Server. Bei Ethereum ist dafür JSON-RPC üblich, eine Schnittstelle für Abfragen und das Einreichen signierter Transaktionen.
Selbstverwahrung der Schlüssel und unabhängige Datenprüfung sind zwei verschiedene Eigenschaften. Wer seine Private Keys selbst kontrolliert, kann bei Kontoständen und Transaktionssimulationen trotzdem von einem einzelnen Anbieter abhängig sein.
Ein gewöhnlicher RPC-Anbieter kann ohne Schlüssel keine gültige Signatur für fremde Coins erzeugen. Er kann aber Anfragen auswerten, Daten verzögert liefern oder den Zugang beschränken. Mehrere unterschiedliche Endpunkte erhöhen nur dann die Ausfallsicherheit, wenn dahinter nicht dieselbe Infrastruktur steht.
Die Ethereum-Dokumentation zu Nodes und Clients nennt die eigene Wallet-Anbindung als Vorteil für Unabhängigkeit und Datenschutz. Dafür muss die Wallet tatsächlich den eigenen Node verwenden. Ein ungenutzter Node verbessert ihre Datenprüfung nicht automatisch.
Auch eine Wallet mit selbst verwahrten Schlüsseln kann Netzwerkdaten von einem fremden Anbieter beziehen. Die Grafik zeigt, wie sich die Kontrolle über die Datenprüfung verändert, wenn die Wallet tatsächlich mit dem eigenen Full Node verbunden ist.
Synchronisierung, Hardware und Betriebskosten
Beim ersten Start muss ein Node einen belastbaren Netzwerkzustand aufbauen. Je nach Blockchain und Client geschieht dies durch historische Verarbeitung oder beschleunigte Verfahren. Dabei sind Downloadumfang, dauerhaft gespeicherte Daten und selbst ausgeführte historische Prüfungen getrennt zu betrachten.
Geths Snap-Synchronisierung bezieht beispielsweise Zustandsdaten samt kryptografischen Nachweisen und baut daraus den lokalen Zustand auf. Auf der Konsensseite können Checkpoints für den Einstieg verwendet werden. Beschleunigung bedeutet deshalb nicht, dass alle Verfahren dieselben Startannahmen besitzen.
Für den Betrieb zählen neben CPU und Arbeitsspeicher besonders SSD-Leistung, freier Speicher, Datenbankwachstum und Internetanbindung. Ein privater Bitcoin-Node und ein stark abgefragter Ethereum-Archivserver sind deshalb keine vergleichbaren Hardwareprojekte. Maßgeblich bleiben die Anforderungen der gewählten Client-Version und Konfiguration.
Auch die Stromkosten lassen sich sauber abgrenzen: Ein hypothetischer Dauerverbrauch von 20 Watt entspricht rund 175 Kilowattstunden pro Jahr. Der Arbeitspreis pro Kilowattstunde ergibt daraus die Stromkosten. Hardware, Internet und Wartung kommen gegebenenfalls hinzu. Ein gewöhnlicher Bitcoin- oder nicht validierender Ethereum-Node zahlt dafür keine automatischen Protokollprämien.
Was Node-Zahlen über Dezentralisierung aussagen
Öffentlich erreichbare Node-Adressen zeigen nur einen Teil des Netzwerks. Instanzen hinter Firewalls oder privaten Verbindungen sind nicht immer vollständig erfassbar. Umgekehrt können viele sichtbare Adressen einem einzigen Betreiber gehören.
Für die Widerstandsfähigkeit zählen deshalb auch Betreiberverteilung, Hosting-Anbieter, geografische Standorte und Softwareabhängigkeiten. Die Ethereum-Dokumentation zur Client-Vielfalt beschreibt, wie unterschiedliche Implementierungen das Risiko gemeinsam auftretender Softwarefehler begrenzen können.
Vollständige Validierung schützt zudem nicht vor jeder Netzwerkmanipulation. Bei einem Eclipse-Angriff kontrolliert ein Angreifer die Verbindungen des Opfers und kann dessen Sicht auf neue Daten einschränken. Ungültige Signaturen werden dadurch nicht gültig, aber aktuelle Blöcke können dem Node vorenthalten werden.
Der praktische Maßstab: Ein eigener Node schafft unabhängige Prüfung nur für die Anwendungen, die seine überprüften Daten tatsächlich verwenden. Für die Netzwerksicherheit ist die Vielfalt unabhängiger Betreiber aussagekräftiger als eine isolierte Gesamtzahl von Instanzen.
Häufige Fragen zu Nodes
Muss ein Node meine Private Keys speichern?
Nein. Ein Node kann Netzwerkdaten prüfen, ohne Ausgabeschlüssel zu verwalten. Die Signierung kann beispielsweise auf einer getrennten Hardware-Wallet stattfinden. Ob eine Node-Software zusätzlich eine Wallet integriert, ist eine eigene Frage.
Ist eine Hardware-Wallet automatisch ein Full Node?
Nein. Sie schützt Schlüssel und signiert Transaktionen. Woher die zugehörige Wallet-Anwendung ihre Blockchain-Daten bezieht und wie diese geprüft werden, ist davon unabhängig.
Muss ein privater Node immer online sein?
Für die gelegentliche eigene Datenprüfung nicht zwingend. Nach einer Pause muss er fehlende Daten nachholen. Für Validatoren, Zahlungsdienste und andere dauerhaft verfügbare Anwendungen gelten dagegen zusätzliche Anforderungen.
KI-Hinweis: Dieser Artikel wurde mit Unterstützung künstlicher Intelligenz erstellt. Die technischen Angaben wurden anhand der verlinkten Primärquellen abgeglichen.
