Ethereums Hegotá-Fork: Wie Verkle-Trees den Node-Speicher um 90 % reduzieren und Stateless Clients ermöglichen könnten
Das Betreiben eines Ethereum-Full-Nodes im Jahr 2026 erfordert 4–8 TB NVMe-SSD-Speicher, 32–64 GB RAM und eine moderne Achtkern-CPU. Diese Hardwarekosten schließen Hobby-Nutzer aus, konzentrieren die Validierungsmacht bei finanzstarken Betreibern und untergraben im Stillen das Dezentralisierungsversprechen, das das gesamte Netzwerk rechtfertigt. Der Hegotá-Hard-Fork, der für Ende 2026 geplant ist, zielt darauf ab, diese Gleichung durch einen einzigen architektonischen Austausch zu ändern: den Ersatz des 15 Jahre alten Merkle-Patricia-Trie durch Verkle-Trees – eine kryptografische Datenstruktur, die den Speicherbedarf von Nodes um bis zu 90 % senken und "stateless" (zustandslose) Ethereum-Clients zum ersten Mal zur Produktionsrealität machen könnte.
Das Problem des State Bloat, das Ethereum nicht länger ignorieren kann
Der Ethereum-State – die vollständige Aufzeichnung jedes Kontostands, jedes Contract-Storage-Slots und jeder Nonce – ist auf über 200 GB angewachsen, und die gesamten Chain-Daten (einschließlich der Historie) überschreiten bei Geth mittlerweile 3 TB. Archive-Nodes benötigen 18–20 TB. Jede Transaktion erhöht diese Last, und nichts in der aktuellen Architektur reduziert sie.
Die Folgen sind messbar. Anfang 2026 erkennt Etherscan weltweit etwa 14.339 Full-Nodes. Die Vereinigten Staaten hosten 38,96 % davon, Deutschland 14,53 % und China 14,01 %. Home-Run-Nodes wuchsen zwar im Jahresvergleich um 18 %, aber die Einstiegshürde steigt stetig an. Ein Solo-Staker, der 2022 eine 2-TB-SSD gekauft hat, war bereits gezwungen aufzurüsten – oder aufzugeben.
Dies ist das Problem, das die "Verge"-Phase der Ethereum-Roadmap lösen soll. Und Verkle-Trees sind das technische Herzstück.
Was Verkle-Trees tatsächlich ändern
Im Kern sieht ein Verkle-Tree dem aktuellen Merkle-Patricia-Trie von Ethereum ähnlich. Beide sind baumförmige Datenstrukturen, bei denen jeder Knoten entweder leer ist, ein Blatt ist (das ein Schlüssel-Wert-Paar enthält) oder ein Zwischenknoten mit Kindknoten ist. Der entscheidende Unterschied liegt darin, wie sie beweisen, dass ein Datenelement im Baum existiert.
Merkle-Patricia-Trees verwenden Hash-basierte Beweise. Um einen einzelnen Wert zu beweisen, müssen Sie jeden Geschwisterknoten entlang des Pfades vom Blatt zur Wurzel angeben – den vollständigen Satz der "Nachbarknoten". Für den hexären (Breite 16) Trie von Ethereum bedeutet dies Beweisgrößen von etwa 150 KB pro Beweis. Wenn der State wächst, werden diese Beweise schwerfälliger.
Verkle-Trees verwenden Vektor-Commitments basierend auf polynomialer Kryptografie. Anstatt jeden Geschwisterknoten unabhängig zu hashen, generiert der Prover einen einzigen kompakten Beweis, der alle Eltern-Kind-Beziehungen entlang des gesamten Pfades abdeckt. Die vorgeschlagene Ethereum-Implementierung verwendet eine Breite von 256 (einige Forscher befürworten 1.024), was den Baum flacher und die Beweise dramatisch kleiner macht.
Die Zahlen sprechen für sich:
| Metrik | Merkle-Patricia-Trie | Verkle-Tree |
|---|---|---|
| Beweisgröße pro Wert | ~150 KB | ~1–2 KB |
| Witness-Daten für einen Block | Megabytes | Kilobytes |
| Baumbreite | 16 (hexär) | 256 |
| Beweisstruktur | Alle Geschwister-Hashes | Einzelnes polynomiales Commitment |
Ein Verkle-Tree kann die Zugehörigkeit in einem Baum mit einer Milliarde Datenpunkten mit weniger als 150 Bytes beweisen. Das aktuelle System benötigt unter idealen Bedingungen etwa 1 KB – und der Patricia-Trie von Ethereum ist weit von ideal entfernt.
Stateless Clients: Das Endspiel
Der eigentliche Preis sind nicht nur kleinere Beweise – es ist die zustandslose Validierung (Stateless Validation).
Heute muss jeder Ethereum-Full-Node den vollständigen State-Trie herunterladen, speichern und pflegen. Wenn ein neuer Block eintrifft, führt der Node jede Transaktion erneut gegen seine lokale Kopie des States aus, um die Korrektheit zu verifizieren. Ohne State keine Verifizierung.
Verkle-Trees ändern diese Gleichung. Da die Beweise kompakt genug sind, um in die Blöcke selbst aufgenommen zu werden, kann ein "Stateless Client" einen Block verifizieren, indem er nur den daran angehängten Verkle-Beweis prüft – ohne überhaupt einen State zu speichern. Der Validator empfängt den Block, prüft den Beweis gegen das Root-Commitment und bestätigt die Korrektheit in Millisekunden.
Was dies in der Praxis bedeutet:
- Nahezu null Speicher für Validatoren: Ein Staking-Node könnte mit minimalem Speicherplatz betrieben werden, potenziell unter 1 GB.
- Sofortiger Sync: Neue Nodes müssten nicht mehr über 200 GB an State herunterladen. Sie verifizieren Blöcke, sobald sie eintreffen.
- Breitere Beteiligung: Die Hardware-Hürde sinkt vom "dedizierten Server" auf einen "Raspberry Pi mit guter Bandbreite".
- Stärkere Dezentralisierung: Mehr Nodes bedeuten mehr geografische Verteilung, mehr Client-Diversität und mehr Resilienz gegen Zensur.
Vitalik Buterin hat Verkle-Trees als Schlüssel zur Ermöglichung von "Stateless Validator Clients" beschrieben, die eine nahezu sofortige Synchronisation erreichen. Wenn die Vision hält, könnte der Betrieb eines validierenden Ethereum-Nodes so einfach werden wie das Überprüfen einiger Kilobyte an Daten pro Block.
Der Quanten-Elefant im Raum
Nicht jeder ist davon überzeugt, dass Verkle-Trees eingeführt werden sollten. Der schwerwiegendste Einwand kommt aus der Community der Quantencomputer-Forscher.
Verkle-Trees basieren auf polynomialen Commitments auf Basis elliptischer Kurven – dieselbe Klasse von Kryptografie, die Quantencomputer mit Shors Algorithmus theoretisch knacken könnten. Wenn innerhalb des nächsten Jahrzehnts ein ausreichend leistungsfähiger Quantencomputer erscheint, würde jeder Verkle-Beweis auf Ethereum unglaubwürdig, und das Netzwerk bräuchte eine weitere Migration.
Dies hat eine aktive Debatte innerhalb der Ethereum-Entwicklergemeinschaft zwischen zwei Lagern ausgelöst:
Verkle-Trees jetzt einführen. Die Vorteile sind unmittelbar und gut verstanden. Quantencomputer, die in der Lage sind, Kryptografie auf Basis elliptischer Kurven zu brechen, sind wahrscheinlich noch 10–15 Jahre entfernt. Ethereum kann heute Verkle-Trees einführen und später auf quantenresistente Strukturen migrieren.
Direkt zu STARK-basierten binären Hash-Bäumen springen. EIP-7864 schlägt vor, den aktuellen Trie durch einen Binärbaum mit einer effizienten Hash-Funktion (Blake3 oder Poseidon) zu ersetzen. In Kombination mit STARK-Beweisen wäre dieser Ansatz vom ersten Tag an quantenresistent. Binärbäume erzeugen Merkle-Zweige, die viermal kürzer sind als die heutige Struktur, und ein Austausch der Hash-Funktion könnte die Effizienz der Beweisführung um das 3- bis 100-fache verbessern.
Der pragmatische Mittelweg – und die aktuelle Strategie – scheint die Einführung von Verkle-Trees in Hegotá zu sein, während gleichzeitig der Fortschritt beim Quantencomputing und die Leistung von STARK-Beweisen überwacht werden. Wenn STARK-basierte Alternativen schnell genug reifen, könnte ein zukünftiger Fork das Commitment-Schema austauschen, ohne die State-Migration zu wiederholen.
Hegotá im Kontext: Ethereums Upgrade-Rhythmus 2026
Hegotá stellt den zweiten großen Hard Fork des Jahres 2026 dar, nach Glamsterdam in der ersten Jahreshälfte. Dieser Zwei-Fork-Rhythmus spiegelt einen bewussten Wandel in der Entwicklungsphilosophie von Ethereum wider: kleinere, häufigere Upgrades anstelle der massiven, verzögerten Veröffentlichungen früherer Epochen.
Glamsterdam (H1 2026) konzentriert sich auf Verbesserungen der Ausführungsebene (Execution Layer): Gas-Optimierungen, Block-level Access Lists und Enshrined Proposer-Builder Separation (ePBS). Dies sind inkrementelle, aber wichtige Änderungen, die den L1-Durchsatz und die MEV-Handhabung verbessern.
Hegotá (H2 2026) zielt auf die Statusebene (State Layer) selbst ab. Verkle Trees sind der führende Kandidat für das Hauptfeature, obwohl auch Mechanismen für den Ablauf von Status und Historie (State and History Expiry) diskutiert werden.
Beide folgen auf die Upgrades von 2025 – Pectra und Fusaka –, die PeerDAS einführten und die Blob-Kapazität für Rollups erweiterten. Zusammen zeichnen diese vier Forks einen kohärenten Bogen: Blob-Speicherplatz für L2s, Gas-Effizienz für L1 und nun Status-Kompression für Node-Betreiber.
Die Benennungskonvention spiegelt diese Kontinuität wider. „Hegotá“ kombiniert „Bogotá“ (der Codename der Ausführungsebene, in Anlehnung an die Gastgeberstadt der Devcon 2022) und „Heze“ (der Codename der Konsensusebene, in Anlehnung an einen Stern). Jeder Ethereum-Fork seit dem Merge folgt diesem Stadt-plus-Stern-Muster.
Was sich für Node-Betreiber, Staker und Entwickler ändert
Solo-Staker werden am meisten profitieren. Die aktuellen Hardware-Mindestanforderungen – 32 GB RAM, 2+ TB SSD, dediziertes Internet – stellen eine finanzielle Hürde dar, die viele zu Liquid-Staking-Protokollen (Lido, Rocket Pool) oder zentralisierten Börsen drängt. Wenn Verkle Trees den Speicherbedarf auf unter 100 GB reduzieren, verschiebt sich die Ökonomie des Solo-Stakings grundlegend.
Node-Infrastruktur-Anbieter stehen vor einer anderen Kalkulation. Unternehmen, die Hunderte oder Tausende von Nodes betreiben, werden sinkende Hardwarekosten verzeichnen, müssen jedoch in Client-Updates und Migrations-Tests investieren. Der Übergang von Patricia Tries zu Verkle Trees erfordert eine einmalige Status-Konvertierung (State Conversion), die nicht scheitern darf – jeder Fehler bei der Migration könnte die gesamte Status-Datenbank von Ethereum korrumpieren.
DApp-Entwickler sollten keinen Unterschied in ihrem Smart-Contract-Code bemerken. Der State Trie ist eine Angelegenheit der Infrastrukturebene, die durch Client-Implementierungen abstrahiert wird. Entwickler, die Tools erstellen, die den Status von Ethereum direkt abfragen (Block-Explorer, Analyseplattformen, MEV-Searcher), müssen jedoch ihre Logik zur Proof-Verifizierung aktualisieren.
L2-Rollups profitieren indirekt. Kleinere Status-Proofs auf L1 bedeuten eine günstigere Status-Verifizierung für Rollups, die Proofs an Ethereum senden. Dies verstärkt die Kostensenkungen, die bereits durch EIP-4844-Blobs erreicht wurden, und könnte die L2-Kosten pro Transaktion potenziell unter $ 0,0001 senken.
Das Migrationsrisiko
Der schwierigste Teil von Verkle Trees ist nicht die Kryptografie – es ist die Migration.
Ethereum kann Datenstrukturen nicht einfach in einem einzigen Block austauschen. Der gesamte State Trie – jedes Konto, jeder Vertrag, jeder Speicherplatz – muss vom Merkle-Patricia-Format in das Verkle-Format konvertiert werden. Dies ist eine Multi-Gigabyte-Transformation, die während des Hard Forks atomar über alle Clients, alle Validatoren und alle Nodes gleichzeitig erfolgen muss.
Frühere Ethereum-Upgrades haben die Art und Weise verändert, wie Daten verarbeitet werden, aber keines hat die Struktur der Datenspeicherung auf dieser fundamentalen Ebene verändert. Die engste Analogie ist der Merge selbst, der den Konsensmechanismus von Proof-of-Work auf Proof-of-Stake umstellte – aber der Merge hat den State Trie nicht berührt.
Client-Teams (Geth, Nethermind, Besu, Erigon, Reth) bauen bereits Migrations-Tools und führen Testnet-Konvertierungen durch. Der Hegotá-Zeitplan gibt ihnen etwa sechs bis neun Monate Testzeit ab dem Zeitpunkt, an dem die Features festgelegt sind. Angesichts der Tragweite könnte dies das am intensivsten geprüfte Upgrade in der Geschichte von Ethereum werden.
Ausblick: Von Verge zu Purge
Verkle Trees sind nicht das Endziel. Sie sind die Wegbereiter-Technologie für die nächste Phase der Ethereum-Roadmap: den Purge.
Sobald Stateless Clients live sind, kann Ethereum alte Status-Daten sicher ablaufen lassen, ohne die Netzwerksicherheit zu gefährden. Nodes müssten keine jahrelangen historischen Status-Daten mehr speichern – sie könnten neue Blöcke nur unter Verwendung des aktuellen Status-Roots und der Verkle-Proofs verifizieren. Dieser „State Expiry“-Mechanismus würde den Speicherbedarf von Ethereum dauerhaft begrenzen, unabhängig davon, wie viele Transaktionen das Netzwerk verarbeitet.
In Kombination mit dem Ablauf der Historie (History Expiry, EIP-4444), der es Nodes ermöglicht, Block-Bodies und Quittungen (Receipts) zu verwerfen, die älter als ein konfigurierbarer Schwellenwert sind, könnte die gesamte Verge-to-Purge-Pipeline die Anforderungen an eine Ethereum-Node so weit reduzieren, dass sie auf ein Smartphone passt.
Das ist noch Jahre entfernt. Aber Hegotá macht, wenn es wie geplant veröffentlicht wird, den wichtigsten Schritt: den Beweis, dass Ethereum seine Statusebene grundlegend umstrukturieren kann, ohne das Netzwerk zu unterbrechen.
BlockEden.xyz betreibt leistungsstarke Ethereum RPC-Nodes und API-Infrastruktur und bietet Entwicklern zuverlässigen Zugang zum Netzwerk, während es sich durch Upgrades wie Hegotá weiterentwickelt. Entdecken Sie unsere Ethereum API-Dienste, um auf einer Infrastruktur aufzubauen, die für die Zukunft gerüstet ist.