Zum Inhalt springen
Financial Context Wiki

Full Node (Vollknoten)

Verifikationsorientierter Leitfaden zu Full Nodes, Ethereum-Ausführungs- und Konsensclients, Sync-Checkpoints, aktuellem und historischem Zustand, Pruning, RPC-Datenschutz, Finalität und Betriebsdimensionierung.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Ein Full Node lädt die protokollseitig nötigen Daten, prüft Blöcke und Zustandsübergänge nach lokalen Konsens- und Ausführungsregeln, folgt der dadurch gewählten Chain und verwirft ungültige Peer-Daten ohne RPC-Delegation. „Full“ bezeichnet Prüfverantwortung, nicht ewige Zustandshistorie, Blockproduktion, Staking, öffentlichen API-Dienst oder Fehlerfreiheit.

Unter Ethereum Proof of Stake kombiniert er Ausführungs- und Konsensclient. Der erste prüft Transaktionen und Payloads, hält den Zustand und bietet JSON-RPC; der zweite prüft Konsensobjekte, Fork Choice, Rechtfertigung und Finalität. Ein Validatorclient ist nur für Vorschläge und Attestierungen mit gestaketen Validatoren nötig.

Funktionsweise

  1. Prüfziel und Snapshot festlegen: Protokoll, Chain, Genesis, Forks, chainId, aktuelle/finalisierte Hashes, Versionen, Sync, Checkpoint, Pruning, RPC, Historienhorizont und Uptime.
  2. Verifizierte Releases installieren. EL und CL über lokale authentisierte Engine API verbinden; Validator nur fürs Staking. Daten, Ports, RPC und Schlüssel trennen.
  3. Vom vorgesehenen Anchor starten. Full Sync prüft ab Genesis; Snap/Checkpoint startet authentisiert später und prüft weiter. Genesis, Checkpoint, Chain-ID, Fork-Digest und finalisierten Head unabhängig abgleichen.
  4. Beide Pipelines überwachen: Peers, Head-/Finalitätslag, Engine API, State Roots, Uhr, Disk, I/O, RAM, CPU, Fehler und Forkbereitschaft. „Synchronisiert“ erfordert Einigkeit und fortlaufenden Import.
  5. Aufbewahrung an Abfragen anpassen. Pruned Full Node hält aktuellen Zustand und genug Validierungsdaten, kann alte Zustände aber neu berechnen oder ablehnen. Archive materialisiert Historie. Light Client prüft schmalere Commitments und fordert Daten an.
  6. Kleinste RPC-Fläche öffnen. Admin und Engine lokal, Authentisierung, Firewall und Limits; Debug, Trace, Accounts oder Txpool nicht unkontrolliert veröffentlichen. latest, safe und finalized, Historie, Logs und Versand testen.
  7. Abgleichen und wiederherstellen. Hashes, Roots und Checkpoints mit zweitem Client vergleichen; Shutdown, Restore, Rebuild, Upgrade, Fork, Diskwechsel, Peerverlust und Failover proben. Verifizierte Ausgabe von externen Claims trennen.

Durchgerechnete Beispiele

  • Bandbreite. Ein Block je 12 seconds mit 150 kB ergibt 86,400 / 12 = 7,200 blocks/day und 7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day dezimal, vor Overhead. Das sind Planannahmen.
  • Diskreserve. Start 1.20 TB, Wachstum 18 GB/month, über 30 months: 1,200 + 18 * 30 = 1,740 GB. Mit 25% Reserve: 1,740 * 1.25 = 2,175 GB oder 2.175 TB.
  • Verfügbarkeit. In 30 days = 720 hours kosten Wartung 2 hours, CL-Ausfall 3 hours, Stromausfall 1 hour, ohne Überschneidung. Downtime 6 hours; (720 - 6) / 720 = 99.1666666667%. Laufend heißt nicht synchron.
  • Historischer Zustand. Snapshot 18,000,000, Ziel 18,250,000: 250,000 blocks Replay. Bei 500 blocks/second ideal 250,000 / 500 = 500 seconds = 8.3333333333 minutes, ohne I/O, Receipts, Reorg und Cache.

Risiken

  • Falsche Chain, Genesis, Forks oder chainId.
  • Bösartiger oder veralteter Checkpoint.
  • Veralteter Client beim Upgrade.
  • EL/CL-Divergenz oder Engine-Ausfall.
  • Clientbug liefert falsche Daten.
  • Monokultur mit korrelierten Fehlern.
  • Zu wenige, eclipsed oder bösartige Peers.
  • Uhrendrift.
  • Volle/langsame Disk oder Datenbankkorruption.
  • Uptime mit Sync/Finalität verwechseln.
  • Head, safe und finalized verwechseln.
  • Jede Historienabfrage von Pruning erwarten.
  • Offchain-Indizes im Archive voraussetzen.
  • Engine/Admin/Debug/Trace/Txpool exponieren.
  • Adressen, Abfragen oder Absicht leaken.
  • RPC verdrängt Validierungsressourcen.
  • Veraltetes/inkonsistentes Backup einspielen.
  • Schlüssel durch Co-Location verlieren.
  • Chain-Daten als Beweis externer Ehrlichkeit behandeln.
  • Ethereum-Modell auf andere Chains übertragen.

Häufige Irrtümer

  • Jeder Full Node ist ein dauerhaftes Archive.
  • Ein Full Node macht den Betreiber zum Validator.
  • „Synchronisiert“ garantiert richtige Finalität.
  • Eigenes RPC beseitigt alle Risiken.
  • Mehr Disk, Peers oder Uptime beweist Korrektheit.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...