Ein Full Node ist ein Programm, das Bitcoins Regeln selbstständig überprüft. Es läuft auf einem Computer, empfängt Blöcke und Transaktionen und prüft, welche in eine gültige Historie aufgenommen werden können. Mit einem eigenen Knoten musst du dich bei der Prüfung nicht auf Aussagen eines Miners oder fremden Servers verlassen. Damit auch deine Wallet davon profitiert, muss sie diesen Knoten tatsächlich als Datenquelle nutzen.
Stell dir vor, deine Wallet zeigt eine eingegangene Zahlung. Woher weiß sie, dass die Transaktion wirklich zur Bitcoin-Historie gehört und die Regeln erfüllt? Sie kann einen fremden Server fragen oder deinen eigenen Knoten nutzen. Ein Full Node macht die zweite Möglichkeit konkret: Er prüft anhand der empfangenen Daten selbst, was gültig ist. Er fragt nicht die Mehrheit der verbundenen Computer, wie er entscheiden soll. Schickt jemand einen regelwidrigen Block, lehnt er ihn ab. Mehr Verbindungen ersetzen daher keine Regelprüfung. Dein eigener Knoten lässt dich die Daten überprüfen, auf denen deine Zahlungen beruhen. [1] [3]
Der Knoten prüft die Verknüpfung der Blöcke, ihre Header und den Proof of Work, den für einen Block verlangten Rechennachweis. Bei Transaktionen prüft er unter anderem, ob sie auf vorhandene Mittel verweisen, diese nicht doppelt ausgeben und die Ausgabebedingungen erfüllen. Solche Bedingungen stehen in Skripten, kleinen programmatischen Regelwerken. Außerdem kontrolliert er die Menge neu erzeugter Bitcoin. Das fortlaufende Ergebnis ist das UTXO Set, die Menge noch nicht ausgegebener Transaktionsausgänge: eine Aufstellung der konkreten Mittel, die noch verwendet werden können. Mehr kumulierte Arbeit kann zwischen zwei gültigen Zweigen entscheiden, macht aber keinen ungültigen Block gültig. [1]
Nein. Ein Full Node überprüft Blöcke und Transaktionen und erhält für gewöhnliche Prüfung allein keine Blockbelohnung. Ein Miner baut dagegen einen Blockvorschlag und wiederholt Berechnungen, bis er einen passenden Wert findet. Dabei verwendet er einen Hash, den digitalen Fingerabdruck des Blockheaders. Die Rollen können zusammenarbeiten: Ein Miner muss wissen, welche Historie er fortsetzt und welche Transaktionen er aufnehmen darf. Daraus folgt aber nicht, dass jeder Knoten schürfen muss. Prüfung und Wettbewerb um den nächsten Block sind unterschiedliche Tätigkeiten. [5] [1]
Ein neuer Knoten muss zunächst die Netzwerkhistorie aufholen. Er lädt Blöcke herunter und verarbeitet ihre Daten; das nennt man die anfängliche Synchronisierung. Bei erweiterten Einstellungen sind zwei Beschleunigungen zu unterscheiden. Bitcoin Core kann mit assumevalid unter bestimmten Bedingungen alte Skriptprüfungen auslassen; assumevalid=0 schaltet diese Optimierung ab. AssumeUTXO erlaubt dagegen das Laden eines Snapshots, eines gespeicherten Bestands ungenutzter Mittel zu einem bestimmten Block. Dessen Fingerabdruck wird mit einem im Quellcode enthaltenen Wert verglichen. Die ältere Historie wird anschließend im Hintergrund überprüft. Ein nutzbarer aktueller Zustand allein beweist daher keine abgeschlossene historische Prüfung. [1] [2]
Ein Full Node muss nicht sämtliche alten Blockdateien für immer behalten. Pruning entfernt einen Teil davon nach der Verarbeitung, behält aber das aktuelle UTXO Set und notwendige neuere Daten. Neue Blöcke prüft der Knoten weiterhin. Ein Archivknoten behält alte Blöcke und kann sie anderen liefern oder erneut durchsuchen. Speicherersparnis ist deshalb nicht dasselbe wie ein SPV-Client, also ein Client mit vereinfachter Zahlungsprüfung. Dieser prüft nicht alle Transaktionen und ihren Zustand wie ein Full Node. Entscheidend ist, was überprüft wird, nicht nur die Zahl gespeicherter Dateien. [3]
Bei gewöhnlicher Synchronisierung lädt ein Pruned-Knoten historische Blöcke herunter und verarbeitet sie, bevor er sie nach und nach entfernen kann. Pruning ist also kein Schalter, mit dem die Prüfung alter Blöcke übersprungen wird. Es spart Speicherplatz. Die oben beschriebenen Optimierungen sind eine andere Frage: assumevalid kann unter bestimmten Bedingungen alte Skriptprüfungen auslassen, und AssumeUTXO lässt einen Snapshot verwenden, während die historische Prüfung noch läuft. Beurteile die Bereitschaft eines Knotens deshalb anhand des Synchronisierungsverfahrens und des tatsächlichen Fortschritts, nicht nur anhand seiner Datenmenge auf der Festplatte. [3] [2]
Eine Wallet braucht Informationen über Transaktionen und Bestätigungen. Holt sie diese von einem fremden Server, stellt sie ihm Anfragen, aus denen er etwas über ihre Zahlungen ableiten kann. Der Anschluss an deinen eigenen Full Node ermöglicht Daten, die dein Knoten geprüft hat, ohne diese Anfragen an den fremden Server. Installation und Start des Knotens verbinden die Wallet aber nicht automatisch damit. Entscheidend ist, welche Datenquelle sie tatsächlich unterstützt und verwendet. Ein eigener Knoten schafft auch nicht automatisch Anonymität: Privatsphäre hängt ebenso von weiteren Netzwerkdaten und der Nutzung der Wallet ab. [3] [4]
Ein Knoten kann ohne deine privaten Schlüssel arbeiten. Schlüssel erlauben es, Zahlungen zu signieren; der Knoten prüft, ob Transaktionen und Blöcke den Regeln entsprechen. Beide Aufgaben müssen nicht auf demselben Gerät liegen. Prüfe bei deiner Wallet deshalb nicht nur, ob irgendwo dein Knoten läuft, sondern auch, woher sie Daten bezieht und wie sie Transaktionen versendet. Eigene Prüfung ersetzt keine sichere Schlüsselsicherung und beseitigt nicht sämtliche Informationen, die Netzwerkkommunikation verraten kann. Sie hilft bei einem bestimmten Teil des Ablaufs: Bitcoin-Daten selbstständig zu kontrollieren. [3] [4]
Ein Knoten besitzt zwei verschiedene Schnittstellen. Über P2P-Verbindungen tauscht er Blöcke und Transaktionen mit anderen Knoten aus. RPC ist die Schnittstelle, über die Anwendungen Befehle erteilen und gegebenenfalls auch seine Wallet steuern. Einen eingehenden P2P-Port zum Datenaustausch zu öffnen ist daher etwas anderes, als RPC Fremden zugänglich zu machen. Bitcoin Core empfiehlt, RPC nicht direkt dem öffentlichen Internet auszusetzen. Für lokalen Zugriff verwendet es normalerweise Zugangsdaten in einer .cookie-Datei, die die Berechtigung der Anwendung nachweisen. Das ist kein Tracking-Cookie eines Webbrowsers. [4]
Mit Knotenbefehlen kannst du mehr als ein grünes Symbol prüfen. Achte in getblockchaininfo auf das richtige Netzwerk, blocks für verarbeitete Blöcke, headers für bekannte Header und initialblockdownload für den Stand der anfänglichen Synchronisierung. Bei einem Snapshot hilft getchainstates, den aktuellen Zustand von der historischen Prüfung im Hintergrund zu unterscheiden. Die Verbindungszahl allein belegt keine vollständige Prüfung. Kontrolliere zuletzt, ob der Knoten an einer veralteten Kettenspitze hängen geblieben ist und ob deine Wallet ihre Daten tatsächlich von ihm bezieht. Erst dann kommt seine unabhängige Kontrolle bei deiner Wallet-Nutzung an. [2] [1]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bitcoin, Timechain / Blockchain, Transaktion, UTXO, Proof of Work. Auf diesen Eintrag verweisen außerdem Bitcoin, Satoshi Nakamoto, Timechain / Blockchain, Proof of Work.