NieuwsCryptoEthereum-nodesynchronisatie teruggebracht naar minder dan een halve dag met EIP-4444-optimalisaties

Ethereum-nodesynchronisatie teruggebracht naar minder dan een halve dag met EIP-4444-optimalisaties

Auteur: CryptoBriefing·

Belangrijkste punten

  • •EIP-4444 werd geactiveerd op 8 juli 2025, waardoor Ethereum execution-clients historische gegevens van vóór de overgang naar proof of stake in september 2022 mogen verwijderen.
  • •De upgrade verlaagt de opslagbehoefte van nodes met 300 tot 500 GB en stelt nieuwe nodes in staat om in minder dan een halve dag volledig te synchroniseren, waarbij sommige configuraties draaien op minder dan 0,5 TB totale opslag.
  • •Het partial history expiry-mechanisme richtte zich aanvankelijk op ongeveer 33.000 epochs aan gegevensbewaring voordat het werd herzien naar ongeveer 82.000 epochs, gelijk aan circa één jaar ketengeschiedenis.
  • •Alle vijf de grote Ethereum execution-clients — Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 en Reth v1.5.0 — hebben ondersteuning voor de functie uitgebracht.
  • •Archiefnodes die historische query's verzorgen voor blockexplorers en analyseplatformen blijven alle gegevens opslaan, terwijl het Portal Network en vergelijkbare peer-to-peer-oplossingen zijn ontworpen om verwijderde geschiedenis tijdens de overgang ophaalbaar te houden.
Ethereum-nodesynchronisatie teruggebracht naar minder dan een halve dag met EIP-4444-optimalisaties

Na de activering van EIP-4444 op 8 juli 2025 kunnen Ethereum execution-clients nu historische gegevens van vóór de Merge verwijderen — de overgang van het netwerk naar proof of stake in september 2022 — waardoor de opslagbehoefte met 300 tot 500 GB daalt en nieuwe nodes in minder dan een halve dag kunnen synchroniseren. Met agressieve instellingen kunnen operators een volledig functionerende node draaien op een schijf van 2 TB, met een totale opslag van minder dan 0,5 TB.

Wat EIP-4444 werkelijk verandert

De verbetering draait om wat bekend staat als “partial history expiry”. In plaats van van elke node te eisen dat deze de volledige geschiedenis van de Ethereum-blockchain opslaat, staat EIP-4444 nodes toe oudere gegevens te verwijderen na een gedefinieerde bewaarperiode. Het oorspronkelijke ontwerp specificeerde grofweg 33.000 epochs — elk een consistenciperiode van 6,4 minuten — een cij dat later werd herzien naar ongeveer 82.000 epochs, oftewel zo'n één jaar aan ketengeschiedenis.

De validatie van de huidige ketenkop leunt op weak subjectivity checkpoints: recente toestanden die clients van een vertrouwde bron overnemen in plaats van de hele keten vanaf het begin te verifiëren. De consensuslaag kan binnen enkele minuten online komen via checkpoint sync, terwijl de execution-laag niet langer tien jaar aan transactieontvangsten hoeft te downloaden en verifiëren. Voor operators die archieftoegang nodig hebben, blijven mechanismen voor het ophalen van historische gegevens beschikbaar als optionele functie.

Alle vijf de grote Ethereum execution-clients hebben ondersteuning uitgerold. Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 en Reth v1.5.0 bevatten elk de nodige vlaggen en configuraties.

Waarom opslag een probleem werd

Vóór EIP-4444 had een full node meer dan 400 GB aan schijfruimte nodig, en dat cijfer ging slechts in één richting. Elk nieuw blok, elke slimme contractinteractie en elke tokentransfer voegde toe aan de stapel.

Er geldt een belangrijk onderscheid: de wijziging raakt full nodes en validators, niet archiefnodes. Archiefnodes, die historische query's verzorgen voor blockexplorers en analyseplatformen, blijven alles blijven opslaan.

De toegankelijkheidsvergelijking

Een synchronisatie van minder dan een halve dag op minder dan 0,5 TB aan opslag betekent dat een relatief bescheiden consumentenmachine met een degelijke SSD kan deelnemen aan het Ethereum-netwerk. Voor operators betekent dit dat ze transacties en saldi verifiëren op hun eigen hardware in plaats van afhankelijk te zijn van externe aanbieders. Dat staat in contrast met de synchronisatieprocessen van meerdere dagen en opslageisen van meer dan een terabyte die nieuwe node-operators eerder te wachten stonden.

EIP-4444 valt binnen de “Purge”-fase van Ethereums roadmap, die Vitalik Buterin omschreef als gericht op het verminderen van protocolcomplexiteit en nodevereisten.

De openstaande vraag is hoe het netwerk de overgangsperiode hanteert nu nodes in verschillend tempo beginnen te prune-en en historische gegevens verspreid raken in plaats van universeel gerepliceerd te worden. Het Portal Network en andere peer-to-peer-oplossingen voor databeschikbaarheid zijn ontworpen om dit gat te vullen, zodat historische query's nog kunnen worden beantwoord, zelfs wanneer deeste nodes zijn doorgegaan.

Bron: CryptoBriefing