Diese Ansicht zeigt die wichtigsten Komponenten meiner laufenden Full Node anhand von Live-Daten.
Über das P2P-Netzwerk ist die Node mit anderen Bitcoin-Peers verbunden und
tauscht Blöcke, Transaktionen und
Protokollnachrichten aus. Die dargestellten Verbindungen zeigen den lokalen
Netzwerkausschnitt, den die Node aktuell kennt.
Die Kurzlabels an den Verbindungen (z. B. Core, Knots, Pool, Scanner oder
Wallet) werden aus der beim Handshake gemeldeten
Subversion abgeleitet. Bitcoin Core meldet beispielsweise
/Satoshi:x.y.z/, Bitcoin Knots /Knots:x.y.z/. Die Darstellung ordnet bekannte Clients und Dienste diesen Kategorien
zu und ergänzt die aktuelle Latenz. So lässt sich erkennen, welche Arten von Software mit der Node verbunden sind, ohne
vollständige User-Agent-Strings oder Netzwerkadressen anzuzeigen.
Neben klassischen Full Nodes erscheinen gelegentlich auch Verbindungen von
Mining-Pools, Netzwerk-Scannern oder Kartierungsdiensten. Diese Systeme erfassen öffentlich
erreichbare Peers, messen deren Erreichbarkeit oder sammeln Netzwerkstatistiken. Solche Verbindungen
sind normal und zeigen, dass die Node Teil des öffentlichen Bitcoin-Netzwerks ist.
Im Relay-Bereich wird sichtbar, welche Informationen die Node empfängt und nach erfolgreicher
Prüfung an andere Peers weiterleitet.
Der Mempool enthält gültige, aber noch unbestätigte Transaktionen. Jede Node verwaltet ihren
eigenen Mempool und entscheidet anhand ihrer Regeln, welche Transaktionen sie
akzeptiert.
Der Chainstate bildet den aktuellen Zustand von Bitcoin ab. Er enthält alle
UTXOs und ermöglicht der Node, Transaktionen effizient zu
validieren, ohne die gesamte Blockchain
durchsuchen zu müssen.
Die Blockchain speichert die vollständige Historie aller bestätigten Blöcke und Transaktionen.
Neue Blöcke werden validiert, zur lokalen Blockchain hinzugefügt und
anschließend im Chainstateverarbeitet.
Zusammen zeigen diese Bereiche die zentralen Aufgaben einer Full Node: Netzwerkkommunikation,
Validierung, Weiterleitung von Daten sowie die Verwaltung des aktuellen Bitcoin-Zustands und
seiner Historie.
Peer-Verteilung
Die folgenden Live-Diagramme zeigen, mit welchen Peers meine Node aktuell verbunden ist. Links werden
die verbundenen Peers anhand ihrer gemeldeten Client-Kennung verschiedenen Software-Familien zugeordnet, beispielsweise
Bitcoin Core, Bitcoin Knots, Wallets, Scanner oder anderen Diensten. Rechts wird für Bitcoin Core und
Bitcoin Knots zusätzlich dargestellt, welche Versionen die verbundenen Peers melden. Grundlage dafür ist die
sogenannte Subversion, die ein Peer während des Verbindungsaufbaus übermittelt. Die Angaben stammen damit vom
jeweiligen Peer selbst und müssen nicht zwingend dessen tatsächliche Software widerspiegeln.
Mempool
Der Mempool dieser Node enthält gültige, aber noch unbestätigte Transaktionen. Die folgende
Live-Ansicht zeigt den lokalen Bestand: Fläche nach vSize, Farbe nach Fee-Rate. Werden Transaktionen in einen
Block aufgenommen, leuchten sie kurz lila und verlassen den Mempool.
Die Difficulty legt fest, wie viel Proof-of-Work für einen gültigen
Block nötig ist. Meine Node kennt den aktuellen Wert aus der lokal
validierten Kette und stellt ihn zusammen mit
Retarget-Metadaten live bereit.
Der Wert kommt direkt aus der Node (getdifficulty) und beschreibt den aktuellen Schwierigkeitsgrad des Netzwerks. Die
prozentuale Änderung darunter entspricht der Anpassung beim letzten
Retarget: Sie ergibt sich aus der gemessenen
Blockzeit der vorherigen 2016 Blöcke im Verhältnis zum Ziel von 600
Sekunden pro Block, begrenzt auf maximal das Vierfache bzw. minimal ein Viertel.
Aktuelles Target
Das Target ist die maximale Hash-Zahl, die ein
Blockheader noch erfüllen darf. Die Node liest bits aus dem Header
des Kettentips und dekodiert daraus den vollständigen 256-Bit-Wert (targetHex). Das Feld
nBits ist dieselbe Schwelle in kompakter Form, wie sie Miner im
Blockheader setzen.
Geschätzte Netzwerk-Hashrate
Bitcoin speichert keine Hashrate. Die Node schätzt sie aus aktueller
Difficulty und der durchschnittlichen Blockzeit der letzten 2016 Blöcke: Je kürzer die beobachtete Blockzeit bei
gleicher Difficulty, desto höher die abgeleitete Hashrate. Der Trend „letzte 24 Stunden“ vergleicht zwei Zeitfenster à
etwa 144 Blöcke miteinander.
Durchschnittliche Blockzeit
Gemessen wird die Zeitspanne zwischen dem Block bei Höhe Tip − 2015 und dem Kettentip, geteilt durch 2015 Intervalle.
Das entspricht dem Fenster, das Bitcoin für die nächste
Difficulty-Anpassung betrachtet. Liegt der Mittelwert über zehn Minuten,
steigt die Difficulty beim Retarget eher. Liegt er darunter, sinkt sie.
Letzte Difficulty-Anpassung
Gezeigt werden Blockhöhe und Zeitstempel des letzten
Retarget-Blocks (Höhe mod 2016 = 0). Die prozentuale Änderung wurde
dort gesetzt, als die Node die Dauer der abgeschlossenen 2016-Block-Periode mit dem 14-Tage-Ziel verglichen hat.
Nächste Difficulty-Anpassung
Verbleibende Blöcke bis zum nächsten Retarget: 2016 − (Tip mod 2016). Die geschätzte Restzeit extrapoliert die
bisherige durchschnittliche Blockzeit der laufenden Epoche. Die Prognose
simuliert, welche Difficulty-Änderung entstehen würde, wenn das aktuelle Tempo bis Block 2016 der Epoche anhält.
Aktuelle Blockhöhe
Die Höhe des zuletzt von der Node akzeptierten Blocks, also des lokalen Kettentips nach vollständiger
Validierung.
Difficulty-Epoche
Eine Epoche umfasst 2016 Blöcke zwischen zwei Retargets. Epoche n
beginnt nach Block (n − 1) × 2016. Der Zähler „Block k von 2016“ zeigt, wie viele Blöcke seit dem letzten Retarget
bereits gemined wurden.
Zielzeit
Konstante Regel des Netzwerks: langfristig durchschnittlich 600 Sekunden (10 Minuten) pro Block. 2016 Blöcke à 10
Minuten entsprechen etwa 14 Tagen. Daran orientiert sich jede
Difficulty-Anpassung.
Zeit seit Genesis Block
Differenz zwischen dem Zeitstempel des Kettentips und dem
Genesis Block (3. Januar 2009, Unix-Zeit 1231006505). Sie misst, wie lange die Kette nach
dem ersten Block bereits läuft.