Was ist ein Blockchain-Node?
Ein Blockchain-Node ist eine laufende Software, die mit einem Blockchain-Netzwerk verbunden ist und Daten empfängt und verarbeitet. Technisch gesehen ist er eine konkrete Ausführung eines Client-Programms, die auf einem Heimrechner, einem Server oder einer Cloud-Instanz liegen kann. Ein Node ist keine bestimmte Spezialhardware und steht nicht zwangsläufig für eine eigene Person oder Organisation: Ein Rechner kann mehrere Nodes betreiben, und dieselbe betreibende Partei kann mehrere Rechner kontrollieren.
Die Kernaufgabe eines Nodes ist es, Netzwerkdaten nach den Protokollregeln zu verarbeiten, die seine lokale Software umsetzt. Er kann Transaktionen und Blöcke empfangen, prüfen, ob Daten dem Protokoll entsprechen, das Ledger oder den aktuellen Zustand speichern, gültige Daten an andere Nodes weitergeben und Wallets sowie Anwendungen Abfrageschnittstellen bereitstellen. Nodes übernehmen nicht dieselben Aufgaben, daher lässt sich „Node“ nicht unmittelbar mit Minern, Validierenden oder einem Server gleichsetzen, der alle historischen Daten speichert.
Wie ein Node an einer Transaktion mitwirkt
Von der Absendung durch eine Wallet bis zur Annahme durch das Netzwerk läuft eine Transaktion üblicherweise so ab:
- Die Wallet erstellt anhand der Nutzeraktion eine Transaktion und signiert sie mit dem passenden Autorisierungsverfahren.
- Die Wallet übergibt die Transaktion an den Blockchain-Node, mit dem sie verbunden ist. Dieser Node prüft zunächst die geltenden Regeln, etwa Format, Signatur, Guthaben, Transaktionsnummer oder Ausgabebedingungen.
- Nach erfolgreicher Prüfung kann der Node sie an andere Nodes weitergeben. Diese validieren sie dennoch selbst, statt ihr nur deshalb zu vertrauen, weil die sendende Seite sie bereits geprüft hat.
- Beteiligte mit Blockproduktionsaufgaben können Inhalte aus den ausstehenden Transaktionen auswählen und einen Kandidatenblock zusammenstellen.
- Nachdem andere validierende Nodes den Block erhalten haben, prüfen sie den Block und die enthaltenen Transaktionen und aktualisieren den von ihnen gespeicherten Ledger-Zustand nach den Konsens- und Fork-Choice-Regeln.
Dass ein Node eine Transaktion empfängt oder weitergibt, bedeutet daher nicht, dass sie bestätigt ist; und dass ein produzierender Node eine Transaktion in einen Kandidatenblock aufnimmt, bedeutet nicht, dass alle Nodes diesen Block annehmen. Jeder validierende Node kommt nach den von ihm ausgeführten Regeln zu seinem Ergebnis, und das Netzwerk entscheidet anschließend über seinen Konsensmechanismus zwischen gültigen Kandidaten.
Die vier Hauptaufgaben eines Nodes
Mit anderen Nodes verbinden und synchronisieren
Ein Node sucht und kontaktiert andere Nodes desselben Netzwerks, um von ihnen neue Blöcke, Transaktionen oder Zustandsinformationen zu erhalten. Ein gerade gestarteter Node muss sich außerdem auf den aktuellen Stand des Netzwerks synchronisieren. Die Synchronisationsmethode bestimmt, wo er mit dem Validieren beginnt, wie viele historische Daten er herunterlädt und was er behält; die Einzelheiten hängen von Netzwerk und Client-Software ab.
Netzwerkdaten eigenständig prüfen
Ein validierender Node wendet die Protokollregeln lokal an. Er kann prüfen, ob eine Transaktion korrekt autorisiert wurde, ob dasselbe Asset schon ausgegeben wurde, ob die Struktur eines Blocks gültig ist und ob der von einem Block referenzierte vorherige Verlauf den Fork-Choice-Regeln entspricht. Ein Node braucht keine Zustimmung der sendenden Seite, um ungültige Daten abzulehnen.
Diese eigenständige Prüfung kann nur belegen, dass Daten dem Protokoll entsprechen, nicht dass eine Aussage außerhalb der Blockchain zutrifft. War eine der Transaktion beigefügte Information aus der Welt von Anfang an falsch, kann ein Node das allein aus den Onchain-Regeln in der Regel nicht erkennen.
Ledger und aktuellen Zustand speichern
Ein Node kann Blöcke, Transaktionen, Kontoguthaben, nicht ausgegebene Transaktionsausgänge oder den Zustand von Smart Contracts speichern. Der Umfang hängt vom Netzwerk, vom Node-Modus und vom Einsatzzweck ab. Manche Nodes behalten die für die aktuelle Validierung nötigen Daten und löschen älteren Inhalt; andere speichern zusätzlich historische Zustände, sodass sich der Stand eines Kontos oder Contracts zu einem früheren Block abfragen lässt.
Mehr gespeicherte Daten bedeuten nicht mehr Konsensmacht. Ein Archivdienst kann mehr historische Abfragen beantworten, doch ob das Netzwerk einen Block annimmt, entscheiden weiterhin die Protokollregeln und die entsprechende Konsensbeteiligung.
Schnittstellen für Wallets und Anwendungen bereitstellen
Wallets, Block-Explorer und dezentrale Anwendungen müssen in der Regel bei einem Node Guthaben, Transaktionsstatus oder Blockdaten abfragen und reichen signierte Transaktionen ebenfalls über einen Node ein. Ein Node mit einer solchen Fernaufruf-Schnittstelle wird oft RPC-Node genannt, wobei RPC für „Remote Procedure Call“ steht: Andere Programme können den Node über eine vereinbarte Anfrage eine Abfrage oder Einreichung ausführen lassen.
Einen RPC-Dienst eines Drittanbieters zu nutzen ist nicht dasselbe wie einen eigenen Node zu betreiben. In diesem Fall kann der Anbieter sehen, woher Anfragen kommen und was abgefragt wird, und er kann auch verzögerte, fehlende oder falsche Daten zurückgeben. Ob eine Wallet das Ergebnis selbst validiert, hängt vom verwendeten Client und den Nachweismechanismen ab.
Unterschiede gängiger Node-Typen
„Full“, „Light“, „Archive“, „Validator“ und „RPC“ beschreiben verschiedene Dimensionen und sind keine feste Rangfolge von niedrig nach hoch. Ein Node kann mehreren dieser Kategorien gleichzeitig angehören.
| Bezeichnung | Hauptmerkmal | Was daraus nicht folgt |
|---|---|---|
| Full Node | Validiert empfangene Blöcke und Transaktionen eigenständig nach den Netzwerkregeln und hält das Ledger oder den Zustand vor, der zum Weitervalidieren nötig ist | Bedeutet nicht zwangsläufig, jeden historischen Zustand ab dem Genesis-Block dauerhaft zu behalten |
| Light Node oder Light Client | Lädt weniger Daten und nutzt Block-Header, kryptografische Nachweise oder andere Mechanismen, um von Full Nodes erhaltene Informationen zu prüfen | Heißt nicht, dass gar nicht validiert wird, und garantiert nicht dieselbe Datenverfügbarkeit wie bei einem Full Node |
| Archive Node | Behält über die vollständige Validierung hinaus mehr historische Blöcke oder Zustände, um Abfragen zu früheren Zeitpunkten zu beantworten | Erhält nicht automatisch mehr Stimmgewicht und ist nicht zwangsläufig für die Blockproduktion zuständig |
| Blockproduzierender Node | Führt Mining-, Validierungs- oder andere Produktionskomponenten aus und kann nach dem Protokoll an Blockvorschlag oder -bestätigung mitwirken | Nicht alle, die einen Node betreiben, können oder müssen diese Rolle übernehmen |
| RPC-Node | Stellt Wallets, Anwendungen oder Entwickelnden Schnittstellen zum Lesen von Daten und Einreichen von Transaktionen bereit | „Eine Schnittstelle bereitstellen“ sagt allein nichts darüber, ob vollständig validiert oder die gesamte Historie gespeichert wird |
Verschiedene Blockchains definieren diese Begriffe unterschiedlich. So bezeichnet die Node-Dokumentation von Bitcoin einen Node, der Blöcke herunterladen und validieren und Daten anschließend an andere Nodes weitergeben kann, als Full Node und unterscheidet dabei Archive Nodes mit vollständiger Historie von Pruned Nodes, die alte Blöcke löschen. Die Node-Dokumentation von Ethereum unterscheidet hingegen Full, Archive und Light Nodes, wobei ein Execution Client und ein Consensus Client zusammen einen aktuellen Ethereum-Node bilden. Beim Vergleich von Nodes sollte zuerst das konkrete Netzwerk und die Softwareversion geklärt werden, statt sich auf den Namen zu verlassen.
Nodes, Clients, Miner und Validierende
Ein Client ist die Software, die ein Blockchain-Protokoll umsetzt; ein Node ist eine Instanz dieser Software, die läuft und mit dem Netzwerk verbunden ist. Ähnlich wie ein Browser eine Softwarekategorie ist, während der aktuell auf einem bestimmten Rechner laufende Browser eine Instanz davon ist, hängen beide zusammen, sind aber nicht dasselbe.
Miner und Validierende tragen bestimmte Konsensaufgaben. Miner in einem Proof-of-Work-Netzwerk versuchen, Blöcke zu erzeugen, die die Anforderung erfüllen; Validierende in einem Proof-of-Stake-Netzwerk können Blöcke vorschlagen oder über sie abstimmen. Ein gewöhnlicher Full Node kann Blöcke validieren und regelwidrige Daten ablehnen, auch wenn er keine Blöcke produziert. Bei Ethereum etwa ist die Validator-Software eine Konsenskomponente, die zusätzlich zu einem Node hinzukommen kann, und nicht jeder Node, der das Netzwerk synchronisiert, betreibt Validierende.
Die Wallet wiederum hilft Nutzenden, Autorisierungsinformationen zu verwalten, Transaktionen zu erstellen und mit Nodes zu interagieren. Eine Wallet kann sich mit einem eigenen Node verbinden oder einen Node Dritter nutzen; Wallet-Oberfläche, Node und Konsensbeteiligte erfüllen jeweils unterschiedliche Aufgaben.
Nutzen und Kosten eines eigenen Nodes
Einen eigenen validierenden Node zu betreiben verringert die Abhängigkeit von Datenschnittstellen Dritter. Die betreibende Partei kann Blöcke und Transaktionen nach lokalen Regeln prüfen, lokale Daten direkt abfragen und vermeiden, jede Adressabfrage demselben externen RPC-Dienst zu überlassen. Nimmt der Node eingehende Verbindungen an oder beantwortet Datenanfragen, kann er auch anderen Beteiligten Netzwerkdaten liefern.
Dafür sind Speicherplatz, Netzwerkbandbreite, Rechenressourcen und laufende Pflege erforderlich. Die betreibende Partei muss das richtige Netzwerk wählen, Software aktuell halten, den Synchronisationsstand überwachen und Administrationsschnittstellen schützen. Softwarefehler, Fehlkonfiguration, Festplattenschäden oder der Verlust der Verbindung zu ehrlichen Nodes können lokale Ergebnisse weiterhin falsch oder veraltet machen.
Einen Node zu betreiben bringt auch nicht automatisch Blockbelohnungen. Ob Blöcke vorgeschlagen, Stimmen abgegeben oder Protokollbelohnungen erhalten werden können, hängt vom Konsensmechanismus des Netzwerks, den Eignungsbedingungen und davon ab, ob die entsprechenden Komponenten betrieben werden. Mehr Nodes verringern die Abhängigkeit von wenigen Betreibenden, erhöhen aber nicht automatisch Blockkapazität oder Transaktionsgeschwindigkeit; diese Größen sind zusätzlich durch Protokoll- und Netzwerkdesign begrenzt.
Was ein Node validieren kann
Validieren kann ein Node die vom Protokoll festgelegten digitalen Bedingungen, etwa Signaturen, Guthaben, Transaktionsformat und die Verkettung von Blöcken. Er kann nicht von sich aus feststellen, ob ein privater Schlüssel gestohlen wurde, ob Nutzende eine Transaktion verstanden haben, ob ein Smart Contract der Absicht der Nutzenden entspricht oder ob eine externe Datenquelle ein tatsächliches Ereignis gemeldet hat.
Das Urteil eines Nodes hängt außerdem von der Regelversion ab, die er ausführt, und von den Netzwerkdaten, die er gesehen hat. Ein Protokoll-Upgrade, ein vorübergehender Fork, ein Softwarefehler oder eine Netzabtrennung können dazu führen, dass verschiedene Nodes zeitweise zu verschiedenen Ergebnissen kommen. „Der Node hat es validiert“ ist daher als „dieser Node akzeptiert es nach seinen aktuellen Regeln und den ihm vorliegenden Daten“ zu lesen und nicht als von diesen Voraussetzungen losgelöster Beweis absoluter Richtigkeit.
Häufig gestellte Fragen
Ist jede Wallet ein Blockchain-Node?
Nein. Eine Wallet kann einen Node oder Light Client enthalten oder sich einfach mit einem RPC-Node Dritter verbinden. Zur Unterscheidung ist zu prüfen, ob die Wallet einen Protokoll-Client ausführt, welche Daten sie validiert und von welchen externen Diensten sie abhängt.
Speichert ein Full Node immer alle historischen Daten?
Nicht zwangsläufig. „Full“ betont üblicherweise die Fähigkeit, die vollständigen Validierungsregeln eigenständig anzuwenden; es bedeutet nicht zwangsläufig, alle historischen Zustände dauerhaft zu behalten. Manche Netzwerke erlauben Full Nodes, alte Daten nach der Validierung zu entfernen; für Abfragen beliebiger historischer Zustände kann dann ein Archive Node nötig sein.
Machen mehr Nodes Transaktionen schneller?
Nicht zwangsläufig. Mehr unabhängige Nodes können Redundanz und Widerstandsfähigkeit gegen einzelne Ausfallpunkte verbessern, doch jeder Node muss Daten weiterhin empfangen und validieren. Transaktionsdurchsatz und Bestätigungsgeschwindigkeit bestimmen vor allem Regeln wie Blockkapazität, Art der Blockproduktion, Konsens und Netzwerkverbreitung.
Kann man mit einem Node minen oder Staking-Belohnungen erhalten?
Nicht pauschal. Ein gewöhnlicher Node kann sich auf Synchronisieren, Validieren und Weitergeben beschränken. Mining- oder Validierungsaufgaben erfordern meist zusätzlich bestimmte Software, Hardware, einen hinterlegten Stake oder andere Protokollbedingungen.
Sind online angezeigte Node-Zahlen genau?
Meist sind sie nur Schätzungen. Nodes können hinter Router, Firewall oder privatem Netzwerk liegen und keine öffentlichen Verbindungen annehmen, und dieselbe betreibende Partei kann mehrere Nodes betreiben. Ein Netzwerk-Crawler sieht nur den Teil der Nodes, den er entdecken und kontaktieren kann.
Verwandte Begriffe
Lies weiter über Blockchain, Block, Krypto-Wallet und kryptografischer Hash, oder kehre zum Krypto-Glossar zurück.
Quellen
- NISTIR 8202: Blockchain Technology Overview — allgemeine Begriffe zu Nodes, Full Nodes, Lightweight Nodes und Blockchain-Netzwerken.
- Bitcoin Developer Guide: P2P Network — Full Nodes, Archive Nodes, Pruned Nodes sowie die Verbreitung von Transaktionen und Blöcken.
- Bitcoin Developer Guide: Operating Modes — Unterschied zwischen vollständiger Validierung und Clients mit vereinfachter Zahlungsprüfung.
- Ethereum.org: Nodes und Clients — Clients, Full Nodes, Archive Nodes, Light Nodes und Synchronisationsarten.
- Ethereum.org: Node-Architektur — Aufgabenteilung zwischen Execution Client, Consensus Client, Validierenden und RPC-Schnittstellen.
- Ethereum.org: Light Clients — Datenbezug, Validierungsumfang und externe Abhängigkeiten von Light Nodes.
© 2025 OKX. Dieser Artikel darf in seiner Gesamtheit vervielfältigt oder verbreitet oder es dürfen Auszüge von 100 Wörtern oder weniger dieses Artikels verwendet werden, sofern eine solche Nutzung nicht kommerziell erfolgt. Bei jeder Vervielfältigung oder Verbreitung des gesamten Artikels muss auch deutlich angegeben werden: „Dieser Artikel ist © 2025 OKX und wird mit Genehmigung verwendet.“ Erlaubte Auszüge müssen den Namen des Artikels zitieren und eine Quellenangabe enthalten, z. B. „Artikelname, [Name des Autors, falls zutreffend], © 2025 OKX.“ Einige Inhalte können durch künstliche Intelligenz (KI) generiert oder unterstützt worden sein. Es sind keine abgeleiteten Werke oder andere Verwendungen dieses Artikels erlaubt.
