Woher die Daten kommen, wie sie erhoben werden, und was die Begriffe im Dashboard bedeuten.
Core Atlas bildet die live erreichbaren Nodes im Core-Blockchain-Netzwerk (XCB) auf einer Weltkarte ab und reichert sie mit Standort-, Anbieter- und Client-Informationen an. Alle Daten werden selbst erhoben und selbst gehostet – es fließen keine Daten an oder von Drittanbietern, außer den unten explizit genannten öffentlichen Diensten (MaxMind GeoIP-Datenbanken, Certificate-Transparency-Logs).
Über die admin_peers-RPC-Methode unserer eigenen Core-XCB-Node lesen wir aus, mit welchen Peers
sie aktuell direkt verbunden ist. Das erfasst auch Nodes, die selbst kein Discovery beantworten, aber
manuell als Static Peer verbunden wurden.
Für ein möglichst vollständiges Netzwerkbild nutzen wir das offizielle devp2p-Tool aus dem
go-core-Quellcode selbst (nicht nachgebaut) – das spricht das Kademlia-basierte Discovery-Protokoll
korrekt mit der Ed448-Kryptografie, die Core Blockchain verwendet. Ausgehend von den 17 offiziellen
Mainnet-Bootnodes wird das Netzwerk rekursiv durchsucht (FINDNODE/NEIGHBORS), um weitere Nodes zu finden.
Wichtige Einschränkung: Ein Crawler kann nur Nodes finden, die eingehend erreichbar sind (Discovery aktiv, Port freigegeben). Nodes hinter NAT ohne Portweiterleitung (z.B. viele Home-Nodes) bleiben unsichtbar, es sei denn, sie werden manuell als Static Peer verbunden.
Für jede gefundene Node führen wir zusätzlich einen echten RLPx-Verbindungsaufbau durch (TCP-Handshake,
ebenfalls über go-cores eigene Bibliotheken), um Client-Version, unterstützte Protokoll-Capabilities
(z.B. xcb/63, xcb/64) und die Antwortzeit (RTT) zu ermitteln.
IP-Adressen werden mit MaxMind GeoLite2 (City + ASN, lokal gehostete Datenbank, kein Live-Abruf pro Anfrage) zu Land/Stadt/Koordinaten sowie Hosting-Anbieter (z.B. "Hetzner Online GmbH") aufgelöst. Anhand bekannter Cloud-/Hosting-Anbieter-Namen wird zusätzlich geschätzt, ob eine Node bei einem Cloud-Anbieter oder bei einem "gewöhnlichen" ISP läuft.
Für jede IP wird ein Reverse-DNS-Lookup (PTR-Record) durchgeführt. Ergibt dieser einen Hostnamen, der nicht zu einem generischen Hosting-Provider-Namensschema gehört, wird zusätzlich bei crt.sh (öffentliche Certificate-Transparency-Logs) nach bekannten Subdomains dieser Domain gesucht.
| Begriff | Bedeutung |
|---|---|
| Online | Node war beim letzten Scan (≤30 Min) erreichbar und ist seit mehr als 30 Tagen bekannt. |
| Neu | Node war beim letzten Scan erreichbar, aber erst seit weniger als 30 Tagen bekannt. |
| Unbekannt | Node wurde schon einmal gesehen, hat aber beim letzten Scan (vor über 30 Min) nicht geantwortet. |
| Zuverlässigkeits-Score | Kommt direkt aus go-cores eigenem Crawler: steigt um 1 bei jeder erfolgreichen Wiedererkennung, halbiert sich bei jedem Ausfall. Höher = zuverlässiger über die Zeit gesehen. |
| RTT | Antwortzeit des RLPx-Handshakes in Millisekunden – ein grobes Latenz-/Erreichbarkeitsmaß, kein Ping im klassischen Sinn. |
| Cloud/Hosting-Anteil | Anteil der Nodes, deren Netzwerk-Anbieter (ASN) zu bekannten Cloud-/Hosting-Unternehmen gehört (Hetzner, OVH, AWS, u.a.) – ein grober Dezentralisierungs-Indikator. |