Der Ethereum-State wächst unkontrolliert, was die Dezentralisierung gefährdet, weil Validatoren immer höhere Hardware-Anforderungen stemmen müssen. Der bevorstehende Hard-Fork Hegotá bietet die Möglichkeit, durch gezielte EIPs das State-Wachstum zu begrenzen, die Datenstrukturen zu optimieren und die Migration zu einem Partitioned Binary Tree (PBT) sicher zu gestalten.

Kernprobleme des Ethereum-States

• 94 % aller Schreibzugriffe betreffen Daten, die in den letzten 30 Tagen geändert wurden (Quelle S1).
• Die obersten 1 % der Accounts erzeugen 96-98 % aller Lesezugriffe (Quelle S1).
• Nur etwa 3 % des gesamten States sind im 30-Tage-Fenster aktiv (Quelle S1).
• Rund 62 % aller neu bereitgestellten Verträge duplizieren bereits vorhandenen Bytecode (Quelle S3).
• Im Schnitt werden täglich ca. 1.500 Accounts erstellt und im selben Transaction-Block wieder zerstört – das entspricht etwa 62 MiB Zustandswachstum pro Jahr (Quelle S4).

Diese Kennzahlen zeigen, dass ein kleiner Teil des States den Großteil der Aktivität ausmacht, während ein erheblicher Anteil dauerhaft ungenutzt bleibt.

EIP-8037: Einführung einer separaten State-Gas-Dimension

EIP-8037 definiert einen Cost per State Byte (CPSB), der jede State-erzeugende Operation proportional zu den geschriebenen Bytes belastet. Ziel ist ein klarer Budgetrahmen für das State-Wachstum. Sollte nach dem Vorgänger-Fork Glamsterdam ein Ungleichgewicht zwischen State-Gas und Execution-Gas auftreten, stehen zwei Korrektur-EIPs bereit:

• EIP-8372 führt eine einmalige Neukalibrierung des rohen State-Gas-Limits am Hard-Fork-Grenzpunkt durch.
• EIP-8368 passt das Limit an, wenn das Block-Gas-Limit erhöht wird, ohne das Grundmodell zu verändern.

Die Wahl zwischen diesen Optionen wird erst nach Beobachtung der tatsächlichen Nutzung nach Glamsterdam getroffen – ein evidenzgesteuerter Ansatz, der das Risiko unnötiger Änderungen minimiert.

Partitioned Binary Tree (EIP-8297) und Offline-Migration (EIP-8347)

Der Partitioned Binary Tree (PBT) ersetzt das aktuelle Merkle-Patricia-Trie (MPT) durch eine binäre Struktur, die kleinere Beweise und effizientere Zustandsnachweise ermöglicht. Der Code von Verträgen wird nach Inhalt dedupliziert, sodass identische Bytecodes nur einmal gespeichert werden.

EIP-8347 beschreibt eine offline Migration: Clients konvertieren den State zu einem finalisierten Anker-Block und nutzen anschließend Block Access Lists (BALs, EIP-7928), um Änderungen bis zum Aktivierungs-Fork nachzuspielen. Dieser Ansatz vermeidet eine vollständige Konvertierung am Fork-Zeitpunkt, macht jedoch die Verfügbarkeit vollständiger BALs zu einer kritischen Abhängigkeit.

• Legacy-Accounts vor Spurious Dragon: 28 Accounts besitzen Storage ohne Code und haben einen Nonce von 0 (EIP-8253).
• Legacy-Storage-Einträge: 129 Anomalie-Speicherplätze (EIP-8253).

Die Migration nutzt optional optionale Ausführungsnachweise (EIP-8025), um den Aufwand weiter zu reduzieren.

Block Access Lists (BALs, EIP-7928) – Schlüssel zur Offline-Migration

BALs enthalten jede Account-, Storage-, Code- oder Balance-/Nonce-Änderung, die ein Block berührt. Durch das Auslagern in ein separates Side-Car-Kanal (EIP-8146) erhalten Clients mehr Vorlaufzeit für das Prefetching und die Berechnung des State-Roots. Allerdings birgt die Migration das Risiko, dass BALs im P2P-Netzwerk verspätet oder unvollständig ankommen – ein Szenario, das den gesamten Migrationszeitplan gefährden kann (Counterpoint).

Reduzierung redundanter Bytecodes – EIP-8298 (SETCODEFROM)

EIP-8298 führt den Opcode SETCODEFROM ein, der bereits deployten Bytecode referenziert und damit doppelte Code-Speicherung verhindert. Da rund 62 % aller Contract-Deployments duplizierten Bytecode erzeugen, kann diese Maßnahme die State-Belastung signifikant senken, ohne zusätzliche Gas-Kosten zu verursachen.

Im Vergleich zu EIP-7819, das lediglich Delegierungen nach EIP-7702 aufheben kann, bietet EIP-8298 einen umfassenderen Nutzen, weil es die eigentliche Code-Duplikation adressiert.

State Tiering und Hot/Cold-Storage – Empirische Evidenz zu EIP-8188

Die Analyse von Hot-Cold Storage Separation in Practice (Quelle S2) liefert folgende Messwerte:

• 55 % aller initial geschriebenen Storage-Slots werden nach ihrer Erstellung nie wieder modifiziert (2026, Messgröße „Einmalig geschriebene Slots“).
• Durch das Auslagern inaktiver Leaves in Flat Files konnten Geth-Knoten mit PebbleDB die Live-Datenbank um 95,9 GB entlasten (2026, Messgröße „Entlastung der Live-Datenbank“).
• Der gesamte Festplattenspeicher wurde um 21,6 % komprimiert.

Diese Ergebnisse belegen ein enormes Entlastungspotenzial, das jedoch erst bei einem mehr-Terabyte-State voll zur Geltung kommt. EIP-8188 fügt jedem Account und Storage-Slot Metadaten zum letzten Schreib-Block hinzu – ein Feature, das im aktuellen PBT-Leaf-Format noch nicht abgebildet ist. Eine vorzeitige Aktivierung würde den Konvertierungspfad von EIP-8347 unnötig verkomplizieren. Deshalb wird empfohlen, State-Tiering nach der Trie-Migration zu prüfen und zunächst nur geringe Explorationen laufen zu lassen.

Weitere Risiken und Gegenmaßnahmen

• Abhängigkeit von BAL-Verfügbarkeit: Unvollständige oder verspätete BALs könnten die Offline-Migration blockieren.
• Permanenter Footprint von Keyed Nonces (EIP-8250): Starke Nutzung datenschutzorientierter Protokolle könnte zu dauerhafter Fragmentierung und Wachstum des States führen, bevor PBT-Zonen greifen.

Beide Punkte sollten kontinuierlich überwacht werden, um rechtzeitig Gegenmaßnahmen zu ergreifen.

FAQ zu den wichtigsten EIPs

Warum sollte EIP-8188 (State Tiering) nicht bereits in Hegotá aktiviert werden?

EIP-8188 fügt Accounts und Speicher-Slots Metadaten zum letzten Schreib-Block hinzu. Das aktuelle Leaf-Format des PBT kann diese Metadaten nicht darstellen. Eine Einführung vor der Migration würde zusätzlichen Konvertierungsaufwand erzeugen, während der Nutzen erst bei mehreren Terabyte State deutlich wird.

Was unterscheidet EIP-8298 von EIP-7819 bei der Account-Abstraction?

EIP-7819 kann Delegierungen nach EIP-7702 aufheben, während EIP-8298 den Opcode SETCODEFROM einführt, der bereits vorhandenen Bytecode referenziert und damit redundante Code-Speicherung bei etwa 62 % aller Deployments verhindert.

Wie fängt Hegotá Ungleichgewichte im neuen State-Gas-Modell (EIP-8037) ab?

Bei asymmetrischer Auslastung von State-Gas und Execution-Gas kann EIP-8372 das Kostenverhältnis pro Byte (CPSB) neu kalibrieren. Bei reinem Anheben des Block-Gas-Limits dient EIP-8368 zur Neuberechnung, sodass das State-Wachstum weiterhin im Zielbereich bleibt.

Fazit

Der Hard-Fork Hegotá stellt einen kritischen Wendepunkt für das Ethereum-State-Management dar. Durch die Einführung von EIP-8037 wird ein präziser Kostenmechanismus für State-Bytes geschaffen, der bei Bedarf über EIP-8372 oder EIP-8368 nachjustiert werden kann. Der Partitioned Binary Tree (EIP-8297) und die Offline-Migration (EIP-8347) bieten ein skalierbares Fundament, das jedoch stark von zuverlässigen Block Access Lists (EIP-7928) abhängt.

Redundante Bytecodes können mit EIP-8298 deutlich reduziert werden, während empirische Messungen zeigen, dass mehr als die Hälfte aller Storage-Slots nie wieder geändert werden. Das Potenzial von Hot/Cold-Storage (EIP-8188) ist beachtlich, jedoch erst bei einem sehr großen State voll nutzbar – ein Grund, die Aktivierung nach der Trie-Migration zu planen.

Insgesamt ermöglicht Hegotá, das State-Wachstum zu begrenzen, die Dezentralisierung zu erhalten und einen sicheren Übergang zu einer effizienteren Datenstruktur zu gewährleisten – vorausgesetzt, die genannten Risiken werden aktiv gemanagt und die Evidenz aus den ersten Messungen fließt in die Entscheidungsprozesse ein.