Ethereum-Vorschlag soll Block-Aufbewahrungsfenster auf 36 Tage verkürzen und Nodes entlasten
Wichtige Erkenntnisse
- •Der Entwurf sieht vor, die erforderliche Aufbewahrungsfrist für Blöcke der Konsensschicht von 33.024 Epochen (etwa 147 Tage) auf 8.192 Epochen (rund 36,4 Tage) zu verkürzen.
- •Der EIP ist nicht-forkend und informativ; er aktualisiert die Erwartungen an Node-Betreiber statt die Protokollregeln und soll die Backfill-Last nach einer Checkpoint-Synchronisierung verringern sowie die Anforderungen an Bandbreite, Speicherplatz und Synchronisierung senken.
- •Der Vorschlag befindet sich in der öffentlichen Überprüfung und erhält frühe Unterstützung von Contributor Dapplion und Lighthouse-Entwickler Michael Sproul; er wurde jedoch noch nicht gemergt und benötigt weiterhin eine offizielle EIP-Nummer.
- •Die Entwickler prüfen 66 Verbesserungsvorschläge für das Hegotá-Upgrade 2027, darunter Privatsphäre-Maßnahmen wie EIP-8141 Frame Transactions, der gemeinsame Shielded-Pool von EIP-8182 und die schlüsselbasierten Nonces von EIP-8250.
- •Bis Mitte August 2026 wurde nur EIP-7805 (FOCIL), ein Zensurresistenz-Mechanismus zur Durchsetzung von Transaktions-Inklusionslisten, für Hegotá bestätigt – vor dem Glamsterdam-Upgrade, das für das vierte Quartal 2026 geplant ist.

Der Ethereum-Entwickler Kevaundray Wedderburn hat am 17. August über den GitHub-Pull-Request #12188 einen neuen Ethereum-Improvement-Proposal-Entwurf eingereicht, der eine Verkürzung des Aufbewahrungsfensters für Blöcke der Konsensschicht (Consensus Layer, CL) fordert.
Der Vorschlag, der derzeit als Entwurf auf eine offizielle EIP-Nummer wartet, würde die erforderliche Aufbewahrungsfrist von 33.024 Epochen auf 8.192 Epochen – etwa 36,4 Tage – senken. Da jede Epoche der Konsensschicht 32 Slots von rund 6,4 Minuten umfasst, entspricht die aktuelle Anforderung etwa 147 Tagen – nahezu fünf Monaten – gespeicherter Historie. Der EIP ist als nicht-forkend und informativ eingestuft: Statt die Protokollregeln von Ethereum zu ändern, würde er die Erwartungen an Node-Betreiber aktualisieren.
Hauptziel der Änderung ist es, die Backfill-Last zu verringern, die nach einer Checkpoint-Synchronisierung entsteht – dem gängigen Verfahren, einen neuen Beacon-Node ausgehend von einem kürzlich zurückliegenden, vertrauenswürdigen Checkpoint zu starten, statt die Blockchain vom Genesis-Block aus erneut abzuspielen, und ältere Blöcke erst anschließend nachzuladen. Indem verkürzt wird, wie lange Nodes historische Beacon-Blöcke vorhalten müssen, würde der Vorschlag die Anforderungen an Bandbreite, Speicherplatz und Synchronisierungszeit senken – im Einklang mit dem seit langem erklärten Ziel von Ethereum, die Anforderungen an Nodes gering genug zu halten, um eine breite Beteiligung zu fördern. Der Entwurf greift zudem frühere Diskussionen aus der Execution Layer auf, etwa EIP-4444, der vorsah, dass Clients historische Blockdaten, die älter als ein Jahr sind, nicht mehr bereitstellen.
Der Entwurf befindet sich in der öffentlichen Überprüfung und hat frühzeitige Unterstützung aus der Entwickler-Community erhalten. Der Ethereum-Contributor Dapplion unterstützte die Richtung des Vorschlags, während der Lighthouse-Client-Entwickler Michael Sproul erklärte, für Lighthouse keine operativen Probleme vorauszusehen. Sproul ergänzte, dass in einem gemischten Netzwerk ältere Clients weiterhin von Peers synchronisieren könnten, die noch das längere Aufbewahrungsfenster vorhalten. Der Pull-Request wurde noch nicht gemergt; nächste Schritte wären die Vergabe einer offiziellen EIP-Nummer und – bei Annahme – abgestimmte Standard-Aufbewahrungseinstellungen über die Client-Implementierungen hinweg.
Entwickler prüfen 66 Vorschläge für das Hegotá-Upgrade 2027
Der Entwurf zum Aufbewahrungsfenster ist einer von mehreren Vorschlägen, die diese Woche in der Ethereum-Entwickler-Community kursieren, zumal die Aufmerksamkeit auch einem breiteren Vorstoß gilt, die Fähigkeiten von Ethereum auf Protokollebene vor dem geplanten Hegotá-Netzwerk-Upgrade 2027 auszubauen. Ethereum-Upgrades werden traditionell als Bündel ausgeliefert, und Kandidatenlisten dieser Größe werden üblicherweise ausgedünnt, je weiter technische Überprüfung und Audits fortschreiten.
Die Entwickler bewerten derzeit ein Paket von 66 Ethereum-Improvement-Proposals für Hegotá, von denen mehrere die On-Chain-Privatsphäre zum Ziel haben – ein Bereich, den das Netzwerk bisher Drittanbieterlösungen überlassen hat, weil Transaktionsdaten im öffentlichen Ledger standardmäßig für jedermann sichtbar sind.
Der zentrale Privatsphäre-Vorschlag ist EIP-8141, bekannt als „Frame Transactions“, der es Privacy-Pools ermöglichen würde, ihre eigenen Gasgebühren zu zahlen, ohne auf externe Relayer angewiesen zu sein. Da jede Interaktion mit einem Zwischendienst eine Metadaten-Spur erzeugt, die Absenderinformationen offenlegen kann, gilt die Beseitigung dieser Abhängigkeit als bedeutsamer Schritt in Richtung nativer Transaktions-Privatsphäre.
Ergänzend dazu würde EIP-8182 einen gemeinsamen Shielded-Pool für anonyme ETH- und ERC-20-Transfers einführen, während EIP-8250 schlüsselbasierte Nonces vorschlägt, um zu verhindern, dass Beobachter separate private Transaktionen über eine Analyse von Nonce-Mustern miteinander verknüpfen.
Von den überprüften Vorschlägen wurde bis Mitte August 2026 nur EIP-7805 (FOCIL), ein Zensurresistenz-Mechanismus zur Durchsetzung von Transaktions-Inklusionslisten, für Hegotá bestätigt. Die übrigen Vorschläge durchlaufen weiterhin technische Überprüfung und Sicherheits-Auditierung.
Hegotá soll auf das Glamsterdam-Upgrade folgen, das derzeit für das vierte Quartal 2026 geplant ist, was den Entwicklern rund ein Jahr lässt, um den Umfang des Pakets final festzulegen – einschließlich der Frage, welche der Privatsphäre-Vorschläge vorankommen.
Quelle: Metaverse Post