Aggiornamento Fusaka: la più grande scommessa di scalabilità per Ethereum

Letto: 50

Il prossimo aggiornamento di Ethereum, denominato Fusaka e previsto per dicembre 2025, introdurrà significative modifiche sia al livello di esecuzione che a quello di consenso della rete. L’aggiornamento, abbreviazione di “Fulu-OSAKA”, è progettato per espandere la capacità dei dati, migliorare le difese contro gli attacchi di negazione del servizio e introdurre nuovi strumenti per sviluppatori e utenti.

Fusaka rappresenta una tappa importante per la rete Ethereum dopo la fusione del 2022. Gli aggiornamenti precedenti, come Shanghai/Shappera nel 2023, Denkun nel 2024 e Pectra nel 2025, hanno introdotto rispettivamente i prelievi di ETH in staking, lo sharding e i blob di protodunk, e la flessibilità del validatore e l’interoperabilità di livello 2.

L’aggiornamento Fusaka si propone di riprogettare il modo in cui Ethereum gestisce la disponibilità dei dati, i prezzi dei blob e le garanzie delle transazioni. Il successo dell’aggiornamento sarà misurato dalla capacità della rete di scalare per soddisfare le richieste del livello 2 senza gravare o interrompere gli operatori dei nodi.

La caratteristica principale di Fusaka è PeerDAS, un nuovo modo di elaborare i dati BLOB. PeerDAS sta per “Data Availability Sampling”.

I BLOB sono pacchetti di dati temporanei introdotti in proto-danksharding come parte dell’aggiornamento di Dencun. Consentono ai rollup di livello 2 di pubblicare a basso costo grandi quantità di dati transazionali sulla mainnet, aumentando la scalabilità senza gonfiare permanentemente lo stato della blockchain.

Attualmente, ogni nodo completo su Ethereum memorizza ogni “blob” di dati di livello 2 pubblicati sulla catena, creando un collo di bottiglia con l’aumento della domanda.

PeerDAS modifica questo processo. Ogni nodo memorizza solo una parte dei dati BLOB (circa un ottavo) e si affida alla ricostruzione crittografica per riempire le parti mancanti. Questo progetto si basa sul campionamento casuale per verificare la disponibilità dei dati con una probabilità di errore estremamente bassa.

Distribuendo lo spazio di archiviazione in questo modo, Ethereum potrebbe teoricamente supportare fino a 8 volte più throughput blob senza richiedere hardware o larghezza di banda più elevati da parte degli operatori dei nodi. Si prevede che i rollup che si basano sui BLOB per esporre i dati transazionali compressi trarranno i vantaggi più diretti.

Fusaka reinventerà inoltre il modo in cui vengono prezzati e gestiti i dati BLOB. L’EIP-7918 introduce tariffe per la prenotazione dei BLOB. Con le regole attuali, i prezzi BLOB possono crollare vicino allo zero quando le commissioni sul gas di esecuzione diventano dominanti, incentivando un uso inefficiente. Con le tariffe di prenotazione, è sempre previsto un costo di base per l’uso dei BLOB e le reti di livello 2 pagano per lo spazio di archiviazione e la larghezza di banda che consumano.

Un altro meccanismo, EIP-7892, introduce un fork di soli parametri BLOB, consentendo ai client Ethereum di regolare il throughput del blob al di fuori di un hard fork completo. L’obiettivo è consentire agli sviluppatori di rispondere agilmente alle imprevedibili richieste del Livello 2 senza attendere il successivo aggiornamento programmato.

Fusaka include una serie di modifiche per limitare gli scenari peggiori e proteggere la rete dagli attacchi di negazione del servizio. **EIP-7823** limita la dimensione di input per le operazioni MODEXP a 8192 bit. **EIP-7825** imposta il limite di carburante per transazione su 2²4 unità. **EIP-7883** aumenta il costo del gas per esponenti MODEXP di grandi dimensioni. **EIP-7934** limita la dimensione del blocco di esecuzione a 10 MB.

Queste modifiche riducono il rischio che transazioni estreme o blocchi eccessivi possano sovraccaricare i client, bloccare la propagazione o causare instabilità.

Fusaka mira anche a migliorare l’usabilità. Per gli utenti, EIP-7917 introduce il supporto pre-controllo, consentendo ai portafogli e alle applicazioni di anticipare il programma del proponente e garantire agli utenti di sapere che le loro transazioni appariranno nel blocco successivo. Il risultato è una latenza inferiore e una minore incertezza sugli include.

Per gli sviluppatori, Fusaka aggiunge due caratteristiche degne di nota: il codice operativo CLZ (contando gli zeri iniziali) e EIP-7951, che fornisce la verifica della firma nativa secp256r1 (P-256). Si tratta di una curva ellittica comune utilizzata nei dispositivi hardware e nei sistemi mobili e la sua aggiunta migliora la compatibilità e l’astrazione dell’account.

Questi cambiamenti hanno lo scopo di ridurre l’onere per gli sviluppatori di applicazioni e aprire la strada a nuovi design di portafogli e modelli di sicurezza.

Per gli utenti quotidiani di Ethereum, Fusaka non dovrebbe richiedere alcuna azione. Il saldo del tuo account, i token e le applicazioni continueranno a funzionare come prima. Ethereum.org sottolinea che gli utenti dovrebbero ignorare le truffe che chiedono loro di “aggiornare” o trasferire ETH, poiché non esiste tale necessità.

L’onere spetta ai validatori e agli operatori dei nodi aggiornare gradualmente i propri client di esecuzione e consenso. L’adeguamento rimane un processo delicato, poiché la mancata sincronizzazione dei validatori può comportare tempi di inattività della rete o un’interruzione temporanea della catena.

Dopo una serie di attivazioni di testnet riuscite, l’aggiornamento Fusaka dovrebbe essere introdotto sulla mainnet di Ethereum il 3 dicembre 2025.

Fusaka rappresenta uno dei passi più audaci nella roadmap di Ethereum dopo la fusione. Si tratta di un tentativo di fornire maggiore capacità blob, difese più forti e nuovi strumenti per sviluppatori in un’unica versione coordinata.

Sono in corso test e sviluppo in rete, con i team dei clienti concentrati sulle prestazioni di PeerDAS, sul modello di prezzo BLOB e sulla compatibilità tra esecuzione e software di consenso. In caso di successo, Fusaka potrebbe segnare un punto di svolta nella capacità di Ethereum di adattarsi alla prossima ondata di adozione del Layer 2.