EIP-4444 verkürzt das Aufbewahrungsfenster von 33.024 auf 14.299 Epochen
Serguey Asael Shinder1 Min. LesezeitDas Repository der Ethereum Improvement Proposals hat eine Änderung an EIP-4444 übernommen, dem Vorschlag, nach dem Execution-Clients alte Kettenhistorie nicht mehr ausliefern müssen. Die Änderung senkt den Parameter HISTORY_PRUNE_EPOCHS von 33.024 auf 14.299 Epochen.
Nach EIP-4444 müssen Clients historische Block-Header, Blockinhalte und Receipts, die älter als dieses Fenster sind, auf der Peer-to-Peer-Ebene nicht mehr ausliefern und dürfen diese Daten lokal löschen. Der Vorschlag sagt ausdrücklich, dass das Abschalten gewollt ist: Wer die vollständige Historie braucht, soll sich andere Quellen suchen, statt sich auf Clients zu verlassen, die sie freiwillig ausliefern, was nach Ansicht der Autoren die Qualität mit der Zeit verschlechtern würde. Zudem soll die Änderung den Bandbreitenverbrauch im Netz senken.
Die Begründung für die Zahl selbst ist unverändert. Das Fenster soll weiterhin dem Aufbewahrungsfenster der Konsensschicht für Blöcke entsprechen, weil manche Konsens-Clients die Ausführungsdaten bei ihrem Execution-Client speichern und vollständige Beacon-Blöcke so lange ausliefern können müssen, wie das Konsensnetz sie verlangt. Dieses Fenster ist laut Text aus der maximalen Weak-Subjectivity-Periode abgeleitet und damit lang genug für Checkpoint-Sync, begrenzt aber den Speicherbedarf der Execution-Clients. Der übernommene Commit aktualisiert Zusammenfassung, Parametertabelle und Begründung auf den neuen Wert.
Was das bedeutet
Die Änderung ist eine Zahl in einer Spezifikation, legt aber fest, wie viel Historie jeder Node an andere ausliefern soll. Ein kürzeres Fenster heißt weniger Speicher und Bandbreite für Node-Betreiber und mehr Abhängigkeit von Archivanbietern, Portal-Netzwerken und Datendateien für alle, die ältere Blöcke brauchen. Weil der Wert an das Fenster der Konsensschicht gekoppelt ist und nicht unabhängig gewählt wird, ändert er sich wieder, sobald sich dieses Fenster ändert.