EIP-4444: la sincronizzazione dei nodi Ethereum scende sotto mezza giornata
Punti chiave
- •L'EIP-4444 è stato attivato l'8 luglio 2025, consentendo ai client di esecuzione di Ethereum di eliminare i dati storici precedenti alla transizione a proof of stake di settembre 2022.
- •L'aggiornamento riduce i requisiti di archiviazione dei nodi da 300 a 500 GB e permette ai nuovi nodi di sincronizzarsi completamente in meno di mezza giornata, con alcune configurazioni che operano su meno di 0,5 TB di spazio totale.
- •Il meccanismo di partial history expiry prevedeva inizialmente circa 33.000 epoch di conservazione dei dati, poi riviste a circa 82.000 epoch, equivalenti a circa un anno di storia della catena.
- •Tutti e cinque i principali client di esecuzione di Ethereum — Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 e Reth v1.5.0 — hanno rilasciato il supporto alla funzionalità.
- •I nodi archivio, che servono le query storiche per block explorer e piattaforme di analisi, continueranno a conservare tutti i dati, mentre la Portal Network e soluzioni peer-to-peer simili sono progettate per mantenere recuperabile la storia potata durante la transizione.

In seguito all'attivazione dell'EIP-4444 l'8 luglio 2025, i client di esecuzione di Ethereum possono ora potare i dati storici creati prima del Merge — la transizione della rete a proof of stake di settembre 2022 — riducendo i requisiti di archiviazione da 300 a 500 GB e permettendo ai nuovi nodi di sincronizzarsi in meno di mezza giornata. Con impostazioni aggressive, gli operatori possono eseguire un nodo pienamente funzionale su un disco da 2 TB mantenendo lo spazio totale sotto 0,5 TB.
Cosa cambia realmente con l'EIP-4444
Il miglioramento ruota attorno a quello che viene definito "partial history expiry" (scadenza parziale della storia). Anziché richiedere a ogni nodo di conservare l'intera storia della blockchain di Ethereum l'EIP-4444 consente ai nodi di eliminare i dati più vecchi dopo un definito periodo di conservazione. Il progetto iniziale specificava circa 33.000 epoch — ognuna un'unità di tempo del consenso di 6,4 minuti — cifra successivamente rivista a circa 82.000 epoch, ovvero circa un anno di storia della catena.
La validazione della testa attuale della catena si basa su weak subjectivity checkpoint, stati recenti che i client ottengono da una fonte affidabile invece di verificare l'intera catena dal genesis. Il livello di consenso può tornare online in pochi minuti tramite il checkpoint sync, mentre il livello di esecuzione non ha più bisogno di scaricare e verificare un decennio di ricevute delle transazioni. Per gli operatori che richiedono l'accesso agli archivi, i meccanismi di recupero dei dati storici restano disponibili come funzionalità opzionale.
Tutti e cinque i principali client di esecuzione di Ethereum hanno rilasciato il supporto. Geth v1.16.0, Nethermind 1.32.2, Besu 25.7.0, Erigon v3.0.12 e Reth v1.5.0 includono tutti i flag e le configurazioni necessari.
Perché l'archiviazione stava diventando un problema
Prima dell'EIP-4444, un nodo completo richiedeva più di 400 GB di spazio su disco, e quella cifra seguiva una sola direzione. Ogni nuovo blocco, ogni interazione con smart contract e ogni trasferimento di token aggiungeva peso.
Va sottolineata una distinzione importante: la modifica riguarda i nodi completi e i validator, non i nodi archivio. I nodi archivio, che servono le query storiche per block explorer e piattaforme di analisi, continueranno a conservare tutto.
L'equazione dell'accessibilità
Una sincronizzazione in meno di mezza giornata su meno di 0,5 TB di archiviazione significa che una macchina consumer relativamente modesta con un buon SSD può partecipare alla rete di Ethereum. Per gli operatori, ciò si traduce nella possibilità di verificare transazioni e saldi sul proprio hardware invece di affidarsi a fornitori terzi. Si confronti ciò con i processi di sincronizzazione di più giorni e i requisiti di archiviazione oltre il terabyte che attendevano in passato i nuovi operatori di nod.
L'EIP-4444 rientra nella fase "Purge" della roadmap di Ethereum, che Vitalik Buterin ha descritto come incentrata sulla riduzione della complessità del protocollo e dei requisiti dei nodi.
La questione ancora aperta è come la rete gestirà il periodo di transizione, man mano che i nodi iniziano a potare i dati a ritmi diversi e la storia si distribuisce invece di restare replicata universalmente. La Portal Network e altre soluzioni peer-to-peer di data availability sono progettate per colmare questa lacuna, assicurando che le query storiche possano comunque essere soddisfatte anche quando la maggior parte dei nodi ha proceduto oltre.
Fonte: CryptoBriefing