Ethereum-Node in einem halben Tag synchronisieren: Was EIP-4444 verändert

Was sich bei Ethereum-Nodes grundlegend verändert hat

Ein eigener Ethereum-Node galt lange als Projekt für geduldige Betreiber: lange Synchronisationszeiten, hohe Anforderungen an SSD und I/O sowie stetig wachsender Speicherbedarf. Dieses Bild ist inzwischen überholt. Mit moderner Snapshot-Synchronisierung, konsequentem Pruning und der schrittweisen Umsetzung von EIP-4444 kann ein aktueller Full Node unter geeigneten Bedingungen innerhalb eines halben Tages einsatzbereit sein. Mit aggressiven Einstellungen lässt sich der belegte Speicher bei bestimmten Clients sogar unter 500 GB halten.

Das ist keine feste Zusage für jede Kombination aus Client, Hardware und Netzwerk. Die tatsächlichen Werte hängen insbesondere von NVMe-Leistung, Arbeitsspeicher, Bandbreite, gewähltem Execution Client und dessen Pruning-Strategie ab. Trotzdem ist die Richtung eindeutig: Einen selbst betriebenen Ethereum-Node zu starten wird deutlich schneller und günstiger.

Snap Sync statt vollständiger Wiedergabe seit Genesis

Ein klassischer Full Sync verarbeitet die gesamte Chain ab Genesis. Moderne Clients können stattdessen einen aktuellen Zustand beziehen, ihn kryptografisch verifizieren und anschließend nur noch bis zur Chain-Spitze aufholen. Das offizielle Ethereum-Snap-Protokoll überträgt Accounts und Contract Storage in Bereichen, ohne zunächst jeden dazwischenliegenden Trie-Knoten laden zu müssen.

Die Client-Teams haben diesen Ablauf in den vergangenen Jahren stark optimiert: parallele Downloads, bessere Datenbankzugriffe, effizienteres State-Healing und stabilere Pivot-Strategien reduzieren die Zeit bis zu einem nutzbaren Node. Eine schnelle CPU allein reicht dabei nicht. Für kurze Sync-Zeiten ist eine hochwertige NVMe-SSD oft der entscheidende Faktor.

EIP-4444: Geschichte bewahren, ohne sie auf jedem Node zu speichern

EIP-4444 begrenzt, wie lange Execution Clients alte Block-Header, Bodies und Receipts im Peer-to-Peer-Netz bereitstellen müssen. Daten außerhalb des vorgesehenen Fensters dürfen lokal entfernt werden. Sie sind nicht nötig, um neue Blöcke zu validieren.

Die Ethereum Foundation meldete 2025, dass alle Execution Clients eine partielle History Expiry unterstützen. Allein das Entfernen der Blockdaten vor dem Merge kann laut der offiziellen Ankündigung rund 300 bis 500 GB einsparen. Langfristig soll eine rollierende History Expiry verhindern, dass der Speicherbedarf eines normalen Nodes unbegrenzt mit der gesamten Historie wächst.

Dezentralisierung bedeutet nicht, dass jeder Node jede historische Information für immer lokal speichern muss. Entscheidend ist, dass aktuelle Zustände unabhängig verifiziert werden können und historische Daten über dafür geeignete Netze und Archive verfügbar bleiben.

Was Glamsterdam zusätzlich verbessern kann

Glamsterdam ist das nächste große Ethereum-Upgrade in Entwicklung. Ein wichtiger Baustein sind Block Access Lists: Sie beschreiben, auf welche Zustände ein Block zugreift. Dadurch können Clients Verarbeitung und Synchronisierung besser parallelisieren und Snapshot-Protokolle effizienter patchen. Das aktuelle Snap-Protokoll berücksichtigt diese Entwicklung bereits in seiner technischen Beschreibung.

Bei zukünftigen Verbesserungen lohnt sich allerdings ein genauer Blick auf den Status. Eine weitergehende EL/CL-Sync-Architektur unter EIP-8237 wurde laut dem Soldøgn-Interop-Bericht aus Glamsterdam herausgenommen und auf einen späteren Fork verschoben. Nimbus und andere Client-Teams experimentieren weiter mit neuen Sync-Ansätzen, doch nicht jede Entwicklung ist bereits Teil des finalen Glamsterdam-Umfangs.

Was Betreiber heute praktisch erwarten können

• Sync innerhalb eines halben Tages: auf schneller Hardware und mit einem gut optimierten Client realistisch, aber abhängig von Peers, Bandbreite und SSD.
• Unter 500 GB: mit History Pruning und aggressiver Konfiguration bei passenden Clients möglich; für Reserven und langfristigen Betrieb sollte mehr Speicher eingeplant werden.
• Keine vollständige Historie: ein pruned Full Node validiert die aktuelle Chain, kann aber alte RPC-Abfragen nicht beliebig beantworten.
• Client-Unterschiede: Geth, Nethermind, Besu, Erigon, Reth und Nimbus setzen unterschiedliche Schwerpunkte und Speicherstrategien.

Die offizielle Ethereum-Anleitung zum Betrieb eines Nodes empfiehlt weiterhin großzügigere Hardware-Reserven als ein experimentelles Minimal-Setup. Wer einen Node produktiv und über Jahre betreiben möchte, sollte nicht auf die knappstmögliche SSD dimensionieren.

Warum das für Ethereum wichtig ist

Je leichter ein Node gestartet werden kann, desto mehr Entwickler, Staker und Unternehmen können ihre Infrastruktur selbst verifizieren, statt sich vollständig auf zentrale RPC-Anbieter zu verlassen. Schnellere Synchronisierung senkt die Eintrittsbarriere, begrenzter Speicherbedarf reduziert die laufenden Kosten und verbessert die geografische sowie organisatorische Vielfalt des Netzwerks.

Die größte Veränderung ist deshalb nicht eine einzelne Rekordzahl. Es ist der Übergang zu einer Architektur, in der normale Nodes aktuell, verifizierbar und ressourceneffizient bleiben können, während historische Daten gezielt über spezialisierte Systeme verteilt werden. EIP-4444, Snap Sync und die Arbeit der Client-Teams machen Self-Hosting wieder deutlich alltagstauglicher.