Geth 1.17.7: Betreiber wählen selbst, ab welchem Block die Historie beginnt
Das go-ethereum-Team hat am 30. September Geth v1.17.7 veröffentlicht. Die Release Notes nennen es ein schnelles Release, vor allem nötig geworden, weil die Veröffentlichung von v1.17.6 im Ubuntu-Paketarchiv scheiterte; dazu kommen einige seither übernommene Korrekturen.
Für Validatoren zählt vor allem das Fork-Datum. Sowohl v1.17.6 als auch v1.17.7 sind bereit für das Amsterdam-Upgrade im Testnetz Sepolia am 6. Oktober 2026 – Sepolia-Betreiber können also jede der beiden Versionen nutzen.
Die wichtigste neue Option ist ein frei wählbarer Startpunkt für die Chain-Historie. Mit --history.chain <Blocknummer>:<Blockhash> legt ein Betreiber fest, wo die Historie beginnt. Das funktioniert beim Beschneiden eines bestehenden Knotens mit geth prune-history ebenso wie beim Snap Sync, der dann die Historie vor diesem Block nicht herunterlädt. Außerdem gibt es den vordefinierten Pruning-Punkt postosaka.
Mehrere Korrekturen betreffen Amsterdam-Funktionen. Der Miner berücksichtigt bei der Auswahl von Transaktionen nun sowohl Ausführungs- als auch State-Gas nach EIP-8037. Zugriffslisten auf Blockebene werden einmal in einer eigenen Pipeline kodiert und gehasht, nur nahe der Chain-Spitze abgerufen und nach dem State Sync angewendet, damit der Pivot von Snap Sync v2 weiterläuft.
Weitere Änderungen beheben ein Speicherleck beim Stoppen der Chain, geben Datenbank-Caches frei, wenn die Datenbank deaktiviert ist, überspringen Peers, deren gemeldeter Blockbereich eine Anfrage nicht abdeckt, erlauben den Neustart eines unterbrochenen Snap Sync mit gesetztem History-Cutoff und stellen einen Fallback des Transaktionspools beim Snap Sync wieder her, der seit v1.17.3 fehlte. Hinzu kommen fünf neue Bootnodes von NodeOps, und die Test-Fixtures wechseln auf execution-spec-tests v21.

Warum das wichtig ist
In Testnetz-Forks zeigen sich Client-Fehler, bevor sie das Mainnet erreichen. Ein Release zu nutzen, das das Client-Team für den Sepolia-Termin freigegeben hat, und vor dem 6. Oktober zu aktualisieren, verhindert, dass ein Validator den Fork verpasst. Die Pruning-Option ist für alle interessant, die auf lange laufenden Knoten Speicher sparen wollen.